1. Let's start with killing the point I made in the last section. Nowadays it is possible to lock your domain to just CAs of your choosing using DNS-CAA. Suppose that you do trust Comodo, and don't trust other CAs, it is possible to request all CAs other than Comodo to not issue certificates for your domain. In theory. (Because DNS-CAA is not checked by browsers, only by issuing CAs. So a compromised CA could ignore this safeguard.)

   If you're willing to go through that trouble, then the question becomes: is Let's Encrypt actually less trustworthy? Or less secure? Trustworthiness is a hard one, how do you quantify that? All I can say is that in my perception Let's Encrypt is no less trustworthy than other CAs. As for the security of their validations, they are very similar to what commercial CAs do (for DV certificates anyway). See also this question.

   For what it's worth: the StackExchange network, which this site is a part of, currently uses Let's Encrypt certificates. Most people would never notice this, and if they did I sincerely doubt if it would mean much to them.

2. For a certificate to be meaningful, the issuing CA must be trusted by software vendors, otherwise the certificate is useless. I used Firefox as an example, but really you want the CA to be trusted by at least current and somewhat older versions of Firefox, Chrome, Windows, Mac OS X, iOS, and Android. And the dozens of smaller players. CAs worth considering (that includes ComodoSSL and Let's Encrypt) are trusted by all these entities.

3. If a CA misbehaves, or is revealed as untrustworthy, it will get removed from the various trust stores quickly enough to ruin the day of certificate owners. Two notable examples I know of are DigiNotar and StartCom/WoSign (check out the articles, they provide interesting insights in the trust dynamics!). So if you think Let's Encrypt will screw up, or will be dropped for some other reason, not using them will prevent you from getting caught in that particular fall-out.

4. Certificates employ some crypto math magic; the question is which crypto math magic? What if it's weak magic? This is actually a real concern, and CAs have shown to drag their feet on upgrading this, too. Luckily, browser vendors have picked up the slack by setting minimums here for certificates to be accepted. For example, certificates using RSA-1024 or SHA-1 are now rejected by most browsers, so any certificate that works in practice doesn't use these deprecated crypto primitives. The upshot is, it's pretty hard for any CA (Let's Encrypt included) to disappoint on this part anymore.

5. Before, I more or less said that all certificates are created equal. I lied, they're not. In particular, what I discussed up until now are "Domain Validated (DV) certificates", which are what the vast majority of websites use. They provide a measure of certainty that your browser is actually talking to the domain it shows in the URL bar. There are also "Organization Validated (OV)" and "Extended Validation (EV)" certificates, which require much more elaborate checks from CAs. In particular, you should only be able to get an EV certificate for somebank.com / SomeBank Inc., if you can actually prove you are SomeBank, Inc.

   EV certificates are a lot more costly to obtain (ballpark: hundreds of EUR/USD per year), and they may be rewarded with a green URL bar or padlock in the browser, maybe displaying "SomeBank, Inc." as well. Contrary to DV certificates, they also offer some guarantee as to who the website might actually belong to. The upside is, they may look more legit. The disappointment is, users rarely pay attention to them, so their effectiveness is limited. An attacker with a forged DV certificate can still impersonate the site, just without the extra visual clue an EV certificate may offer.

   So if you're a financial institution, you probably still want an EV certificate. For most things, it's overkill. But if you do need EV, Let's Encrypt isn't for you because they simply don't offer EV certificates.

6. Certificates are only valid for a limited time. Certificates from a typical commercial CA tend to be valid for one year, but I've seen anything from three months to three years. Let's Encrypt certificates are valid for 90 days, which is on the short side of that range, so you'll need to renew them often. For Let's Encrypt users, this is usually automated so that certificates are replaced every 60 days.

   Being able to automate renewal with widely available software is actually more pleasant than the yearly Oh shit my certificate expired? What's my login at the CA? How does this work again? ritual that most small sites seem to end up with at commercial CAs.

7. And finally, there's other benefits a paid CA might offer, such as commercial support, or a million-dollar SSL warranty. I have little faith in both of these aspects, but they are things that Let's Encrypt does not offer.

My head hurts... I had a question... I think?

1. Let's start with killing the point I made in the last section. Nowadays it is possible to lock your domain to just CAs of your choosing using DNS-CAA. Suppose that you do trust Comodo, and don't trust other CAs, it is possible to request all CAs other than Comodo to not issue certificates for your domain. In theory. (Because DNS-CAA is not checked by browsers, only by issuing CAs. So a compromised CA could ignore this safeguard.)

   If you're willing to go through that trouble, then the question becomes: is Let's Encrypt actually less trustworthy? Or less secure? Trustworthiness is a hard one, how do you quantify that? All I can say is that in my perception Let's Encrypt is no less trustworthy than other CAs. As for the security of their validations, they are very similar to what commercial CAs do (for DV certificates anyway). See also this question.

   For what it's worth: the StackExchange network, which this site is a part of, currently uses Let's Encrypt certificates. Most people would never notice this, and if they did I sincerely doubt if it would mean much to them.

2. For a certificate to be meaningful, the issuing CA must be trusted by software vendors, otherwise the certificate is useless. I used Firefox as an example, but really you want the CA to be trusted by at least current and somewhat older versions of Firefox, Chrome, Windows, Mac OS X, iOS, and Android. And the dozens of smaller players. CAs worth considering (that includes ComodoSSL and Let's Encrypt) are trusted by all these entities.

3. If a CA misbehaves, or is revealed as untrustworthy, it will get removed from the various trust stores quickly enough to ruin the day of certificate owners. Two notable examples I know of are DigiNotar and StartCom/WoSign (check out the articles, they provide interesting insights in the trust dynamics!). So if you think Let's Encrypt will screw up, or will be dropped for some other reason, not using them will prevent you from getting caught in that particular fall-out.

4. Certificates employ some crypto math magic; the question is which crypto math magic? What if it's weak magic? This is actually a real concern, and CAs have shown to drag their feet on upgrading this, too. Luckily, browser vendors have picked up the slack by setting minimums here for certificates to be accepted. For example, certificates using RSA-1024 or SHA-1 are now rejected by most browsers, so any certificate that works in practice doesn't use these deprecated crypto primitives. The upshot is, it's pretty hard for any CA (Let's Encrypt included) to disappoint on this part anymore.

5. Before, I more or less said that all certificates are created equal. I lied, they're not. In particular, what I discussed up until now are "Domain Validated (DV) certificates", which are what the vast majority of websites use. They provide a measure of certainty that your browser is actually talking to the domain it shows in the URL bar. There are also "Organization Validated (OV)" and "Extended Validation (EV)" certificates, which require much more elaborate checks from CAs. In particular, you should only be able to get an EV certificate for somebank.com / SomeBank Inc., if you can actually prove you are SomeBank, Inc.

   EV certificates are a lot more costly to obtain (ballpark: hundreds of EUR/USD per year), and they may be rewarded with a green URL bar or padlock in the browser, maybe displaying "SomeBank, Inc." as well. Contrary to DV certificates, they also offer some idea as to who the website might actually belong to. The upside is, they may look more legit. The disappointment is, users rarely pay attention to them, so their effectiveness is limited.

   An attacker with a forged DV certificate can still impersonate the site, just without the extra visual clue an EV certificate may offer, and users generally don't notice the distinction. Conversely, it is possible to obtain a misleading EV certificate to make phishing easier. As a result, both Chrome and Firefox will be dropping their visual nods to EV certificates, and some people believe they will go away entirely.

   If you're a bank, you probably still want an EV certificate for now. Otherwise, not so much. But if you do need EV, Let's Encrypt isn't for you because they simply don't offer EV certificates.

6. Certificates are only valid for a limited time. Certificates from a typical commercial CA tend to be valid for one year, but I've seen anything from three months to three years. Let's Encrypt certificates are valid for 90 days, which is on the short side of that range, so you'll need to renew them often. For Let's Encrypt users, this is usually automated so that certificates are replaced every 60 days.

   Being able to automate renewal with widely available software is actually more pleasant than the yearly Oh shit my certificate expired? What's my login at the CA? How does this work again? ritual that most small sites seem to end up with at commercial CAs.

7. Before, I called it scary that there are so many CAs we all have to trust. Having many CAs is also an advantage though, in the sense that removing a single one from our trust stores has a limited impact on users. In particular, expelling a single CA will only affect the certificates issued by that one CA. If everyone ends up using one single CA (which some people fear might happen with Let's Encrypt), we concentrate all of our trust there, and lose the advantages of that fragmentation.

8. And finally, there's other benefits a paid CA might offer, such as commercial support, or a million-dollar SSL warranty. I have little faith in both of these aspects, but they are things that Let's Encrypt does not offer.

My head hurts... I had a question, I think?

• The certificate proper, which contains a public key and some identification (such as a domain name).
• The private key, which allows the holder (and only the holder) to digitally sign messages in such a way that they can be verified using the above certificate.

• Create a private/public keypair, and keep the private part, well, private.
• Ask a trustworthy third party ("CrediCorp") to create a certificate for yourdomain.com with your public key.
• Prove in some way to CrediCorp that you actually own yourdomain.com.
• Put the private key and the obtained certificate on your server, and configure the web server to use them.

(There also follows some crypto voodoo to turn this authenticity into confidentiality.)

In particular, they managed to convince the makers of, say, Firefox. As a result, CrediCorp gets on Firefox' A-list, and their certificates are trusted by Firefox by default. So really, Alice trusts Firefox, Firefox trusts CrediCorp, and CrediCorp trusted (after verifying) you when you claimed you owned yourdomain.com. It's almost like a chain.

This has consequences. If someone manages to convince ShabbyCorp that they own yourdomain.com (because ShabbyCorp isn't very thorough), then they can obtain a ShabbyCorp certificate for yourdomain.com with corresponding private key. And with that certificate they could impersonate your web server. After all, they have a certificate (plus key) for yourdomain.com that is trusted by Firefox!

CrediCorp and ShabbyCorp are what's called Certificate Authorities, CAs for short. In the real world, ComodoSSL and Let's Encrypt are examples of CAs. But there's a lot more of them; as of this writing, Firefox trusts 154 CAs.

And even if you like CrediCorp better — because you know, they just sound so much more trustworthy — using them won't really help you. If an attacker can convince ShabbyCorp to give them a certificate for your site, the attacker can use that certificate to impersonate your site, regardless of where you got yours.

As long as Firefox trusts ShabbyCorp, visitors won't see the difference. (Yes, they can pull up the certificate, and dig through there, see who issued it. But who does that?) As far as forging certificates is concerned, this makes the entire system as weak as the weakest of 150+ CAs. Yes, that is a bit scary, and it's probably the biggest criticism of this entire scheme. Still, it's what we're stuck with.

Point is, if you don't trust a CA to give out "good" certificates, not using that CA doesn't help you.

1. Let's start with killing the point I made in the last section. Nowadays it is possible to lock your domain to just CAs of your choosing using DNS-CAA. Suppose that you do trust Comodo, and don't trust Let's Encrypt, it is possible to ask non-Comodo CAs not to issue certificates for your domain. In theory. (Because DNS-CAA is not checked by browsers, only by issuing CAs. So a compromised CA could ignore this safeguard.)

   The question then is, is Let's Encrypt actually less trustworthy? Or less secure? Trustworthiness is a hard one, how do you quantify that? All I can say is that in my perception Let's Encrypt is no less trustworthy than other CAs. As for the security of their validations, they are very similar to what commercial CA's do (for DV certificates anyway). See also this question.

   For what it's worth: the StackExchange network, which this site is a part of, currently uses Let's Encrypt certificates. Most people would never notice this, and if they did I sincerely doubt if it would mean much to them.

2. For a certificate to be meaningful, the issuing CA must be trusted by software vendors, otherwise the certificate is useless. I used Firefox as an example, but really you want the CA to be trusted by at least current and somewhat older versions of Firefox, Chrome, Windows, Mac OS X, iOS, and Android. And the dozens of smaller players. This is the case for any CA normal people would consider, including ComodoSSL and Let's Encrypt.

3. If a CA misbehaves, or is revealed as untrustworthy, it will get removed from the various trust stores quickly enough to ruin the day of certificate owners. Two notable examples I know of are DigiNotar and StartCom (former purveyor of free certificates). So if you think Let's Encrypt will screw up (or will be dropped for some other reason), not using them will prevent you from getting caught in the fall-out.

4. Certificates employ some crypto math magic; the question is which crypto math magic? What if it's weak magic? This is actually a real concern, and CAs have shown to drag their feet on upgrading this, too. Luckily, browser vendors have picked up the slack by setting minimums here for certificates to be accepted. For example, certificates using rsa-1024 or sha-1 are now rejected by most browsers, so any certificate that works doesn't use these deprecated crypto primitives. The upshot is, it's pretty hard for any CA (Let's Encrypt included) to disappoint on this part anymore.

5. Before I said more or less that all certificates are created equal. I lied, they're not. In particular, what I discussed up until now are "Domain Validated (DV) certificates", which is what the vast majority of websites use. They prove, more or less, that your browser is talking to the domain it shows in the URL bar. There are also "Organization Validated (OV)" and "Extended Validation (EV)" certificates, which require much more elaborate checks from CAs. In particular, you should only be able to get an EV certificate for somebank.com / SomeBank Inc., if you can actually prove you are SomeBank, Inc.

   EV certificates are a lot more costly to obtain, and they may be rewarded with a green URL bar or padlock in the browser, maybe displaying "SomeBank, Inc." as well. Contrary to DV certificates, they also offer some guarantee as to who the website might actually belong to. The upside is, they may look more legit. The disappointment is, users rarely pay attention to them, so their effectiveness is limited. An attacker with a forged DV certificate can still impersonate the site, just without the extra visual clue an EV certificate may offer.

   So if you're a financial institution, you probably still want an EV certificate. For most things, it's overkill. But if you do need EV, Let's Encrypt isn't for you because they simply don't offer EV certificates.

6. Certificates are only valid for a limited time. Certificates from a typical commercial CA tend to be valid for one year, but I've seen two or three years as well. Let's Encrypt certificates, on the other hand, are only valid for three months, so you'll need to replace them more often. For Let's Encrypt users, this is usually automated, so certificates are replaced every two months.

   Being able to do that with widely available software is actually more pleasant than the yearly Oh shit my certificate expired? What's my login at the CA? How does this work again? ritual that most small sites end up with at commercial CAs.

7. And finally, there's other benefits a paid CA might offer, such as support, or a million-dollar SSL warranty. I have little faith in both of these aspects, but they are things that Let's Encrypt does not offer.

My head hurts... I had a question I think?

Use what you feel comfortable with! For DV certificates, there is little that actually differentiates the various CA's. I use Let's Encrypt both privately and professionally, and I'm happy with it.

There really are only thee potential reasons I see to avoid Let's Encrypt:

• If you need EV (or OV) certificates.
• If you can't or don't want to automate certificate renewal and three months certificate validity is too short for you.
• If you don't trust Let's Encrypt (but be sure to consider other measures like DNS-CAA as well).

• The certificate proper, which contains a public key and some identification (such as a domain name).
• The private key, which allows the holder (and only the holder) to digitally sign messages in such a way that they can be verified using the above certificate.

• Create a private/public keypair, and keep the private part, well, private.
• Ask a trustworthy third party ("CrediCorp") to create a certificate for yourdomain.com with your public key.
• Prove in some way to CrediCorp that you control yourdomain.com.
• Put the private key and the obtained certificate on your server, and configure the web server to use them.

(There also follows some crypto voodoo dance to turn this authenticity into confidentiality.)

In particular, they managed to convince the makers of, say, Firefox. As a result, CrediCorp gets on Firefox' A-list, and their certificates are trusted by Firefox by default. So really, Alice trusts Firefox, Firefox trusts CrediCorp, and CrediCorp trusted (after verifying) you when you claimed you controlled yourdomain.com. It's almost like a chain.

This has consequences. If someone manages to convince ShabbyCorp that they control yourdomain.com (because ShabbyCorp isn't very thorough), then they can obtain a ShabbyCorp certificate for yourdomain.com with corresponding private key. And with that certificate they could impersonate your web server. After all, they have a certificate (plus key) for yourdomain.com that is trusted by Firefox!

CrediCorp and ShabbyCorp are what's called Certificate Authorities, CAs for short. In the real world, ComodoSSL and Let's Encrypt are examples of CAs. But there's a lot more of them; as of this writing, Firefox trusts 154 CAs.

And even if you like CrediCorp better — because you know, they just sound sooo much more trustworthy — using them won't really help you. If an attacker can convince ShabbyCorp to give them a certificate for your site, the attacker can use that certificate to impersonate your site, regardless of where you got yours.

As long as Firefox trusts ShabbyCorp, visitors won't see the difference. (Yes, visitors could pull up the certificate, and dig through there, see who issued it. But who does that?) As far as forging certificates is concerned, this makes the entire system as weak as the weakest of 150+ CAs. Why yes, that is scary, and it's probably the biggest criticism people have of this entire scheme. Still, it's what we're stuck with.

Point is, if you don't trust a CA to give out "good" certificates, getting your certificates elsewhere doesn't help you much.

1. Let's start with killing the point I made in the last section. Nowadays it is possible to lock your domain to just CAs of your choosing using DNS-CAA. Suppose that you do trust Comodo, and don't trust other CAs, it is possible to request all CAs other than Comodo to not issue certificates for your domain. In theory. (Because DNS-CAA is not checked by browsers, only by issuing CAs. So a compromised CA could ignore this safeguard.)

   If you're willing to go through that trouble, then the question becomes: is Let's Encrypt actually less trustworthy? Or less secure? Trustworthiness is a hard one, how do you quantify that? All I can say is that in my perception Let's Encrypt is no less trustworthy than other CAs. As for the security of their validations, they are very similar to what commercial CAs do (for DV certificates anyway). See also this question.

   For what it's worth: the StackExchange network, which this site is a part of, currently uses Let's Encrypt certificates. Most people would never notice this, and if they did I sincerely doubt if it would mean much to them.

2. For a certificate to be meaningful, the issuing CA must be trusted by software vendors, otherwise the certificate is useless. I used Firefox as an example, but really you want the CA to be trusted by at least current and somewhat older versions of Firefox, Chrome, Windows, Mac OS X, iOS, and Android. And the dozens of smaller players. CAs worth considering (that includes ComodoSSL and Let's Encrypt) are trusted by all these entities.

3. If a CA misbehaves, or is revealed as untrustworthy, it will get removed from the various trust stores quickly enough to ruin the day of certificate owners. Two notable examples I know of are DigiNotar and StartCom/WoSign (check out the articles, they provide interesting insights in the trust dynamics!). So if you think Let's Encrypt will screw up, or will be dropped for some other reason, not using them will prevent you from getting caught in that particular fall-out.

4. Certificates employ some crypto math magic; the question is which crypto math magic? What if it's weak magic? This is actually a real concern, and CAs have shown to drag their feet on upgrading this, too. Luckily, browser vendors have picked up the slack by setting minimums here for certificates to be accepted. For example, certificates using RSA-1024 or SHA-1 are now rejected by most browsers, so any certificate that works in practice doesn't use these deprecated crypto primitives. The upshot is, it's pretty hard for any CA (Let's Encrypt included) to disappoint on this part anymore.

5. Before, I more or less said that all certificates are created equal. I lied, they're not. In particular, what I discussed up until now are "Domain Validated (DV) certificates", which are what the vast majority of websites use. They provide a measure of certainty that your browser is actually talking to the domain it shows in the URL bar. There are also "Organization Validated (OV)" and "Extended Validation (EV)" certificates, which require much more elaborate checks from CAs. In particular, you should only be able to get an EV certificate for somebank.com / SomeBank Inc., if you can actually prove you are SomeBank, Inc.

   EV certificates are a lot more costly to obtain (ballpark: hundreds of EUR/USD per year), and they may be rewarded with a green URL bar or padlock in the browser, maybe displaying "SomeBank, Inc." as well. Contrary to DV certificates, they also offer some guarantee as to who the website might actually belong to. The upside is, they may look more legit. The disappointment is, users rarely pay attention to them, so their effectiveness is limited. An attacker with a forged DV certificate can still impersonate the site, just without the extra visual clue an EV certificate may offer.

   So if you're a financial institution, you probably still want an EV certificate. For most things, it's overkill. But if you do need EV, Let's Encrypt isn't for you because they simply don't offer EV certificates.

6. Certificates are only valid for a limited time. Certificates from a typical commercial CA tend to be valid for one year, but I've seen anything from three months to three years. Let's Encrypt certificates are valid for 90 days, which is on the short side of that range, so you'll need to renew them often. For Let's Encrypt users, this is usually automated so that certificates are replaced every 60 days.

   Being able to automate renewal with widely available software is actually more pleasant than the yearly Oh shit my certificate expired? What's my login at the CA? How does this work again? ritual that most small sites seem to end up with at commercial CAs.

7. And finally, there's other benefits a paid CA might offer, such as commercial support, or a million-dollar SSL warranty. I have little faith in both of these aspects, but they are things that Let's Encrypt does not offer.

My head hurts... I had a question... I think?

Use what you feel comfortable with! For DV certificates, there is little that actually differentiates the various CAs. I use Let's Encrypt both professionally and privately, and I'm happy with it.

There really are only four potential reasons I see to avoid Let's Encrypt:

• If you need EV (or OV) certificates.
• If you can't or don't want to automate certificate renewal and three months certificate validity is too short for you.
• If you don't trust Let's Encrypt (but be sure to consider other measures like DNS-CAA as well, and you should probably blacklist Let's Encrypt in your browser then, too).
• If you believe Let's Encrypt will be discontinued or dropped from browsers for some reason.

For most uses, there's no good reason to pay for them. See the very bottom for a summary of the few reasons why you might want to.

• The certificate proper, which contains some identification (such as a domain name).
• The private key, which allows the holder (and only the holder) to digitally sign messages in such a way that they can be verified using the above certificate.

• Create a private key, and keep it to yourself.
• Ask a trustworthy third party ("CrediCorp") to create a certificate matching your private key for yourdomain.com.
• Prove to CrediCorp that you actually own yourdomain.com.
• Put the private key (and certificate) on your server, and configure the web server to use them.

The combination of these three things guarantees Alice that she actually is talking to yourdomain.com, and not to some impostor, provided that Alice trusts CrediCorp.

1. Let's start with killing the point I made in the last section. Nowadays it is sort of possible to lock your domain to just CAs of your choosing using DNS-CAA. Suppose that you do trust Comodo, and don't trust Let's Encrypt, it is possible to ask non-Comodo CAs not to issue certificates for your domain. In theory. (Because DNS-CAA is not checked by browsers, only by issuing CAs. So a compromised CA could ignore this safeguard.)

   The question then is, is Let's Encrypt actually less trustworthy? Or less secure? Trustworthiness is a hard one, how do you quantify that? All I can say is that in my perception Let's Encrypt is no less trustworthy than other CAs. As for the security of their validations, they are very similar to what commercial CA's do (for DV certificates anyway). See also this question.

   For what it's worth: the StackExchange network, which this site is a part of, currently uses Let's Encrypt certificates. Most people would never notice this, and if they did I sincerely doubt if it would have much effect on SE's trustworthiness.

2. For a certificate to be meaningful, the issuing CA must be trusted by software vendors, otherwise the certificate is useless. I used Firefox as an example, but really you want the CA to be trusted by at least Firefox, Chrome, Windows, Mac OS X, iOS, and Android. And the dozens of smaller players. This is the case for any CA normal people would consider, including ComodoSSL and Let's Encrypt.

3. If a CA misbehaves, or is revealed as untrustworthy, it will get removed from the various trust stores quickly enough to ruin the day of certificate owners. Two notable examples I know of are DigiNotar and StartCom (former purveyor of free certificates). So if you think Let's Encrypt will screw up (or will be dropped for some other reason), not using them will prevent you from getting caught in the fall-out.

4. Certificates specify some crypto math magic; the question is which crypto math magic? What if it's weak magic? This is actually a real concern, and CAs have shown to drag their feet on upgrading this, too. Luckily, browser vendors have picked up the slack by setting minimums here for certificates to be accepted. For example, certificates using rsa-1024 or sha-1 are now rejected by most browsers, so any certificate that works doesn't use these deprecated crypto primitives. The upshot is, it's pretty hard for any CA (Let's Encrypt included) to disappoint on this part anymore.

5. Before I said more or less that all certificates are created equal. I lied, they're not. In particular, what I discussed up until now are "Domain Validated (DV) certificates", which is what the vast majority of websites use. They prove, more or less, that your browser is talking to the domain it shows in the URL bar. There are also "Organization Validated (OV)" and "Extended Validation (EV)" certificates, which require much more elaborate checks from CAs. In particular, you should only be able to get an EV certificate for somebank.com / SomeBank Inc., if you can actually prove you are SomeBank, Inc.

   EV certificates are a lot more costly to obtain, and they may be rewarded with a green URL bar or padlock in the browser, maybe displaying "SomeBank, Inc." as well. Contrary to DV certificates, they also offer some guarantee as to who the website might actually belong to. The upside is, they may look more legit. The disappointment is, users rarely pay attention to them, so their effectiveness is limited. An attacker with a forged DV certificate can still impersonate the site, just without the extra visual clue an EV certificate may offer.

   So if you're a financial institution, you probably still want an EV certificate. For most things, it's overkill. But if you do need EV, Let's Encrypt isn't for you because they simply don't offer EV certificates.

6. Certificates are only valid for a limited time. Certificates from a typical commercial CA tend to be valid for one year, but I've seen two or three years as well. Let's Encrypt certificates, on the other hand, are only valid for three months, so you'll need to replace them more often. For Let's Encrypt users, this is usually automated, so certificates are replaced every two months.

   Being able to do that with widely available software is actually more pleasant than the yearly Oh shit my certificate expired? What's my login at the CA? How does this work again? ritual that most small sites end up with at commercial CAs.

7. And finally, there's other benefits a paid CA might offer, such as support, or a million-dollar SSL warranty. I have little faith in both of these aspects, but they are things that Let's Encrypt does not offer.

For most uses, there's no good reason to pay for them.
See the very bottom for a summary of the exceptions.

• The certificate proper, which contains a public key and some identification (such as a domain name).
• The private key, which allows the holder (and only the holder) to digitally sign messages in such a way that they can be verified using the above certificate.

• Create a private/public keypair, and keep the private part, well, private.
• Ask a trustworthy third party ("CrediCorp") to create a certificate for yourdomain.com with your public key.
• Prove in some way to CrediCorp that you actually own yourdomain.com.
• Put the private key and the obtained certificate on your server, and configure the web server to use them.

The combination of these three things guarantees Alice that she actually is talking to yourdomain.com, and not to some impostor... Provided that Alice trusts CrediCorp.

1. Let's start with killing the point I made in the last section. Nowadays it is possible to lock your domain to just CAs of your choosing using DNS-CAA. Suppose that you do trust Comodo, and don't trust Let's Encrypt, it is possible to ask non-Comodo CAs not to issue certificates for your domain. In theory. (Because DNS-CAA is not checked by browsers, only by issuing CAs. So a compromised CA could ignore this safeguard.)

   The question then is, is Let's Encrypt actually less trustworthy? Or less secure? Trustworthiness is a hard one, how do you quantify that? All I can say is that in my perception Let's Encrypt is no less trustworthy than other CAs. As for the security of their validations, they are very similar to what commercial CA's do (for DV certificates anyway). See also this question.

   For what it's worth: the StackExchange network, which this site is a part of, currently uses Let's Encrypt certificates. Most people would never notice this, and if they did I sincerely doubt if it would mean much to them.

2. For a certificate to be meaningful, the issuing CA must be trusted by software vendors, otherwise the certificate is useless. I used Firefox as an example, but really you want the CA to be trusted by at least current and somewhat older versions of Firefox, Chrome, Windows, Mac OS X, iOS, and Android. And the dozens of smaller players. This is the case for any CA normal people would consider, including ComodoSSL and Let's Encrypt.

3. If a CA misbehaves, or is revealed as untrustworthy, it will get removed from the various trust stores quickly enough to ruin the day of certificate owners. Two notable examples I know of are DigiNotar and StartCom (former purveyor of free certificates). So if you think Let's Encrypt will screw up (or will be dropped for some other reason), not using them will prevent you from getting caught in the fall-out.

4. Certificates employ some crypto math magic; the question is which crypto math magic? What if it's weak magic? This is actually a real concern, and CAs have shown to drag their feet on upgrading this, too. Luckily, browser vendors have picked up the slack by setting minimums here for certificates to be accepted. For example, certificates using rsa-1024 or sha-1 are now rejected by most browsers, so any certificate that works doesn't use these deprecated crypto primitives. The upshot is, it's pretty hard for any CA (Let's Encrypt included) to disappoint on this part anymore.

5. Before I said more or less that all certificates are created equal. I lied, they're not. In particular, what I discussed up until now are "Domain Validated (DV) certificates", which is what the vast majority of websites use. They prove, more or less, that your browser is talking to the domain it shows in the URL bar. There are also "Organization Validated (OV)" and "Extended Validation (EV)" certificates, which require much more elaborate checks from CAs. In particular, you should only be able to get an EV certificate for somebank.com / SomeBank Inc., if you can actually prove you are SomeBank, Inc.

   EV certificates are a lot more costly to obtain, and they may be rewarded with a green URL bar or padlock in the browser, maybe displaying "SomeBank, Inc." as well. Contrary to DV certificates, they also offer some guarantee as to who the website might actually belong to. The upside is, they may look more legit. The disappointment is, users rarely pay attention to them, so their effectiveness is limited. An attacker with a forged DV certificate can still impersonate the site, just without the extra visual clue an EV certificate may offer.

   So if you're a financial institution, you probably still want an EV certificate. For most things, it's overkill. But if you do need EV, Let's Encrypt isn't for you because they simply don't offer EV certificates.

6. Certificates are only valid for a limited time. Certificates from a typical commercial CA tend to be valid for one year, but I've seen two or three years as well. Let's Encrypt certificates, on the other hand, are only valid for three months, so you'll need to replace them more often. For Let's Encrypt users, this is usually automated, so certificates are replaced every two months.

   Being able to do that with widely available software is actually more pleasant than the yearly Oh shit my certificate expired? What's my login at the CA? How does this work again? ritual that most small sites end up with at commercial CAs.

7. And finally, there's other benefits a paid CA might offer, such as support, or a million-dollar SSL warranty. I have little faith in both of these aspects, but they are things that Let's Encrypt does not offer.