#!/bin/blog

February 2, 2010

Dealing with lengthy SSL certificate chains

Filed under: Security — Tags: , , , , — martin @ 4:16 pm

Comodo delivers the cheapest widely-recognized certificates (available e.g. via psw.net), second only to the famed StartSSL Free CA, which I haven’t had the guts to try out so far. What I got from Comodo, is my server cert, along with no less than three intermediate certificates:

AddTrustExternalCARoot.crt
issuer= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
subject= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

UTNAddTrustServerCA.crt
issuer= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
subject= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware

PositiveSSLCA.crt
issuer= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
subject= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA

Server.crt
issuer= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA

You can obtain this information by running, e.g.:

for c in $(ls *crt); do echo -e "\n$c"; openssl x509 -issuer -subject -noout -in $c; done

Note how I have ordered them from the root certificate on top to the server certificate on the bottom, each being the issuer of the succeeding one. Did I say root certificate? Good news then: AddTrust is the root certificate, hence it does not need to be deployed, which leaves me with a chain of two.

I will need to deploy the certificates into Postfix and Dovecot, which use an all-in-one file that contains the complete chain, including the server certificate. Other servers, such as the Apache webserver, use a server certificate file and a separate file containing the intermediate certificates. Which is the method I prefer. But you just can’t always get what you want. 😉

I learned the hard way that certificate order does matter. RFC 5246 states:

The sender’s certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority may optionally be omitted from the chain,
under the assumption that the remote end must already possess it
in order to validate it in any case.

Thus, the all-in-one file needs to start with the server certificate, followed by the certificate that issued the server certificate, all the way down to the one that is farthest away from the server certificate: 1) Server, 2) PositiveSSLCA, 3) UTNAddTrustServerCA

For servers that use a separate intermediate file, the order is the same, with the difference that the server certificate resides in its own file.

I recommend to maintain the subject and issuer information of all components of the all-in-one file so it won’t have to be dissected at a later point in order to understand what it contains. My starting point is the server cert, to which I will append the intermediate certs:

1) Locate the issuing certificate of the server cert (-> output above) and append the respective certificate to the server cert.
2) Locate the issuing certificate of the previously appended certificate and append it to the server cert.
3) Repeat until the root CA certificate has been reached.

In my case:
openssl x509 -in server.crt -subject -issuer > server-allinone.crt
openssl x509 -in PositiveSSLCA.crt -subject -issuer >> server-allinone.crt
openssl x509 -in UTNAddTrustServerCA.crt -subject -issuer >> server-allinone.crt

Now I have a handy file ready for deployment:

subject= /OU=Domain Control Validated/OU=PositiveSSL/CN=server
issuer= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA
issuer= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
issuer= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

The main point is that you must understand how the certificates relate to each other. The issuer and subject fields are the key all the way through the procedure.

Advertisements

13 Comments »

  1. Oh, thanks for the info, since i planned on setting up our own server with official certificates some time in the future, and since i’m also using dovecot and postfix, this is helpful information! Tagged and bookmarked! 🙂

    Comment by Dirk — February 2, 2010 @ 9:13 pm

  2. Thanks a lot, i’m using now a certificate from Start SSL for my dovecot imap server. I just used ‘cat’ to pipe the whole certificate into my ALL-IN-ONE file.Is this anyhow different to what u did? Also postfix seems to be just fine without the intermediate certificate, which dovecot needs to have evolution (my email client) accept my server certificate. Evolution accepts the certificate from postfix when sending emails, although postfix does not even know there is a intermediate certificate. I’m not that much familiar with the topic of certificates, maybe you can point out to me why evolution still accepts the certificate from postfix.

    thanks in advance and best regards

    robert

    Comment by robert — March 17, 2010 @ 11:38 pm

    • Evolution may have cached the intermediate certificate from its communication with the IMAP server.

      Comment by martin — March 18, 2010 @ 9:58 am

      • thanks for the hint, i will try to sent emails without an imap account configured. When deleting my imap account the cached certificates should be gone right?

        Comment by robert — March 18, 2010 @ 10:45 am

      • That’s a client issue. What is the actual problem you’re trying to solve?

        Comment by martin — March 18, 2010 @ 11:54 am

  3. I get the certs from StartSSL a while ago and gave up after 16 man hours in work. Decided to use a self-signed cert in the end. We decided it was not worth the pain. Its nice to now know that we weren’t alone 😀 Good luck.

    Comment by Tom — January 7, 2011 @ 10:16 pm

  4. By the way:
    Although I used self-signed certs, I decided to finally email StartSSL, and have found them very helpful. It was still very confusing 😀

    Comment by Tom — January 7, 2011 @ 10:53 pm

  5. The idea of explicitly examining the subject and issuer of each cert in the chain got me to realize that my ssl vendor didn’t give me all the intermediates I needed. They recently went away from a single signed root cert and introduced a new intermediary chain. I was able to ID the culprit and go download the missing cert. This got rid of my return code 20 (unable to get local issuer certificate) when testing via openssl s_client.

    However, I know am getting a self-signed return code with openssl s_client because the GeoTrust root cert is signed by GeoTrust (issuer and subject are the same). Most all of my tested clients (imaps, smtps, and https) seem to be ok with this except for one: my wife’s mail client on her android phone. I have to ignore trust settings for the server cert on her phone to connect to imaps. openssl verify on my server cert now works (using hashed cert dir).

    Any idea how to get around this, if it’s really a problem? If not, why is this one client choking?

    Thanks for the post and also for any insight.

    Comment by Ian — June 11, 2011 @ 9:35 am

    • I have never had an SSL issue that wasn’t fixable in the end, so yes, it is most certainly a problem. 😉

      As you make no mention of it: Have you checked to see if the Android phone has the Root certificate preinstalled?

      Comment by martin — June 11, 2011 @ 9:52 am

      • Hah! Thanks for the pointer on where to look. Looking at a problem from the outside always helps. The issue is with the android’s certificate stack. That brought me here:
        http://code.google.com/p/android/issues/detail?id=10807

        Apparently the CAs distributed with the froyo release of the OS didn’t include some of the newer certs that the authorities were distributing (the higher bitsize ones). So I’ve had to include the “crossroot” CA as well as Equifax’s root CA in my intermediary CA bundle for dovecot. Now the Android mail client doesn’t complain.

        Openssl still complains about the Equifax cert being self-signed, but I can live with that, since no clients have any issues.

        Thanks!

        Comment by Ian — June 11, 2011 @ 10:23 am

      • Great. 🙂 I don’t have too much trust in the validity checks from OpenSSL, though. They have given me misleading results many times.

        Comment by martin — June 11, 2011 @ 10:33 am

      • Well, I do like the s_client interface. I can use it as a general purpose protocol debugger.

        Comment by Ian — June 11, 2011 @ 10:40 am

  6. […] […]

    Pingback by Comodo SSL Certificate installation - Zimbra :: Forums — March 11, 2012 @ 8:07 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: