| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Thanks for the PR. Merged with minor revisions. Now up on https://www.bouncycastle.org/betas |
Sorry, something went wrong.
…n indirect CRL by issuer as well as serial number, and look beyond the JDK's own serial number lookup, which sees only the CRL issuer's entries; CRL.isRevoked() no longer stops at another issuer's entry for the same serial number, and the jdk1.4 validators read an entry's certificate issuer through the class the provider's CRLs actually use, relates to github #2464.
| Back | FazBrowse Home | New Git URL |
getCertStatus in the three cert path validator copies found a certificate's entry in an indirect CRL with getRevokedCertificate(serial) and compared only the issuer of whichever entry came first, so when another issuer's entry with the same serial number preceded the certificate's own (a serial number is only unique within its issuer, and aggregating issuers is what an indirect CRL is for) the revoked certificate validated; found reading the RFC 5280 sec. 5.3.3 handling in the validators, the lookup now checks every entry carrying the serial number against the issuer it applies to, X509CRLImpl implements the JDK's getRevokedCertificate(X509Certificate) the same way instead of inheriting the single-issuer default, and X509CRLEntryObject.equals keeps two identically encoded entries under different issuers apart so getRevokedCertificates() no longer drops one, with IndirectCRLSerialCollisionTest covering the provider validator, X509RevocationChecker and the direct lookup, failing without the change.
AI tooling was used to help prepare this change.