Getting SSL certificate error on valid certificate when accessing via Curl

ubuntu ssl openssl ssl-certificate

8,715

Solution 1

You didn't provide the actual address of the website, nor the SSL provider's name, nor any other information about the certificate, and basically want us to guess at various possible causes.

My guess is that your certificate chain ends with "AddTrust External Root" as the topmost CA, and that root certificate just expired several hours ago.

Sectigo, the certificate's owner, has a diagram of the chain – due to old CA certificates cross-signing new ones, "AddTrust External Root" was basically a higher tier above what would normally be the company's actual root CA. New operating systems would see Sectigo/Comodo's certificates as self-signed root CAs, while old ones would see them as intermediate CAs below AddTrust Root.

So on old operating systems which only recognize Sectigo via cross-signing by the AddTrust Root CA certificate, as soon as the latter expires, the whole chain is invalid. To fix this, you have to switch to another CA which those systems recognize as a root (check /etc/ssl/certs).

It could be that those systems do recognize Sectigo as a root CA in its own right. In theory, is completely legal for a certificate to validate through multiple chains, e.g. a CA can simultaneously be a root and be cross-signed by another CA.

But in practice, many TLS client libraries are really bad at building alternate chains and assume there's always exactly one way to validate a certificate. (Windows is a bit better, and the big web browsers also include code to handle this extra complexity on top of what the TLS library would probide.)

For example, older versions of OpenSSL were very strict about which certificates could act as trust roots. If the server sent a chain "OldCA–NewCA–Intermediate–MyServer", OpenSSL 1.0 would only accept if you had "OldCA" as a trusted certificate – but it wouldn't be smart enough to accept it if you had "NewCA" instead.

So if Ubuntu 14.04 already recognizes Sectigo as a certificate authority, then you need to fix the certificate chain that is being sent by your webserver – I suspect removing the certificate which says "Issuer: AddTrust" should be enough.

Let's say the old certificate chain looks like this:

[AddTrust External Root]                               [included in OS]
+-- USERTrust RSA Certification Authority (Sectigo)    sent by your server
    +-- Gandi Standard SSL CA 2                        sent by your server
        +-- git.kernel.org                             sent by your server

You need to edit it so that your server stops sending the cross-signed USERTrust certificate:

[USERTrust RSA Certification Authority (Sectigo)]      [included in OS]
+-- Gandi Standard SSL CA 2                            sent by your server
    +-- git.kernel.org                                 sent by your server

You can also fix this on the client side, by removing the AddTrust root CA.

Solution 2

We had the same issues today with our 14.04s failing and the 18s working fine. It looks like today is the day when a popular root support stopped working for older Ubuntu boxes. Fortunately, we just decommissioned the 14s but if you can't there are some instructions in there to try to get it to work. Also, our DevOps team noted this would also probably require some heavy lifting with upgrading OpenSSL and making it compadible with the changes described here. https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020

Solution 3

you need to remove AddTrust External Root from your cacert.pem or your trustchain /usr/lib/ssl/certs/AddTrust_External_Root.pem in my Linux mint.

For those who are wondering, you can take the cacert.pem from Mozilla there: https://curl.haxx.se/docs/caextract.html You then need to remove AddTrust External Root.

Removing AddTrust External Root force software to use correct path certification (when you have multiple ones).

For example, twinoid.com has 3 paths. Two of them are valid, the last contain AddTrust External Root. https://www.ssllabs.com/ssltest/analyze.html?d=twinoid.com&hideResults=on (you can check the 3 paths there)

Of course, the correct fix should be from software who do not handle correctly this but this temporary fix saves me. Some Softwares like browsers have already fixed this issue some time ago.

8,715

Author by

kargirwar

Updated on September 18, 2022

Comments

kargirwar over 1 year
I have a wildcard SSL certificate which powers *.mysite.com. The site is accessible from all browsers without any problem. There is also a service (on a different server) with URL: service.mysite.com. Strangely, when I access service.mysite.com using curl I get this:
```
curl: (60) SSL certificate problem: certificate has expired
```
On digging further I found that I can indeed access service.mysite.com from a Ubuntu 18.04 server but not from Ubuntu 14.04. That tells me that perhaps my CA bundle is not in order.

So I did this:
```
curl -vv --cacert mysite.ca-bundle.crt https://service.mysite.com
```
mysite.ca-bundle.crt is the one I received from the SSL provider. But I still get exactly same error. What am I missing?
- Daniel B almost 4 years
  
  Why do you think the message is wrong? Have you checked the certificate to make sure it is not expired?
- kargirwar almost 4 years
  
  Finally fixed it on client side using following: 1. Edit /etc/ca-certificates.conf and put a bang/exclamation mark (!) before mozilla/AddTrust_External_Root.crt 2. Run update-ca-certificates
Ramhound almost 4 years

This just duplicates the information in the existing answer to this question, links to the same support article of an existing question, relevant information should always be cited and quoted from supporting external links.
Ricardo Martins almost 4 years

I just needed to replace .ca-bundle for a new one, downloaded at my SSL provider's website. More info at ssls.com/knowledgebase/…
stevec almost 4 years

"You need to edit it so that your server stops sending the cross-signed USERTrust certificate" Is this right - shouldn't it say "stop sending the 'AddTrust External Root' certificate" ?
user1686 almost 4 years

No – the root certificate usually isn't being sent in the first place (it is assumed that clients will have all roots they trust – otherwise they couldn't really trust them). You need to remove an intermediate certificate which refers to AddTrust as its issuer, so that the client system will use its own copy of that certificate which refers to a different issuer.
user1686 almost 4 years

(There are at least three different versions of the exact same "USERTrust" certificate: the one in bad chains has AddTrust as issuer, the one in Windows has AAA Certificate Authority as issuer, and the one on Linux is a self-issued root certificate.)
Honarkhah almost 4 years

But by removing that you can have a risk of getting it back by updating root ca. the best way is to reissue the certs with correct chain and install it.
Honarkhah almost 4 years

I checked OpenSSL 1.0.1t (3 May 2016) this one cannot handle old CA and new CA together.
user1686 almost 4 years

Strictly speaking, the server's cert is not the one that needs to be reissued -- only the intermediate cert (the one directly under AddTrust) needs to be reissued. And it actually has been reissued. So if you're in a situation where getting a new certificate (with a working chain) would be slow or expensive, you can edit the existing chain by hand.
Matoran almost 4 years

The next update will remove this root ca from everywhere, ca-certificates is already updated on ubuntu. This fix was temporarily useful. I've done this because I had no control over the faulty server.