{"id":2399,"date":"2020-06-03T11:08:02","date_gmt":"2020-06-03T09:08:02","guid":{"rendered":"https:\/\/www.bnamed.blog\/en\/?p=2399"},"modified":"2020-06-03T11:13:46","modified_gmt":"2020-06-03T09:13:46","slug":"expired-sectigo-certificate-causes-problems","status":"publish","type":"post","link":"https:\/\/www.bnamed.blog\/en\/2020\/06\/expired-sectigo-certificate-causes-problems\/","title":{"rendered":"Expired Sectigo certificate causes problems"},"content":{"rendered":"

\"\"On May 30th 2020 the certificate of “AddTrust External CA Root” expired. This certificate was 20 years old and had been used by Comodo\/Sectigo to sign the certificates they sold. While it had already been replaced a long time ago, it was still being included by Sectigo in the certificate chain, because it added support to old devices (like old Android systems) that didn’t know the new certificate yet.<\/p>\n

<\/p>\n

According to information from Sectigo, having an expired certificate in the certificate chain shouldn’t cause any problems. They informed that it should either be automatically substituted by an other certificate in the chain, or even that the client wouldn’t notice that it was expired.<\/p>\n

In practice this was indeed the case for all mayor browsers. So users visiting a website using such a certificate didn’t have any problems. But that couldn’t be said for all use cases of a certificate. When used for example by e-mail systems or servers talking to each other, those systems would not ignore the expired certificate in the chain and refused to connect.<\/p>\n

If you use a Comodo\/Sectigo certificate and have seen problems starting May 30th, you don’t need to replace your own certificate. It is sufficient to remove the expired certificate from the chain of intermediate certificates (also called “CA certs”). These are the correct chain certificates for the most commonly used certificates that are affected:<\/p>\n