I just downloaded isrgrootx1.pem, lets-encrypt-x1-cross-signed.pem, and lets-encrypt-x2-cross-signed.pem. Thank you for using SHA256 instead of SHA-1. I thought I would inquire why you picked 2048-bit RSA for your CA. I understand that 2048-bit RSA is probably sufficient for most websites (equivalent in strength to 112-bit symmetric cryptography), but I would think you would want the CA to be a bit stronger, especially since you have an expiration date for 2035 on isrgrootx1.pem (2020 for X1 and X2). For example, the NSA requires 3072-bit RSA (equivalent to AES128 in strength) or P-384 (equivalent to AES192 in strength) with SHA384 for TOP SECRET, which would seem to be the appropriate equivalent for a CA.
When you offer EC certificates, which curves will you use for Root, X1/X2? Given the smaller size of EC certs, I think you can afford P-512 or P-384 for Root.
(equivalent strengths taken from NIST SP800-57part1rev3 Table 2)
It looks like their root is using RSA 4096 with SHA-256 hashing, while the intermediates are using RSA 2048 with SHA-256.
I am not entirely sure how this changes the attack surface. If the root is 4096 bit but the intermediate is 2048 bit, can you just factor the intermediate and entirely circumvent the need to deal with the root’s larger key size?
Many other CAs are still using SHA-256 hashing, the main exception being Comodo, which has gone with SHA-384 for one of their newer chains.
Yes, AFAIK in a certificate hierarchy always the weakest cert is attackable.
Basically the size of the root cert does not matter that much, because it's not send over any connection (expect for the actual cross-signed variant), but just stays in the root stores of Browsers and OSes. As disk space does hardly matter there the cert could use a very large key size.
Of course this changes if you talk about intermediate certificates.
Generally only the signature (SHA-1 or SJHA-265) of the root cert does not seem to matter. Don't ask me why*, but at least that's what SSLLabs always reports when a root cert uses SHA-1:
Weak or insecure signature, but no impact on root certificate
In SSL certificates the hash is used as a cryptographically secure summary, or “digest”, of the certificate. It allows the client to run its own hash computation and compare the answer it got to the hash contained in the certificate. If it matches then the client knows the certificate has not been modified in anyway (corruption or malicious means). If the two hash values do not check out its possible the certificate is a forgery from an attacker.
This is all done because the client can not just blindly accept any certificate it downloads from a webserver. So the end-entity and intermediate certs are all checked this way.
Root certificates do not come from the server (even if they are marked as “Sent by Server” in SSLLabs, the client just ignores it). The root is pulled from the devices local trust store. For that reason its inherently trusted and a hash check is not needed. This is why SSL Labs says “no impact on root certificate”.
A certificate consists of the actual server’s authority and other encryption relevant information, and a signature which you are ought to trust. You only trust it if you trust the signing CA OR you have that very certificate stored (automatic or manually) in your browser’s trust store. Since the Root CAs all are/have to be stored in the browser shipped, you’re implicitly trusting them.
However, the trust for any certificate transferred as you’re surfing is based on said signature, and the quality of the signature is based on the strength of the signing CA’s key*. So the better/worse any signing CA’s key is, the harder/easier it is for the bad guys to find out its key and fake any certificate to be approved by this CA.
*: another aspect is that the signature is not proving the authenticity of the certificate’s full server information but just about the SHA hash of its contents. That means, instead of attacking a signing CA’s key, Dr Evil could try to fake a server authority information in such a way that its SHA/SHA256 checksum matches one of any other certificate issued by this very signing CA. Since SHA-1 can be assumed broken for quite some time, research seems to have found a way to produce SHA-1 collisions quite easily these days, at least in pairs A SHA-1 freestart collision has occurred. It seems to be about time to get rid of SHA-1 certificates soon. However, this is not related to the cryptographic properties of the actual key used for signing which is the topic of this thread.