I manage hosting for a security oriented website managed by a rather large blue-chip company. They had 3rd party security experts scan our setup and got back to us with a red flag (in their opinion) regarding our LetsEncrypt certificate. This is what they wrote specifically:
Your certs include TLSv1.0, weak ciphers with a bitlength of less than 128, as well as weak algorithms such as DES and CBC3.
My initial gut reaction is: Well, LetsEncrypt is backed by giants of the industry, so they wouldn’t be issuing crappy certificates!
But I have to defend our choice of LetsEncrypt or recommend an alternative - so, can anybody here shed some light on this?
Are they wrong? If not, is this anything to worry about? If so, why not?
Yes. Your certificate has nothing to do with the issues noted. Those are (potentially) valid issues--you should be using a good selection of protocols and cipher suites--but they don't relate to your certificate. The only thing that's determined by your certificate is the type and length of your private key, but even the defaults on that are ample for most purposes.
To elaborate, your web server configuration is responsible for cipher and protocol selections. What web server software are you using? There are lots and lots of resources online to help you configure your webserver for modern ciphers and protocols. Sometimes slightly less secure ones are left available by companies balancing backwards compatibility with security, as older operating systems and browsers are incompatible with some newer protocols.
In this specific case we are using Apache but we run Nginx servers as well
This makes little sense to me - doesn’t the certificate used dictate the ciphers and valid bitlengths? Why should it matter what Apache is configured to “accept” if the cert used doesn’t support it?
So is this essentially a case of “IF the webserver had a crappy cert installed, in theory the webserver would be able to support it”
But in our case this is obviously a moot point? Meaning, should I take some action here, or just communicate this back to them?
Yeah, all the heavy lifting is done by the server configuration. The cert does play a role, but it's a small role (if you were able to generate a cert with a 256-bit private key, for example, your security would be very weak--but Let's Encrypt doesn't allow such weak private keys). But protocol selection, cipher suite, etc., are all handled by your server configuration, and those are the issues you mentioned.
By the way, in non-TLS1.3 ciphers, the certificate dictates the choice between EDSA or RSA in the complete name and designation of the “cipher suite”. (Because this depends on the used public key algorithm embedded in the certificate.) In TLS1.3, this part is left out in the “cipher suite” name.
This is a slight mis-phrasing, which you probably picked up from your 3rd party security experts. They said:
What they should have said was "Your TLS configuration includes TLSv1.0, weak ciphers, etc".
This can certainly all be a bit confusing because some of the things that affect security are in fact in the certificate. If they had said "Your certificates use the SHA-1 algorithm and 1024-bit RSA keys," that would be a serious problem with the certificate rather than with your TLS configuration. Fortunately, Let's Encrypt does not issue certificates with either of those problems, and all of the problems that you were notified of are purely TLS configuration problems.
"weak ciphers with a bitlength of less than 128, as well as weak algorithms such as DES and CBC3" - this refers to the symmetric cipher used to encrypt the traffic between the server and the client. The cipher is chosen by agreement between the client and server, and the key is randomly generated for each session. Which ciphers the server will agree to use is a matter of local configuration.
The certificate itself uses only asymmetric (public/private) key cryptography. You can see in plain text what's actually inside the certificate with the following command:
openssl x509 -in filename.pem -noout -text
The essential fields are:
the name of the subject (e.g. the domain name for a server cert)
the subject's public key
a serial number and valid from/to dates
a signature covering the entire certificate, signed using the CA's private key
It's a document from the CA saying: "I declare that whoever holds the private key that corresponds to this public key, has this name".
When you connect to a webserver, you learn its public key, and it is able to prove cryptographically that it possesses the corresponding private key, using an RSA or ECDSA exchange.
The certificate itself is then validated by:
checking the signature using a local copy of the CA's public key
checking the current date is within the validity range
checking the serial number is not on a revocation list periodically published by the CA
A "signature" is a hash of the document, encrypted with the CA's private key. To validate, you decrypt it using the CA's public key and compare against a locally-generated hash of the document.
Many details elided but that's the main points in a nutshell
