7

Background:

  • Ubuntu Server 14.10 64-bit on aws.amazon.com/ec2
  • Cheap PositiveSSL server certificate from COMODO
  • 1 server certificate, 2 intermediate CA certificates and 1 Root CA certificate as ZIP archive from COMODO
  • Citadel's WebCit httpsd

Problem:

The concatenated certificate chain seems to be correct but verification fails.

openssl s_client myhost:port

shows the certificate chain and the issuer-subject pairs line up correctly through the chain, but:

verify error:num=19:self signed certificate in certificate chain

The root CA certificate is not accepted by openssl, although it is found per default in the Ubuntu server trust store.

Specifically: AddTrustExternalCARoot.crt received per email from COMODO and /etc/ssl/certs/AddTrust_External_Root.pem which links to /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt are indentical.

What is wrong here?

Improve this question
5
  • If you use firefox or chrome to connect to your site, do you get any certificate warning?
    – John Siu
    Apr 18, 2015 at 23:37
  • Not firefox. I am using Citadel.org as an email server and the SSL certificates are for SMTPS on ports 465 and 587. Indeed Thunderbird does not complain.
    – Reinhard Seifert
    Apr 19, 2015 at 21:35
  • The Firefox issue triggered my post here. Oh man, I am tired. So, Thunderbird does not complain on SMTPS, but Firefox does not display the HTML page and I am guessing it it the certificate, because when using openssl s_client the html of the page shows up and w3m also displays the page after complaining about the untrusted certificate. But Firefox simply does not show the page, without any warning about the certificate.
    – Reinhard Seifert
    Apr 19, 2015 at 21:49
  • Try the browser test with another device. Also use latest version if possible. I am starting to guess that the computer used for the test need root CA package update.
    – John Siu
    Apr 19, 2015 at 21:55
  • Thank you guys! Tried in on another machine and it works now both in Firefox and Thunderbird. This said it seems that jotaps answer is correct. Although it is even more weird with openssl: openssl verify -CAfile chained.crt chained.crt passes "OK" (chained.crt is the chained certificate with server cert, intermediate certs and root CA cert)! To me this is inconsistent and strange behavior of openssl. The cert chain is correct, the last cert is in the trust store and openssl recognizes it both as a single cert and as a CAfile, but not when last in a chain. Is this a bug?
    – Reinhard Seifert
    Apr 20, 2015 at 18:54

3 Answers 3

Reset to default
4

OpenSSL at least through current (1.0.2a) has a bug where s_client with NO -CA{path,file} argument doesn't actually use the default truststore as it should, and thus fails to verify certs that are valid according to that truststore. (Also s_server and s_time, but caring about verification in those is rare.) See https://serverfault.com/questions/607233/how-to-make-openssl-s-client-using-default-ca . A fix is announced in dev, but may take some time to be released and distributed. In the meantime you need to explicitly specify the -CA* argument(s). Note that openssl verify does not have this bug, and therefore correctly reported the cert/chain as valid.

UPDATES 2015/08/26: fix was released 2015/06/12 in 1.0.1o and 1.0.2c. Also, while investigating something else I found that RedHat packages may have been okay. More specifically the CentOS source RPM for openssl-1.0.1e-30.el6.11 which I understand is a copy of the RedHat one (but can't easily confirm) contains openssl-1.0.1c-default-paths.patch which contains changes to s_client.c s_server.c s_time.c dated 2012/12/06 that appear equivalent to (though not textually the same as) the 2015/06/12 upstream fixes. Assuming this patch was applied in RedHat and CentOS packages, which I can't easily go back and check, they would (have) work(ed) as expected.

Improve this answer
1
  • Thank you. That clarified the matter and indeed it was for once not me messing things up... in the browser and MUA the chain is accepted.
    – Reinhard Seifert
    Apr 27, 2015 at 9:11
3

I faced a similar issue with Comodo certificates recently when developing a script using Ruby. In the end it was that OpenSSL did not have it in the store, even though it looked like it did.

To test this, download all of the Comodo intermediate certs and create a cert bundle something like this (you'll need to use different cert names depending on what you downloaded):

cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt AddTrustExternalCARoot.crt > yourDomain.ca-bundle

Comodo has an article on how to do this.

Once done, try verifying the certificate again using OpenSSL and specifying the cert store on the command line:

openssl verify -untrusted yourDomain.ca-bundle cert.pem

That example was adapted from this Unix and Linux StackExchange article.

Once you've determined which certificate it is, it should be possible to add the certificate to the local cert store, which is detailed here for Ubuntu, and is something like:

Create a directory for extra CA certificates in /usr/share/ca-certificates

sudo mkdir /usr/share/ca-certificates/extra

Copy the '.crt' file to the directory

sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt

Let Ubuntu add the '.crt' file's path relative to /usr/share/ca-certificates to /etc/ca-certificates.conf

sudo dpkg-reconfigure ca-certificates
Improve this answer
9
  • This is my guess too, that's why I ask OP to test with a Chrome or Firefox browser.
    – John Siu
    Apr 18, 2015 at 23:45
  • "In the end it was that OpenSSL did not have it in the store..." - OpenSSL does not have a store. You have to explicitly tell it what to use as a trust anchor. OpenSSL is not like browsers which trust nearly anything that's thrown at them.
    – jww
    Apr 19, 2015 at 20:48
  • Thanks for your immediate answers and comments guys. I will look closer at it tomorrow. I get the point. But: When doing openssl verify AddTrustExternalRootCA.crt (which is the culprit at the end of the chain) for the root certificate alone, then it passes "OK", i.e. openssl is very well aware of the certificates linked in /etc/ssl/certs.
    – Reinhard Seifert
    Apr 19, 2015 at 21:39
  • ... and yes, when concatenating the intermediate and root CA certificates into CAbundle.crt and trying openssl verify -CAfile CAbundle.crt myserver_com.crt then it passes the test "OK".
    – Reinhard Seifert
    Apr 19, 2015 at 21:43
  • 2
    @jww OpenSSL library has a default store location, but uses it only if the application calls SSL_CTX_set_default_verify_paths() or some related X509_STORE routines. OpenSSL commandline is supposed to use the default store, but currently fails to do so for some functions including s_client due to a bug; see my answer. OTOH verify does use it, which probably added to the confusion here.
    – dave_thompson_085
    Apr 22, 2015 at 4:32
0

The comodo root certificate is no longer trusted - google for "comodo stolen certificate" if you don't know why.

While a comodo certificate may be cheap, its value is much less than its price: It is in effect worthless, the chain of trust is broken.

Improve this answer
1
  • 1
    That is four years ago and the certificates have been revoked and replaced. On top the root CA is not from COMODO but from AddTrust; the root CA certificate is verified OK when using openssl verify AddTrustExternalCARoot.crt directly, but it is not accepted as the last certificate in a chain.
    – Reinhard Seifert
    Apr 18, 2015 at 23:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .