This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

S/MIME certificates are not extracted

In Astaro 8.311, I have configured (under Mail security - Encryption - Options) automatic extraction of S/MIME certificates.
However, it never happens that S/MIME certificates get extracted and listed under Mail security - Encryption - S/MIME certificates. The list remains empty.
I have received several signed mails from external, where the user certificate (A) was signed by an intermediate certificate (B) and the intermediate certificate (B) was signed by a standard VeriSIgn certificate (C).
I have verified that C occurs among Mail security - Encryption - S/MIME CAs
I have also added B manually to that list and received signed mails after that. 
Still no success.
The way I understand this feature, an incoming mail signed with certificate A should cause A to appear under Mail security - Encryption - S/MIME certificates after a few minutes ...

What's wrong here? [:S]


This thread was automatically locked due to age.
Parents
  • I'm still having this problem with 9.106-17 - Any new ideas? For exmaple, any logging that might shed insights?
  • 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,

    • which was signed by a user certificate,
    • which is signed by "COMODO SHA-256 Client Authentication and Secure Email CA" (not in list) as intermediate,
    • and this again signed by "AddTrust External CA Root" (in the list of "global S/MIME CAs", verified by comparing fingerprints).

    I also tested with another incoming mail,

    • signed by a user certificate,
    • this signed by "StartCom CA StartCom CC ICA" as intermediate (previously imported by me into the list of local CAs),
    • this again signed by "StartCom CA StartCom Certification Authority ECC" as root CA (previously imported by me into the list of local CAs).

    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").

Reply
  • 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,

    • which was signed by a user certificate,
    • which is signed by "COMODO SHA-256 Client Authentication and Secure Email CA" (not in list) as intermediate,
    • and this again signed by "AddTrust External CA Root" (in the list of "global S/MIME CAs", verified by comparing fingerprints).

    I also tested with another incoming mail,

    • signed by a user certificate,
    • this signed by "StartCom CA StartCom CC ICA" as intermediate (previously imported by me into the list of local CAs),
    • this again signed by "StartCom CA StartCom Certification Authority ECC" as root CA (previously imported by me into the list of local CAs).

    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").

Children
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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) ...

  • OK, thanks Bob. I opened a ticket at Sophos support. We will see...

    @hagman_01: Did you contacted support regarding that?

    -

  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Till now it seems that the extraction is not even triggered in my case. This should be visible in smtp debug log (see )

    Support is working on that. I will post an update asap.

    Best

    Alex

    -