![]() 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. (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.)įor example, older versions of OpenSSL were very strict about which certificates could act as trust roots. a CA can simultaneously be a root and be cross-signed by another CA.īut 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. In theory, is completely legal for a certificate to validate through multiple chains, e.g. It could be that those systems do recognize Sectigo as a root CA in its own right. To fix this, you have to switch to another CA which those systems recognize as a root (check /etc/ssl/certs). 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. 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. 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. 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. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |