Greetings, I am reaching out to see if your certs support SHA384 and SHA512 hashing algorithms today. I have not been able to find documentation on the site hence the reach out. Please let me know. Thanks.
The question is fairly generic and I'm not sure what exactly it is aimed at. Certificates do not directly "support" hashing algorithms. Rather they are a primitive used in various algorithms that may be either used within or encoded in the certificate.
One of the most prominent fields within a certificate where hashing algorithms are involved is the signature algorithm field. This field indicates the signature algorithm used to sign the certificate (which involves a hash).
This field has to be based upon the issuing certificate, because it's signed with the issuer's key. While not technically required, a common method is to use a hash method that scales with the keylength: 2048 bit RSA keys use SHA-256, 3072 bit use SHA-384 and 4096 bit uses SHA-512. For ECDSA, P-256 means SHA-256, P-384 SHA384 and so on.
Let's Encrypt currently has two active issuers:
- For certificates signed by R3 (by default all certificates)
sha256WithRSAEncryptionaka RSASSA‐PKCS1‐v1_5 with SHA‐256. This is because R3 is a 2048-bit RSA key.
- For certificates signed by E1 (ECDSA leafs only; currently requires opt-in)
ecdsa-with-SHA384. This is because E1 is a P-384 key.
If your question was aimed at something different than the signature algorithm, please specify and we're happy to answer.
(Also, for clarification: The above signature algorithms are fixed and cannot be changed by the subscriber)
TL;DR: you need to ECDSA key with account opt in for ECDSA whitelist
I don't think this is very common. E.g. ISRG Root X1 is 4096-bits RSA, and both its self-sig and its signatures on R3/R4 intermediates are SHA-256.
For ECDSA, this is indeed the case; these are formal CA/B requirements.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.