Hodie XV Kal. Iun. MMXI, Alex Bergmann scripsit: > On 05/18/2011 11:17 AM, Erwann ABALEA wrote: > >Bonjour, > > > >Hodie XV Kal. Iun. MMXI, Jean-Ann GUEGAN scripsit: > >> Hi ! > >> > >> It’s possible to renew a Certificate Autority or extend the date > >> validity > >> ? > > > >These 2 options are possible. > > > >"Recertify" (i.e. sign the same certificate, but change the serial > >number and validity dates) is the least problematic solution, as the > >same public key will be used to validate the certificates and CRLs. > > > >"Renew" (i.e. create a entirely new certificate, strictly keeping the > >same exact subject DN, changing the key, validity dates, and > >potentially the extensions) is covered by the X.509 standard (a CA is > >a name, not a certificate). Sadly, you can't be sure it's correctly > >dealt with by verifiers. The new objects (certificates and CRLs) will > >be signed by the new CA key, the CRLs will cover both "old" and "new" > >certificates (by old, I mean those signed by the old CA certificate). > >If your CA is a root, and you want RFC5280 compliance, you MUST > >produce one CRL for each root CA certificate (and adapt the > >crlDistributionPoints). > > There seems to be a problem with this if you have AKID and SKID in > place. Certificates signed with the "old" Root Certificate will be > bound to the "old" Root Certificate serial number. You can verify > this with the output of "openssl x509" at the "X509v3 extensions" > section.
"old" end-user certificates can only be verified by the "old" CA certificate, of course (in case the CA is "renewed", with its key changed, etc). > The only way I found was to give the new Root Certificate the same > serial number as the previous one. That's forbidden by X.509 standard. And the serial number has nothing to do with the SKI/AKI. > openssl req -new -x509 -days 1000 -key cakey.pem \ > -set_serial <old id in decimal> -out new_cacert.pem > > After that, verification of already signed certificates is working > fine with the old and new Root Certificate. Did you change the private key of the CA? If not, then: - the SKI of the new CA certificate will be the same as the old certificate (it's a *Key* identifier, and is generally constructed from the public key) - you don't need to have the same serial number (remember, it's forbidden by X.509 standard) - you will be able to verify old end-user certificates with the new CA certificate (since the CA key didn't change), if the rest of the CA certificate permits it (validity dates, extensions). If you were in this situation, and only were able to verify end-user certificates if the new CA certificate had the same serial number as the old one, then I'm sure you made a mistake in your tests. -- Erwann ABALEA <erwann.aba...@keynectis.com> Département R&D KEYNECTIS ----- Press Control-Alt-$ to appease spirits. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
