Add AKI to child CA certificates

[illia-v]

In urllib3's tests urllib3/urllib3#3366 (comment), I discovered that child CA certificates generated by trustme do not pass verification with ssl.VERIFY_X509_STRICT enabled by default in CPython 3.13.0a5 python/cpython#112389.

$ openssl verify -x509_strict -CAfile cacert.pem -untrusted client_intermediate.pem client_intermediate.pem
O = trustme v1.1.0, OU = Testing CA #0hrzBwpZFQa95Z4M
error 85 at 1 depth lookup: Missing Authority Key Identifier
error client_intermediate.pem: verification failed

Adding the AKI extension to child CA certificates seems to fix the verification error.

[pquentin]

Thanks Illia! Is there a downside to enable it unconditionally?

[illia-v]

Thanks Illia! Is there a downside to enable it unconditionally?

I believe root CA certificates are not supposed to have any AKI

[pquentin]

Thanks! LGTM.

[trio-bot]

Hey @illia-v, it looks like that was the first time we merged one of your PRs! Thanks so much! 🎉 🎂

If you want to keep contributing, we'd love to have you. So, I just sent you an invitation to join the python-trio organization on Github! If you accept, then here's what will happen:

• Github will automatically subscribe you to notifications on all our repositories. (But you can unsubscribe again if you don't want the spam.)

• You'll be able to help us manage issues (add labels, close them, etc.)

• You'll be able to review and merge other people's pull requests

• You'll get a [member] badge next to your name when participating in the Trio repos, and you'll have the option of adding your name to our member's page and putting our icon on your Github profile (details)

If you want to read more, here's the relevant section in our contributing guide.

Alternatively, you're free to decline or ignore the invitation. You'll still be able to contribute as much or as little as you like, and I won't hassle you about joining again. But if you ever change your mind, just let us know and we'll send another invitation. We'd love to have you, but more importantly we want you to do whatever's best for you.

If you have any questions, well... I am just a humble Python script, so I probably can't help. But please do post a comment here, or in our chat, or on our forum, whatever's easiest, and someone will help you out!

[woodruffw]

(Author of the CPython patch that tripped this; thanks @sethmlarson for bringing this to my attention!)

Yes, adding the AKI extension to intermediate CA certificates is the appropriate approach here, since it'll bring the certs here into closer alignment with RFC 5280 (which is what VERIFY_X509_STRICT roughly maps to).

I believe root CA certificates are not supposed to have any AKI

FWIW, this is RFC 5280's exact language on AKIs in self-signed (i.e. "root") certificates:

The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate certification path construction. There is one exception;
where a CA distributes its public key in the form of a "self-signed"
certificate, the authority key identifier MAY be omitted.

In other words: all certs can have an AKI, but it's optional for roots. As such, there's no error in generating root CA certs with an AKI extension; it just has no effect 🙂

Ref: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1