Bumping this thread: Meanwhile we have UTM 9.413-4 and the problem is still there, even after so many years.
I just tested the situation once more with an incoming mail,
I also tested with another incoming mail,
Neither of these mails triggered the automatic S/MIME certificate extraction. My list under "S/MIME certificates" is still empty.
I do not find any interesting lines in the smtp.log, either (or would I have to look elsewhere?)
It would be really great if this problem could be resolved, finally.
P.S.: I noticed some strangeness, but don't know if that is in any way related to the bug: The format how fingerprints are displayed differ between global and local CAs in that local CA fingerprints are displayed (via the info icon) as pure hex digit sequence (e.g., "Fingerprint: DA1D80BCF06499E616B8C51226A1C62D7ADAD751") whereas global CA fingerprints are grouped by colons (e.g., "Fingerprint: B5:61:EB:EA:A4:DE:E4:25:4B:69:1A:98:A5:57:47:C2:34:C7:D9:71").
Anyone got that working?
Same situation here as hagman_01. Using UTM 9.503. Evaluating Mail Protection at the moment to see if it's worth buying it.
As this thread is many years old and only few guys replied my hope isn't increased.
-
Loading the UTM with CAs that have an intermediate CA is tricky. You have a PM with my email address.
Cheers - Bob
Our UTM automatically stripped the certificate from Alex' email:
If your UTM isn't doing this, then it's a configuration issue there.
Cheers - Bob
BAlfson said:Loading the UTM with CAs that have an intermediate CA is tricky.
And what is the trick? I for my part tried with importing both the senders root and intermediate cert without success (situation unchanged for several years) ...
Here's an example of how to create a p12 file with Windows OpenSSL that works to get a correct import with an intermediate CA.
From the directory containing the CAs, your cer file and your private key (all on one line):
C:\Program Files (x86)\OpenSSL-Win64\bin\openssl.exe pkcs12 -export -in -certfile Comodo.Root.CA.file -certfile Comodo.Intermediate.CA.file sub.domain.com.cer -inkey sub.domain.com.private.key -out sub.domain.com.p12
Cheers - Bob
Can you elaborate on the issues related to Intermediate CAs? My experience is only with web traffic certificates.
For web traffic, the server is supposed to send both the identity certificate and the intermediate certificate. For S/MIME, is the same behavior expected, so that the email includes the intermediate certificate, or is the receiving system supposed to use AIA Fetching to find the intermediate certificate?
UTM Web Filtering does not do AIA Fetching, at least in the versio that I am running, and a significant percentage of sites do not provide the intermediate certificate. So I have gradually built a database of Intermediate certificates that I have loaded inot WEb Proxy as a CA. This solves the Web Proxy problem. I wonder if htis is necessary for your S/MIME traffic as well.
BAlfson said:Here's an example of how to create a p12 file with Windows OpenSSL that works to get a correct import with an intermediate CA.
From the directory containing the CAs, your cer file and your private key (all on one line):
C:\Program Files (x86)\OpenSSL-Win64\bin\openssl.exe pkcs12 -export -in -certfile Comodo.Root.CA.file -certfile Comodo.Intermediate.CA.file sub.domain.com.cer -inkey sub.domain.com.private.key -out sub.domain.com.p12
Cheers - Bob
I do not understand how a private key can play a role here. In fact, conceptually, I do not even need to have a private key for the desired behaviour the way I understand it.
To be precise, the problem is that some external sender foo@external.example sends an email to me@internal.example and that mail carries an S/MIME-Signature that is valid for foo@external.example and the corresponding cert is signed by third-party-CA (possibly indirectly, i.e., signed by intermediate-third-party-CA, which again is signed by third-party-CA). The expected bahaviour (provided, the CA certificate(s) is/are known to the UTM) is that the S/MIME certificate of foo@external.example be extracted and inserted into the list of external S/MIME certificates. Note that the private keys involved (those of foo@external.example, intermediate-third-party-CA, third-party-CA) are not and should not be under my control ...
Confused - Hagen
You're right, that example is for a situation where you generate a CSR with a private key and then want to load it into your UTM along with the CAs. For just the CAs, I haven't played with it, but I would try:
C:\Program Files (x86)\OpenSSL-Win64\bin\openssl.exe pkcs12 -export -in -certfile Comodo.Root.CA.file -certfile Comodo.Intermediate.CA.file -out Comodo.CA.p12
In fact, you might be able to just concatenate the CAs and upload that.
Doug, I can't give definitive answers to your questions. I know that with Webserver Protection, you have to use the approach I described in my post yesterday. You can't upload the certificate separate from the CA chain and you can't upload the CAs separately. I suspect that this has to do with the way the object database is constituted by WebAdmin and the configuration daemon - they need to be associated in order for things to work. So, I suspect that such is the case with certs and CAs everywhere in the UTM.
Cheers - Bob
You're right, that example is for a situation where you generate a CSR with a private key and then want to load it into your UTM along with the CAs. For just the CAs, I haven't played with it, but I would try:
C:\Program Files (x86)\OpenSSL-Win64\bin\openssl.exe pkcs12 -export -in -certfile Comodo.Root.CA.file -certfile Comodo.Intermediate.CA.file -out Comodo.CA.p12
In fact, you might be able to just concatenate the CAs and upload that.
Doug, I can't give definitive answers to your questions. I know that with Webserver Protection, you have to use the approach I described in my post yesterday. You can't upload the certificate separate from the CA chain and you can't upload the CAs separately. I suspect that this has to do with the way the object database is constituted by WebAdmin and the configuration daemon - they need to be associated in order for things to work. So, I suspect that such is the case with certs and CAs everywhere in the UTM.
Cheers - Bob
At least in my case, it was a layer 8 mistake [H] Certainly caused by a lack of documentation.
Certificate extraction therefore only takes place if the e-mail is sent to a user for whom an internal user is listed under E-mail Encyption.
Thus, the automatic extraction of certificates worked for me too. I hope this insight will help others now.
Best
Alex
-