I am having a similar problem here:
For some reason I need to renew/extend a intermediate certificate within a
chain. Without setting the old serial number, all its descending certs
verification will fail when use 'openssl verify'.

So the question is: Is there anyway to issuing a new signing certificate
with a different serial number but not breaking the original chain?

Thanks,
Peter



On Mon, May 23, 2011 at 8:35 AM, sandeep kiran p <[email protected]>wrote:

> If this isn't resolved yet, can you post the contents of the old cert, new
> cert and the user cert?
>
> -Sandeep
>
>
> On Fri, May 20, 2011 at 8:33 PM, Alex Bergmann <[email protected]> wrote:
>
>> Hi Erwann!
>>
>> On 05/19/2011 10:20 AM, Erwann ABALEA wrote:
>>
>>  "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).
>>>
>>
>> I didn't "renew" the CA certificate, I've used the existing private key
>> to create thr new one.
>>
>> >> 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.
>>
>> I agree, using the same serial number seems to be not valid.
>>
>> But, according to RFC 3280 the Authority Key Identifier "MAY be based on
>> either the key identifier ... or on the issuer name and serial number".
>>
>> My Root CA Certificate and user certificates shows exactly this
>> information:
>>
>> Root CA Certificate:
>> --------------------
>> X509v3 Subject Key Identifier:
>>   A8:C3:14:22:3A:48:50:66:78:89:97:02:A8:B0:CE:D3:EE:FC:0F:1E
>> X509v3 Authority Key Identifier:
>>   keyid:A8:C3:14:22:3A:48:50:66:78:89:97:02:A8:B0:CE:D3:EE:FC:0F:1E
>>   DirName:<Root CA Subject/Issuer DN>
>>   serial:1C:26:30:4D:53:64:7A:83
>>
>> User Certificate:
>> -----------------
>> X509v3 Subject Key Identifier:
>>   7C:F7:66:B5:A4:83:42:1A:FF:AA:CB:0D:07:37:8A:81:E7:48:B8:1D
>> X509v3 Authority Key Identifier:
>>   keyid:A8:C3:14:22:3A:48:50:66:78:89:97:02:A8:B0:CE:D3:EE:FC:0F:1E
>>   DirName:<Root CA Subject/Issuer DN>
>>   serial:1C:26:30:4D:53:64:7A:83
>>
>> So the Root CA Certificate serial number is part of my X509v3 Authority
>> Key Identifier.
>>
>> > 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)
>>
>> I didn't change the private key, so the X509v3 Subject Key Identifier is
>> always the same, right.
>>
>> >   - you don't need to have the same serial number (remember, it's
>> >     forbidden by X.509 standard)
>>
>> Right, I've check that with RFC 2459.
>>
>>   - 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).
>>>
>>
>> This seems to be a problem if you're using openssl to verify the
>> certificate. I've generated a new CA certificate with the same CA key as
>> before. But only the verification with the "old" CA certificate was working.
>>
>> #> openssl verify -CAfile newca.pem user_cert.pem
>> user_cert.pem: <User DN>
>> error 20 at 0 depth lookup:unable to get local issuer certificate
>>
>> According to old threads on this list this message has something to do
>> with the AKID/SKID.
>>
>> > 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.
>>
>> I agree, maybe I did something wrong here. What steps would I have to do
>> to recertify my CA with openssl?
>>
>>
>> Cheers,
>> Alex
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    [email protected]
>> Automated List Manager                           [email protected]
>>
>
>

Reply via email to