Hi, how is the performance of a Letsencrypt certificate on Windows (Windows 2008 and 2012 server), on IIS, versus a cheap commercial certificate? (ie. how would Letsencrypt perform versus a cheap $10/$15 per year Comodo certificate).
Assuming I set up the certificate properly, is the performance almost negligible?
What exactly do you mean with “performance”? Speed? For speed the chosen key size would be the important factor, not the certificate issuer. And the user can choose the key size, that isn’t enforced by Let’s Encrypt.
as @osiris said the performance of TLS is dependent on algorithm selection and the size of the private key
there is a difference between rsa keys vs ecc keys which is worthwhile exploring
once again given your last post i would suggest that you stick to RSA certificates
if you are interested a comparison between ECC and RSA TLS can be found here: https://www.symantec.com/content/en/us/enterprise/white_papers/b-wp_ecc.pdf
In summary:
Its more about the web server, the cryptography engine used and the selection of algorithm rather than the certificates themselves. Certificates in PKI do not do the encryption. It’s the algorithms in use with the private key that matter.
Andrei
One additional detail is that the Let’s Encrypt certificates have just one intermediate CA in the chain. In contrast, most existing commercial CA have two intermediate CA - they had to add an additional one to support SHA256 certificates.
Now, having one more intermediate CA in the commercial certs’ chain doesn’t obligatory mean decreased performance - it really depends on how the client is configured to check the certificate or the whole chain.
Generally, I would prefer a certificate with less intermediates - one intermediate is the minimum for public use, and LE stands up here and is a better choice in my opinion, regardless of the price.
Euh, I'm hoping every client will check the whole chain. Otherwise, I could generate a self-signed root, issue a valid intermediate from that root and a valid end-leaf certificate with that intermediate. The end-leaf cert will be valid when checked with the intermediate, but if the chain checking stops there, how would the client know it was from a valid root? Or in this case, my own self-signed? It doesn't.. So it always needs to check the whole chain up to a trusted root!
If the Intermediate CA is in the client's trusted CA or Intermediate CA list, the client will trust the certificates issued by that Intermediate CA. The best way to test this is to remove the Godaddy root CA from your client's list of root CA (for example) and make sure you still have the GoDaddy Intermediates - if you still trust sites with Godaddy issued certs, then the client is not checking the whole chain.
In your case, you can generate a self-signed and intermediate, but the clients will not have the intermediate (and the root of course) in their trusted CA list and the check will fail at the Intermediate.
The opposite is valid as well - if you have the Root CA in the client's trusted Root CA list but do not have the Intermediate, the check will fail and the client will not trust the certificate.
How did the GoDaddy intermediates get trusted in the absence of the GoDaddy root?
What kind of list? I only know of a root certificate store.
The only way I can think of that a chain doesn't need to chain 100 % up to the top if one of the intermediate certificates is also a root certificate (which is in the root certificate store of the browser/client).
That's possible because any self signed root certificate can also be cross-signed by another root certificate. So you'd end up with two certificates with the same CN and public key:
So if you have an end leaf certificate signed by the private key X (with the corresponding issuer of course), the client also has two options:
As you can see above, the client always checks up to a root certificate, even if it's only "half way" up the chain. 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.