Performance of Letsencrypt on Windows & IIS, vs commercial certificates?


#1

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?


#2

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.


#3

@mikebrandy

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


#4

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.


#5

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!


#6

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.


#7

How did the GoDaddy intermediates get trusted in the absence of the GoDaddy root?


#8

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:

  • Public key X with common name Y, signed by private key X (i.e., self signed root certificate, issuer and common name is the same);
  • Public key X with common name Y, signed by private key Z (i.e., cross signed intermediate certificate where Z corresponds with the key from the root certificate which has issued this cross signed certificate).

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:

  • check the chain up to the certificate X and check if it is in its root certificate store. If it finds the self signed root certificate X, it’s fine. If not, it has to continue:
  • check the chain up to the certificate Z and check if it is in its root certificate store.

As you can see above, the client always checks up to a root certificate, even if it’s only “half way” up the chain. :slight_smile:


#9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.