https://issues.apache.org/bugzilla/show_bug.cgi?id=45708
--- Comment #10 from sektor <[email protected]> 2011-10-10 08:05:35 UTC --- Comment on attachment 27749 --> https://issues.apache.org/bugzilla/attachment.cgi?id=27749 patch for mod_ssl in order to support more than one crl issued by different CAs with the same subject In my company we have a root certification authority with a subCA. The PKI is based on Microsoft infrastructure (Certificate Service, Active Directory, etc). Last month, we have renewed (with new key pair) the subCA since in 6 months it will expire and now we have to manage two different CRLs: the first one is issued by the old subCA and the second is issued by the new subCA. Of course, the subject of the subCA is not changed. When we revoke a certificate issued by the old subCA the first CRL is updated and when we revoke a certificate issued by the new subCA the related CRL is updated. I don’t know if it is the right behavior but it sounds reasonable, however it is the only behavior possible for the Microsoft services. We have a lot of certificates issued with a high turnover (many revocations) so it is important for us to check both the CRLs. For this reason we have developed a patch starting from the patch provided by Erwann that unfortunately does not fit with our scenario. For that I described before, the usage of authority key identifier and subject key identifier, during the CRL verification process, can be helpful. So, the idea behind the patch is this: 1. Get authority key identifier (akid) from the current certificate 2. Get subject key identifier (skid) from the current certificate 3. For the CRL verification (first step), look for the CRL with the CRL issuer equal to certificate subject and CRL akid equal to certificate skid 4. For the revocation check (second step), look for the CRL with the CRL issuer equal to certificate issuer and CRL akid equal to certificate akid -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
