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?

  • Why do you think the message is wrong? Have you checked the certificate to make sure it is not expired?
    – Daniel B
    May 30, 2020 at 16:25
  • 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
    – kargirwar
    Jun 4, 2020 at 3:50

3 Answers 3


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.

  • "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" ?
    – stevec
    Jun 2, 2020 at 22:43
  • 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. Jun 2, 2020 at 23:10
  • (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.) Jun 2, 2020 at 23:19
  • I checked OpenSSL 1.0.1t (3 May 2016) this one cannot handle old CA and new CA together.
    – Honarkhah
    Jun 3, 2020 at 10:34

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

  • 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.
    – Ramhound
    May 30, 2020 at 18:22
  • 1
    I just needed to replace .ca-bundle for a new one, downloaded at my SSL provider's website. More info at ssls.com/knowledgebase/… Jun 2, 2020 at 4:05

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.

  • 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
    Jun 3, 2020 at 10:31
  • 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. Jun 3, 2020 at 10:50
  • 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.
    – Matoran
    Jun 4, 2020 at 11:06

You must log in to answer this question.

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