Loading ...
Sorry, an error occurred while loading the content.

ECDSA chain cert not working

Expand Messages
  • SW
    Yesterday I had my SSL certificate re-issued. I now have two certificates for the same domain. One has an RSA signature and the new one I received yesterday
    Message 1 of 10 , May 12, 2014
    • 0 Attachment
      Yesterday I had my SSL certificate re-issued. I now have two certificates for the same domain. One has an RSA signature and the new one I received yesterday uses ECDSA. I enabled the ECDSA certificate in Dovecot and Apache and those services are working great.

      In Postfix I have enabled two certificates (RSA and ECDSA). To enable the ECDSA cert I added the following to my main.cf:

      smtpd_tls_eccert_file = /usr/local/openssl/certs/mail.domain.com.chained.postfix.ecdsa.crt
      smtpd_tls_eckey_file = /usr/local/openssl/certs/mail.domain.com.ecdsa.key


      When I received the ECDSA cert from Comodo I had the following files:
      • AddTrustExternalCARoot.crt
      • COMODOECCAddTrustCA.crt
      • COMODOECCDomainValidationSecureServerCA.crt
      • mail.domain.com.crt

      To create the chained file for use in Postfix I ran:
      cat mail.domain.com.crt COMODOECCDomainValidationSecureServerCA.crt COMODOECCAddTrustCA.crt > mail.domain.com.chained.postfix.ecdsa.crt

      The problem is, when I restart postfix and test with:
      openssl s_client -connect mail.domain.com:25 -crlf -starttls smtp -CAfile /usr/local/openssl/certs/AddTrustExternalCARoot.crt

      it says:

      CONNECTED(00000003)
      depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = mail.domain.com
      verify error:num=20:unable to get local issuer certificate
      verify return:1
      depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = mail.domain.com
      verify error:num=27:certificate not trusted
      verify return:1
      depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = mail.domain.com
      verify error:num=21:unable to verify the first certificate
      verify return:1

      Certificate chain
       0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.domain.com
         i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
       1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA
         i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority
       2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority
         i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

      ....

         Verify return code: 21 (unable to verify the first certificate)


      If I comment out:

      #smtpd_tls_eccert_file = /usr/local/openssl/certs/mail.domain.com.chained.postfix.ecdsa.crt
      #smtpd_tls_eckey_file = /usr/local/openssl/certs/mail.domain.com.ecdsa.key

      and restart Postfix agan and run another OpenSSL test it is all fine with the RSA cert:

      Verify return code: 0 (ok)


      So the question is, how do I get this new ECDSA certificate to work in Postfix and why doesn't it like the chain file I have created? It looks like its using the RSA certificate in the chain for the ECDSA certificate which is confusing! In case anyone's wondering, Postfix does support running more than one certificate at once. See here: http://postfix.cs.utah.edu/TLS_README.html.
      RSA, DSA and ECDSA (Postfix ≥ 2.6) certificates are supported. You can configure all three at the same time, in which case the cipher used determines which certificate is presented.


      I am running the latest version of Postfix and OpenSSL on FreeBSD 10-STABLE

      Any ideas? My Dovecot and Apache ECDSA certifcate and chain verify just fine as does my chain file used in Postfix with my RSA certificate. Its just the ECDSA one in Postfix I am battling with.

      I would appreciate any help!
    • Viktor Dukhovni
      ... Notice that the issuer of the leaf certificate is called: COMODO RSA Domain Validation Secure Server CA ... While the subject of the second certificate is
      Message 2 of 10 , May 12, 2014
      • 0 Attachment
        On Mon, May 12, 2014 at 04:43:27PM +0100, SW wrote:

        > Certificate chain
        > 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.domain.com
        > i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA

        Notice that the issuer of the leaf certificate is called:

        COMODO RSA Domain Validation Secure Server CA

        > 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA
        > i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA

        While the subject of the second certificate is called:

        CN=COMODO ECC Domain Validation Secure Server CA

        So this chain does not have matching issuer-subject pairs.

        > So the question is, how do I get this new ECDSA certificate to work in
        > Postfix and why doesn't it like the chain file I have created? It looks like
        > its using the RSA certificate in the chain for the ECDSA certificate which
        > is confusing! In case anyone's wondering, Postfix does support running more
        > than one certificate at once. See here:
        > http://postfix.cs.utah.edu/TLS_README.html.

        The issue appears to be an OpenSSL limitation that is fixed in the
        master 1.1.0 development branch and in the upcoming 1.0.2 release
        branch. (In other words, broken in all currently released stable
        branches).

        The problem is that there is no separate per-algorithm chain. Only
        a single global chain. Loading the chain for any given algorithm
        clears the global chain and replaces it with the issuers from the
        most recently loaded chain file (last one wins).

        A work-around is to list all the relevant CAs in the chain files
        for both algorithms. The patches that resolve this for 1.0.2 are
        attached for educational purposes only. They are unlikely to apply
        to 1.0.1 or earlier in isolation, and in any case would be entirely
        untested with 1.0.1 as a base.

        The first patch implements the relevant internal mechanisms, and
        the second uses them in an updated implementation of the chain
        file loading function.

        So the Postfix documentation for multiple key types promises more
        than OpenSSL currently delivers. Unfortunately the limitation was
        not apparent from earlier OpenSSL documentation.

        --
        Viktor.
      • SW
        Hi Viktor Many thanks for the reply! So I m not going crazy... You said: A work-around is to
        Message 3 of 10 , May 12, 2014
        • 0 Attachment
          Hi Viktor

          Many thanks for the reply! So I'm not going crazy...<smiley
          image="smiley_beam.gif"/>

          You said:

          <quote author="Viktor Dukhovni">
          A work-around is to list all the relevant CAs in the chain files
          for both algorithms. The patches that resolve this for 1.0.2 are
          attached for educational purposes only. They are unlikely to apply
          to 1.0.1 or earlier in isolation, and in any case would be entirely
          untested with 1.0.1 as a base.
          </quote>

          So do I need to create a chain cert as follows for each cert (RSA and
          ECDSA):

          cat mail.domain.com.ecdsa.crt
          COMODOECCDomainValidationSecureServerCA.crt COMODOECCAddTrustCA.crt
          COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt>
          mail.domain.com.chained.postfix.ecdsa.crt

          cat mail.domain.com.sha256.crt
          COMODOECCDomainValidationSecureServerCA.crt COMODOECCAddTrustCA.crt
          COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt>
          mail.domain.com.chained.postfix.sha256.crt

          Would this do the trick?
        • Viktor Dukhovni
          ... (Why not just try it, first?) Basically, each chain starts with the leaf cert, and then includes all the issuers of either for both. The order will no
          Message 4 of 10 , May 12, 2014
          • 0 Attachment
            On Mon, May 12, 2014 at 08:44:00PM +0100, SW wrote:

            > <quote author="Viktor Dukhovni">
            > A work-around is to list all the relevant CAs in the chain files
            > for both algorithms. The patches that resolve this for 1.0.2 are
            > attached for educational purposes only. They are unlikely to apply
            > to 1.0.1 or earlier in isolation, and in any case would be entirely
            > untested with 1.0.1 as a base.
            > </quote>
            >
            > So do I need to create a chain cert as follows for each cert (RSA and
            > ECDSA):
            >
            > cat mail.domain.com.ecdsa.crt COMODOECCDomainValidationSecureServerCA.crt
            > COMODOECCAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt
            > COMODORSAAddTrustCA.crt> mail.domain.com.chained.postfix.ecdsa.crt
            >
            > cat mail.domain.com.sha256.crt COMODOECCDomainValidationSecureServerCA.crt
            > COMODOECCAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt
            > COMODORSAAddTrustCA.crt> mail.domain.com.chained.postfix.sha256.crt
            >
            > Would this do the trick?

            (Why not just try it, first?)

            Basically, each chain starts with the leaf cert, and then includes
            all the issuers of either for both. The order will no longer be
            a strict sequence of subject followed by issuer, but this requirement
            is generally not enforced.

            When 1.0.2 is finally released, you can return to a saner configuration.

            --
            Viktor.
          • SW
            Ok, so I have tried: cat mail.domain.com.ecdsa.crt COMODOECCDomainValidationSecureServerCA.crt COMODOECCAddTrustCA.crt
            Message 5 of 10 , May 12, 2014
            • 0 Attachment
              Ok, so I have tried:

              cat mail.domain.com.ecdsa.crt
              COMODOECCDomainValidationSecureServerCA.crt COMODOECCAddTrustCA.crt
              /support/certs/sha256/COMODORSADomainValidationSecureServerCA.crt
              /support/certs/sha256/COMODORSAAddTrustCA.crt >
              mail.domain.com.chained.postfix.ecdsa_2.crt

              cat mail.domain.com.sha256.crt
              COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt
              /support/certs/ecdsa/COMODOECCDomainValidationSecureServerCA.crt
              /support/certs/ecdsa/COMODOECCAddTrustCA.crt >
              mail.domain.com.chained.postfix.sha256_2.crt

              And this seems to have done the trick! Running:

              openssl s_client -connect mail.domain.com:25 -crlf -starttls smtp
              -CAfile /usr/local/openssl/certs/AddTrustExternalCARoot.crt

              returns:

              Verify return code: 0 (ok)

              The output looks as follows now:

              CONNECTED(00000003)
              depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN
              = AddTrust External CA Root
              verify return:1
              depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA
              Limited, CN = COMODO RSA Certification Authority
              verify return:1
              depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA
              Limited, CN = COMODO RSA Domain Validation Secure Server CA
              verify return:1
              depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN =
              mail.domain.com
              verify return:1
              ---
              Certificate chain
              0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.domain.com
              i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
              Limited/CN=COMODO RSA Domain Validation Secure Server CA
              1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
              Limited/CN=COMODO ECC Domain Validation Secure Server CA
              i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
              Limited/CN=COMODO ECC Certification Authority
              2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
              Limited/CN=COMODO ECC Certification Authority
              i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
              External CA Root
              3 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
              Limited/CN=COMODO RSA Domain Validation Secure Server CA
              i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
              Limited/CN=COMODO RSA Certification Authority
              4 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
              Limited/CN=COMODO RSA Certification Authority
              i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
              External CA Root
              ---

              Unfortunately I don't know of any email servers I can email as a test to
              see if the ECDSA cert is working 100%.

              But I think this issue is resolved?

              On 12/05/2014 21:16, Viktor Dukhovni wrote:
              > On Mon, May 12, 2014 at 08:44:00PM +0100, SW wrote:
              >
              >> <quote author="Viktor Dukhovni">
              >> A work-around is to list all the relevant CAs in the chain files
              >> for both algorithms. The patches that resolve this for 1.0.2 are
              >> attached for educational purposes only. They are unlikely to apply
              >> to 1.0.1 or earlier in isolation, and in any case would be entirely
              >> untested with 1.0.1 as a base.
              >> </quote>
              >>
              >> So do I need to create a chain cert as follows for each cert (RSA and
              >> ECDSA):
              >>
              >> cat mail.domain.com.ecdsa.crt COMODOECCDomainValidationSecureServerCA.crt
              >> COMODOECCAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt
              >> COMODORSAAddTrustCA.crt> mail.domain.com.chained.postfix.ecdsa.crt
              >>
              >> cat mail.domain.com.sha256.crt COMODOECCDomainValidationSecureServerCA.crt
              >> COMODOECCAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt
              >> COMODORSAAddTrustCA.crt> mail.domain.com.chained.postfix.sha256.crt
              >>
              >> Would this do the trick?
              > (Why not just try it, first?)
              >
              > Basically, each chain starts with the leaf cert, and then includes
              > all the issuers of either for both. The order will no longer be
              > a strict sequence of subject followed by issuer, but this requirement
              > is generally not enforced.
              >
              > When 1.0.2 is finally released, you can return to a saner configuration.
              >
            • Viktor Dukhovni
              ... This results in extraneous certificates in the chain, but likely works for most TLS clients. Unfortunately, there s nothing else you can do if you need to
              Message 6 of 10 , May 12, 2014
              • 0 Attachment
                On Mon, May 12, 2014 at 09:39:39PM +0100, SW wrote:

                > And this seems to have done the trick! Running:
                >
                > openssl s_client -connect mail.domain.com:25 -crlf -starttls smtp -CAfile
                > /usr/local/openssl/certs/AddTrustExternalCARoot.crt
                >
                > returns:
                >
                > Verify return code: 0 (ok)

                This results in extraneous certificates in the chain, but likely
                works for most TLS clients. Unfortunately, there's nothing else
                you can do if you need to support multiple key algorithms.

                For most users, it is probably best to delay rolling out multiple
                key algorithms until OpenSSL 1.0.2 or later is deployed.

                --
                Viktor.
              • SW
                I ll leave it configured as you have mentioned for now. When OpenSSL 1.0.2 is released I will change it back to how it should be. Is there any way I can
                Message 7 of 10 , May 13, 2014
                • 0 Attachment
                  I'll leave it configured as you have mentioned for now. When OpenSSL
                  1.0.2 is released I will change it back to how it should be.

                  Is there any way I can send/receive a test email that makes use of an
                  ECDSA cert? As expected, all the current TLS connections in the logs are
                  for RSA certs.
                • Viktor Dukhovni
                  ... Since you re controlling the server, all you need to do is configure a client that, all else being equal, prefers ECDSA to RSA. With OpenSSL 1.0.0 or
                  Message 8 of 10 , May 13, 2014
                  • 0 Attachment
                    On Tue, May 13, 2014 at 08:22:46AM +0100, SW wrote:

                    > I'll leave it configured as you have mentioned for now. When OpenSSL 1.0.2
                    > is released I will change it back to how it should be.
                    >
                    > Is there any way I can send/receive a test email that makes use of an ECDSA
                    > cert? As expected, all the current TLS connections in the logs are for RSA
                    > certs.

                    Since you're controlling the server, all you need to do is configure
                    a client that, all else being equal, prefers ECDSA to RSA. With
                    OpenSSL 1.0.0 or greater, a cipherlist something like:

                    aRSA:-aRSA:aECDSA:-aECDSA:kRSA:-kRSA:kEDH:-kEDH:kEECDH:-kEECDH:AESGCM:-AESGCM:AES128:CAMELLIA128:3DES:RC4:!EXPORT:!LOW:!MD5:!aNULL:!aDSS:!kSRP:!aPSK:!aECDH

                    will give you 128-bit AES and CAMELLIA, followed by 3DES and 128-bit
                    RC4, with ECDSA preferred to RSA, kEECDH and KEDH preferred to RSA
                    key transport, and AESGCM preferred to other block cipher modes.

                    --
                    Viktor.
                  • SW
                    Currently my cipher list looks as follows: tls_high_cipherlist =
                    Message 9 of 10 , May 13, 2014
                    • 0 Attachment
                      Currently my cipher list looks as follows:

                      tls_high_cipherlist =
                      ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

                      When I send an email (submission) from Thunderbird the logs show:

                      postfix/submission/smtpd[77780]: Anonymous TLS connection established
                      from machine.domain.com[192.168.14.120]: TLSv1.2 with cipher
                      ECDHE-ECDSA-AES128-SHA (128/128 bits)

                      So from a client point of view it looks good...although can you get
                      256/256 bits rather than 128/128 bits rather?

                      What I would still like to test is receiving an email from another MTA
                      that supports an ECDSA cert to my server.

                      Thanks so much for the helpful advice.


                      On 13/05/2014 15:18, Viktor Dukhovni wrote:
                      > On Tue, May 13, 2014 at 08:22:46AM +0100, SW wrote:
                      >
                      >
                      > Since you're controlling the server, all you need to do is configure
                      > a client that, all else being equal, prefers ECDSA to RSA. With
                      > OpenSSL 1.0.0 or greater, a cipherlist something like:
                      >
                      > aRSA:-aRSA:aECDSA:-aECDSA:kRSA:-kRSA:kEDH:-kEDH:kEECDH:-kEECDH:AESGCM:-AESGCM:AES128:CAMELLIA128:3DES:RC4:!EXPORT:!LOW:!MD5:!aNULL:!aDSS:!kSRP:!aPSK:!aECDH
                      >
                      > will give you 128-bit AES and CAMELLIA, followed by 3DES and 128-bit
                      > RC4, with ECDSA preferred to RSA, kEECDH and KEDH preferred to RSA
                      > key transport, and AESGCM preferred to other block cipher modes.
                      >
                    • Viktor Dukhovni
                      ... So it works. ... This is pointless. MTAs treat your certificate with equal indifference whether it is an RSA or ECDSA certificate. Since OpenSSL sorts
                      Message 10 of 10 , May 13, 2014
                      • 0 Attachment
                        On Tue, May 13, 2014 at 04:20:37PM +0100, SW wrote:

                        > When I send an email (submission) from Thunderbird the logs show:
                        >
                        > postfix/submission/smtpd[77780]: Anonymous TLS connection established from
                        > machine.domain.com[192.168.14.120]: TLSv1.2 with cipher
                        > ECDHE-ECDSA-AES128-SHA (128/128 bits)

                        So it works.

                        > What I would still like to test is receiving an email from another MTA that
                        > supports an ECDSA cert to my server.

                        This is pointless. MTAs treat your certificate with equal indifference
                        whether it is an RSA or ECDSA certificate.

                        Since OpenSSL sorts aRSA ahead of aECDSA by default, you're unlikely,
                        in the near future, to see any MTAs that negotiate ECDSA in preference
                        to RSA. Of course you can configure one that does, and use it to
                        "test", but it is not clear what you'd be testing.

                        --
                        Viktor.
                      Your message has been successfully submitted and would be delivered to recipients shortly.