x509-cert: support for computing certificate fingerprints
Hi! I've got a Certitifacate and need the fingerprint, (SHA-1/SHA-256) of the certificates.
I've found the FingerprintBytes and corresponding implementation in the spki crate, but I have no idea how to get from one to another.
Can anybody here tell me: How to I get the fingerprint of a certificate?
Thx in advance!
We don't have anything built-in for this AFAICT, however you can look at how the spki crate computes a similar fingerprint and apply it to the whole certificate: https://github.com/RustCrypto/formats/blob/a0b4200/spki/src/fingerprint.rs#L17-L42
We should probably add such a feature so I will rename the issue title to reflect the potential new feature.
Thanks. I'll see if I can hack something together that computes the hash of a certificate. An easy to use function directly in the Certificates structures, would be preferred in the future.
Maybe it's a stretch, but I wonder if defining a trait that could be used for calculating cert fingerprints as well as key identifiers from SubjectPublicKeyInfo would be the thing to do. May also be useful for SignedAttributes in cms.
The logic for calculating fingerprints from spki could be extracted and generalized into der
What's the use for the fingerprint?
Would this be for building a trust-ca folder? (ala openssl rehash)
I believe the hash for that is the hash of the subject, not the full certificate itself. As for the SKI, it's fairly tied to spki
Validating of a binary was signed by a "trusted signer", e.g. a known certificate. It's very commen in the security field to do that. I've written a crate to check the authenticode signature of a PE file and then check if the signing certificate (identified by the hash) is known to be benign. https://crates.io/crates/cross-authenticode
For what it's worth, I have a fairly complete implementation of authenticode in https://github.com/nix-community/goblin-signing This is based on goblin, and up to date with latest spec (which adds padding to make sure you do not have a change of the hash once you append the signature).
I don't know how standard it would be to hash the certificate itself or how common that is. In my experience either the name or the spki gets hash (for different reasons (threat model!)). This is the first time I've seen someone hash the full certificate as it would usually be in a trust-anchor repository. All that to say, do you have any reference to as spec doing that?
All that to say, do you have any reference to as spec doing that?
It's sometimes referred to as certHash and is computed as SHA-1 of the entire DER serialization of the certificate, e.g. in RFC4210 (CMP): https://datatracker.ietf.org/doc/html/rfc4210
Or RFC4387: https://datatracker.ietf.org/doc/html/rfc4387#section-2.2
certHash Hash Search key derived from the SHA-1 hash of the certificate (sometimes called the certificate fingerprint or thumbprint).
RFC9480 updates CMP to support alternative hash algorithms to SHA-1: https://datatracker.ietf.org/doc/rfc9480/
That would then be in cmpv2 and would look something like https://github.com/RustCrypto/formats/pull/1766 ?
Sure, that's one usage, but certHash / "thumbprints" can be found elsewhere, e.g. the OpenSSL command line tooling, the Windows certificate manager UI, OCSP
https://github.com/RustCrypto/formats/pull/1766/commits/eaa26bd471aac3b30bc6e668c2c913aaf110480f then
Sure
@baloo I still think we should add a general method for calculating certHash in x509-cert itself
Something else than https://github.com/RustCrypto/formats/blob/53d2e3b34c38920d09c266896688ee006edd3571/x509-cert/src/certificate.rs#L432-L447 ?
Oh sorry, that’s fine