Generated cert signed by external CA cert returns cert that can't be validated against CA #195
Comments
brocaar
changed the title
|
I believe the issue here is with respect to how rcgen handles subject and authority key IDs. The pre-existing The Downstream the generated @brocaar Can you speak at all about how the original Ultimately I think this might be an API limitation that should be fixed in rcgen. The
and:
So I think at the end of the day it's reasonable to assume there are CA certificates that have chosen methods of generation beyond those in 5280/7093 and Rcgen might need a way to play ball by copying the exact value to use from the existing cert's choice. |
|
Also thank you for the very detailed bug report! It was quite helpful :-) |
|
Thanks for looking into this @cpu! This is the command that I used to generate the CA cert: |
|
@cpu I can confirm that creating a CA using Command: This creates two files:
`ca-csr.json`:{
"CN": "example.com",
"key": {
"algo": "rsa",
"size": 2048
}
}The resulting key-file must be converted to In this case the original CA cert contains: OpenSSL textual outputThe CA cert as printed by the Rust example: OpenSSL textual output: |
|
Thanks for the extra info - I think all the mysteries are resolved now and we just have to think about what actions to take.
Tl;dr - the other software wasn't using a RFC 7093 scheme. It was using SHA1 in the way 5280 originally described. The good news is there's no extra bug here as far as I can tell: just the API limitation mentioned before. Your original certificate was generated with OpenSSL and I confirmed it uses the full 160 bit SHA1 digest over the public key info to compute its subject key IDs (the original RFC 5280 recommendation). It turns out that CFSSL does the same. If I patch rcgen's So I think there are two things to consider here:
P.s. I hope you don't mind, I edited your previous comments to create some collapsed sections so we don't sprain our wrists scrolling to the bottom of this issue :-D |
|
If SHA1 is still used in the wild for these purposes, then we can't make SHA1 a non-feature like rustls has many, which is sad, but we'll have to add it. Also agree with the idea of adding a way to override SKI (AKI should always be that of the signer certificate), so +1 to both:
Also quite interesting that recent OpenSSL still uses SHA-1, and it seems to be hardcoded. I wonder whether there is an upstream issue about that, we are soon going to have 2024 :). |
If using from_ca_cert_der/_pem, the key_identifier_method would always be set to Sha256, which is not always true. If using OpenSSL for example SHA1 would be used. If the provided CA certificate contains a SubjectKeyIdentifier extension, then this change tries to detect the correct method. As well, this adds support for the SHA1 method as this is (still) being used by for example OpenSSL and cfssl. Fixes rustls#195.
|
@cpu and @est31, thanks again for looking into this and explaining what is going on. I have created a pull-request which:
Some initial testing looks promising:
Validation: |
If using from_ca_cert_der/_pem, the key_identifier_method would always be set to Sha256, which is not always true. If using OpenSSL for example SHA1 would be used. If the provided CA certificate contains a SubjectKeyIdentifier extension, then this change tries to detect the correct method. As well, this adds support for the SHA1 method as this is (still) being used by for example OpenSSL and cfssl. Fixes rustls#195.
If using from_ca_cert_der/_pem, the key_identifier_method would always be set to Sha256, which is not always true. If using OpenSSL for example SHA1 would be used. If the provided CA certificate contains a SubjectKeyIdentifier extension, then this option will be automatically set. Fixes rustls#195.
If using from_ca_cert_der/_pem, the key_identifier_method would always be set to Sha256, which is not always true. If using OpenSSL for example SHA1 would be used. If the provided CA certificate contains a SubjectKeyIdentifier extension, then this option will be automatically set. Fixes rustls#195.
If using from_ca_cert_der/_pem, the key_identifier_method would always be set to Sha256, which is not always true. If using OpenSSL for example SHA1 would be used. If the provided CA certificate contains a SubjectKeyIdentifier extension, then this option will be automatically set. Fixes rustls#195.
If using from_ca_cert_der/_pem, the key_identifier_method would always be set to Sha256, which is not always true. If using OpenSSL for example SHA1 would be used. If the provided CA certificate contains a SubjectKeyIdentifier extension, then this option will be automatically set. Fixes rustls#195.
If using from_ca_cert_der/_pem, the key_identifier_method would always be set to Sha256, which is not always true. If using OpenSSL for example SHA1 would be used. If the provided CA certificate contains a SubjectKeyIdentifier extension, then this option will be automatically set. Fixes rustls#195.
If using from_ca_cert_der/_pem, the key_identifier_method would always be set to Sha256, which is not always true. If using OpenSSL for example SHA1 would be used. If the provided CA certificate contains a SubjectKeyIdentifier extension, then this option will be automatically set. Fixes #195.
Summary
rootCA.crt+rootCA.key)outCA.crtand client-certificate toclientCert.crtclientCert.crtvalidated againstrootCA.crt== invalidclientCert.crtvalidated againstoutCA.crt== validIt looks like the
rcgen::Certificateinstance that I create from therootCA.crt+rootCA.keyis not complete. As you can see below, the printed CA certificate (stored asoutCA.crt) is not equal torootCA.crt.rootCA.crtcontains:outCA.crtcontains:clientCert.crtcontains:The
X509v3 Authority Key Identifierof theclientCert.crtmatches theX509v3 Subject Key Identifierof theoutCA.crtbut not ofrootCA.crt, which I think is the root of the issue, but I'm not sure what I'm doing wrong.Looking at different issues in this repository, the code below seems the suggested way to load an external CA certificate, but it looks like I'm missing something....
Files
(The certificates below were created for testing purposes, nothing sensitive)
main.rsmain.rs
rootCA.crtrootCA.crt
rootCA.keyrootCA.key
Example output
Example output
CA CERTIFICATE->outCA.crtCLIENT CERT->clientCert.crtTests
Verify against original
rootCA.crtfails:Note that the CA certificate that is printed by the above Rust code (
ca.serialize_pem().unwrap()) is different fromrootCA.crt. If we validate against the CA certificate printed by the above Rust code:OpenSSL info
rootCA.crtrootCA.crt
outCA.crtoutCA.crt
clientCert.crtclientCert.crt
The text was updated successfully, but these errors were encountered: