[gnutls-dev] [PATCH] Authority key ID bug in certtool
Simon Josefsson
simon at josefsson.org
Wed Jan 31 18:36:40 CET 2007
Hi again. Using the SKI from the CA seems to be the right thing,
although I modified your patch to make it fall back to a locally
computed KID if reading the SKI from the CA fails (which would happen
for CAs that doesn't have any SKI, for instance..).
The replies on the PKIX list also indicate that OpenSSL's behaviour
here is buggy, though, so if you care about that, you'd might want to
report it. Non-matching AKI/SKI shouldn't cause verification
failures.
/Simon
Simon Josefsson <simon at josefsson.org> writes:
> Hi Dale! Thanks for your detailed report, a quite interesting bug
> indeed! I'm sorry for the delay.
>
> I think this problem warrants some even more detailed discussion.
> First, as far as I can tell, RFC 4158 section 3.5.12 suggests that
> OpenSSL is buggy here. Non-matching KID's should not cause
> verification failures: "May be used to eliminate certificates: No".
> Are you sure OpenSSL is rejecting the chain because of this problem
> alone? It looks that way, but I'm not familiar with OpenSSL.
>
> Second, it is not clear to me whether it is right to copy the SKI from
> the CA into the AKI in the EEC. I've posted a question to the PKIX
> list, but it hasn't showed up in the archives yet. To me, the spec
> seem a bit unclear.
>
> There's also the question what to when there is no AKI in the CA, but
> RFC 3280 says that you MUST add one so I guess that is what we'll do.
> OpenSSL appear to break on this as well.
>
> Thanks,
> Simon
>
> Dale Sedivec <dale-keyword-gnutls.5670f1 at codefu.org> writes:
>
>> Greetings,
>>
>> When certtool is signing a certificate, it calculates the CA
>> key's ID and uses that to fill in the X.509 v3 authority key ID
>> extension. This results in certtool generating invalid certificates
>> when the CA certificate has a different subject key ID than the one
>> that certtool calculated for the CA key (i.e., this happens when
>> something other than certtool was used to make the CA certificate,
>> such as OpenSSL).
>>
>> To reproduce with OpenSSL:
>>
>> openssl req -days 3650 -nodes -new -x509 -keyout ca.key -out ca.crt
>> # Answer the resulting questions any way you would like.
>> certtool --generate-privkey > user.key
>> certtool --generate-certificate --load-privkey user.key \
>> --load-ca-certificate ca.crt --load-ca-privkey ca.key > user.crt
>> # Answer more questions.
>> openssl verify -issuer_checks -CAfile ca.crt user.crt
>>
>> "openssl verify" should bomb with some errors, the significant
>> ones being:
>>
>> error 30 at 0 depth lookup:authority and subject key identifier mismatch
>> error 20 at 0 depth lookup:unable to get local issuer certificate
>>
>> When "openssl verify" succeeds, the last line should say
>> simply "OK". certtool seems not to check/care about the
>> subject/authority key ID mismatch:
>>
>> $ cat user.crt ca.crt | certtool --verify-chain
>> Certificate[0]:
>> Issued by: C=GB,ST=Berkshire,L=Newbury,O=My Company Ltd
>> Verifying against certificate[1].
>> Verification output: Verified.
>>
>> Certificate[1]: C=GB,ST=Berkshire,L=Newbury,O=My Company Ltd
>> Issued by: C=GB,ST=Berkshire,L=Newbury,O=My Company Ltd
>> Verification output: Verified.
>> $
>>
>> I've included a patch I made against GNU TLS 1.2.11 to use the
>> CA's subject key ID when filling in a new certificate's authority key
>> ID. When applied here certtool generates certificates that pass
>> "openssl verify."
>>
>> Dale
>>
>>
>> --- src/certtool.c.orig 2006-12-16 18:22:04.000000000 -0500
>> +++ src/certtool.c 2006-12-16 18:58:19.000000000 -0500
>> @@ -524,7 +524,12 @@
>> */
>> if (ca_crt != NULL) {
>> size = sizeof(buffer);
>> - result = gnutls_x509_crt_get_key_id(ca_crt, 0, buffer, &size);
>> + result = gnutls_x509_crt_get_subject_key_id(ca_crt, buffer, &size, NULL);
>> + if (result < 0) {
>> + fprintf(stderr,
>> + "generate_certificate: can't read CA subject key ID\n");
>> + exit(1);
>> + }
>> if (result >= 0) {
>> result =
>> gnutls_x509_crt_set_authority_key_id(crt, buffer, size);
More information about the Gnutls-dev
mailing list