code.jquery.com use a TLS/SSL certificate no more valid

[fcomte]

The root certificate authority has expired at 30 may 2020

https://www.ssllabs.com/ssltest/analyze.html?d=code.jquery.com&s=2001%3a4de0%3aac19%3a0%3a0%3a1%3ab%3a1b&latest

[brianwarner]

Thanks for raising this, @fcomte. This appears to be a general issue affecting the legacy AddTrust root cert, which was replaced in 2010 by the COMODO RSA Certification Authority. As long as a browser/OS has an alternate path to establish the chain of trust (meaning that the cert store has been updated since 2010), this shouldn't cause SSL failures.

In the event that it does affect a system, it will likely affect a great many of the client's SSL connections.

https://www.xolphin.com/support/Rootcertificates/Phasing_out_Addtrust_External_CA_Root_certificate

[mgol]

Closing per Brian’s comment.

[Patate687]

This should not be closed, seems like your ADC(ngnix?) is forcing a link to the old CA Root certificate.

We have no problem with https://jquery.org which expose the same certificate as you do on code.jquery.org The CA Root certificate sent on this exposure is Good

Also, for improvement, I would recommand you to not send the CA Root Certificate in chain certificate and let the servers discovers them by themself. Can't find the right link to the documentation about that, will update as soon as I get it.

[mgol]

@brianwarner the number of duplicates & comments like the one above by @Patate687 suggest to me the issue affects more than just very old systems.

I’ll reopen it for now for further investigation & to reduce the number of duplicates a bit as people are more likely to look at open issues.

[Patate687]

More info on full chain : https://discussions.qualys.com/docs/DOC-1931

Certificate chains that are too long; Sites often include more certificates in the handshake than necessary. Of those, most include one extra certificate, and that is the actual trusted root certificate (which browsers already have in their storage). This last certificate is not needed for the validation process. Having an additional certificate in the chain wastes bandwidth and decreases overal performance slightly. A small number of sites will include a very large number of certificates as a result of misconfiguration. Such sites will typically suffer significant performance issues and need to be reconfigured.

[armyofda12mnkeys]

One of our websites was down because of this. The Enterprise Network Firewall was blocking the jquery resource since it had a 'invalid cert' higher up on the cert chain. Temporarily for now, our network-admin has put jquery.com on a whitelist but will watch this issue to see when the issue is fixed so we can remove that one-off rule.

[Patate687]

Just to add to this, your cloudflare configuration is sending the good ca root certificate but not the ngnix exposing this website...

[brianwarner]

Thank you @Patate687 and @armyofda12mnkeys, I'm on this and will track down the fix asap.

[bigben386]

Can you please make sure there are no expired intermediate certs in the chain too? This also causes issues for us. Thanks.

[brianwarner]

Folks, I believe this is taken care of. I've scrubbed the expired intermediary (the source of the original issue). Please let me know if you still see issues.

https://www.ssllabs.com/ssltest/analyze.html?d=code.jquery.com&s=2001%3a4de0%3aac19%3a0%3a0%3a1%3ab%3a1b&latest

[Patate687]

Holy cow! I think you did removed the link to the root CA dont you? 😁

[brianwarner]

The new trust chain is jQuery cert (the cert) -> COMODO RSA Domain Validation Secure Server CA (distributed in the chain) -> COMODO RSA Certification Authority (in the system/browser/etc. trust store)

[Patate687]

Cool, will this works for blog.jquery.com too?

[brianwarner]

Hmm, I think that's independent of this. I'll have a chat with @mgol about it.