Fail to do revocation checking on hosts, other than on google.TLD (and similar) (#1046) #1057
Comments
drwetter
changed the title
|
I tried banggood.com and csdn.net, and they are just broken. The cRLDistributionPoints extensions in the certificates contain http://cdp1.digicert.com/ssca-sha2-g6.crl. If you use There is nothing we can do about it, except perhaps report the error. |
This PR fixes problems with check_revocation_crl() sometimes reporting that a certificate is revoked even when it isn't, and with check_revocation_ocsp() sometimes reporting "error querying OCSP responder" even if the OCSP responder provided a good response. The most common reason for this to happen is that OpenSSL cannot validate the server's certificate (even without status checking). PR testssl#1051 attempted to get status checking to work even in cases in which the server's certificate could not be validated. This PR instead addresses the problem by not checking status if determine_trust() was unable to validate the server's certificate. In some cases the server's certificate can be validated using some, but not all of the bundles of trusted certificates. For example, I have encountered some sites that can be validated using the Microsoft and Apple bundles, but not the Linux or Mozilla bundles. This PR introduces GOOD_CA_BUNDLE to store a bundle that could be used to successfully validate the server's certificate. If there is no such bundle, then neither check_revocation_crl() nor check_revocation_ocsp() is run. When check_revocation_crl() and check_revocation_ocsp() are called, the status checks within them closely match the validation check in determine_trust(), which helps to ensure that if the check fails it is because of the status information. As noted in testssl#1057, at least one CA provides incorrect information when the CRL is downloaded, so validation could fail for a reason other than the certificate being revoked. So, this PR adds a check of the reason that validation failed and only reports "revoked" if the validation failed for that reason. As noted in testssl#1056, it is not possible to perform an OCSP query without access to the certificate issuer's public key. So, with this PR check_revocation_ocsp() is only called if the server's provided at least one intermediate certificate (i.e., the issuer's certificate, which contains the issuer's public key).
|
Can close this now. According to my checks on the Alexa Top 1k we're fine now. There a a few (1%) which don't seem ok. A part of it is just a trust issue (certificate <--> hostname) other parts are more tricky and either broken OCSP/CRL endpoints or misconfiguration of supplied certificates on the server side. |
Those hosts also show a problem (hosts from Alexa Top-something):
related tickets: #254, #1051
The text was updated successfully, but these errors were encountered: