Is there a reason to use an SSL certificate other than Let's Encrypt's free SSL?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
129
down vote

favorite
38












Let's Encrypt are providing free SSL certificates. Are there any downsides compared to other, paid certificates e.g. AWS Certificate Manager?







share|improve this question
















  • 1




    I've removed the majority of comments regarding the pointless debate if LE is inherently less trustworthy due to its free nature.
    – Sven♦
    Aug 23 at 21:26















up vote
129
down vote

favorite
38












Let's Encrypt are providing free SSL certificates. Are there any downsides compared to other, paid certificates e.g. AWS Certificate Manager?







share|improve this question
















  • 1




    I've removed the majority of comments regarding the pointless debate if LE is inherently less trustworthy due to its free nature.
    – Sven♦
    Aug 23 at 21:26













up vote
129
down vote

favorite
38









up vote
129
down vote

favorite
38






38





Let's Encrypt are providing free SSL certificates. Are there any downsides compared to other, paid certificates e.g. AWS Certificate Manager?







share|improve this question












Let's Encrypt are providing free SSL certificates. Are there any downsides compared to other, paid certificates e.g. AWS Certificate Manager?









share|improve this question











share|improve this question




share|improve this question










asked Aug 18 at 9:29









ripper234

2,15363444




2,15363444







  • 1




    I've removed the majority of comments regarding the pointless debate if LE is inherently less trustworthy due to its free nature.
    – Sven♦
    Aug 23 at 21:26













  • 1




    I've removed the majority of comments regarding the pointless debate if LE is inherently less trustworthy due to its free nature.
    – Sven♦
    Aug 23 at 21:26








1




1




I've removed the majority of comments regarding the pointless debate if LE is inherently less trustworthy due to its free nature.
– Sven♦
Aug 23 at 21:26





I've removed the majority of comments regarding the pointless debate if LE is inherently less trustworthy due to its free nature.
– Sven♦
Aug 23 at 21:26











8 Answers
8






active

oldest

votes

















up vote
115
down vote



accepted










Certificate lifespan



Security



Shorter lifespan is better. Simply because revocation is mostly theoretical, in practice it cannot be relied on (big weakness in the public PKI ecosystem).



Management



Without automation: Longer lifespan is more convenient. LE may not be feasible if you, for whatever reason, cannot automate the certificate management

With automation: Lifespan doesn't matter.



End-user impression



End-users are unlikely to have any idea one way or another.



Level of verification



Security



Letsencrypt provides DV level of verification only.

Buying a cert you get whatever you pay for (starting at DV, with the same level of assertion as with LE).



DV = only domain name control is verified.

OV = owner entity (organization) information is verified in addition.

EV = more thorough version of OV, which has traditionally been awarded with the "green bar" (but the "green bar" appears to be going away soon).



Management



When using LE, the work you put in is setting up the necessary automation (in this context, to prove domain control). How much work that is will depend on your environment.



When buying a cert the DV/OV/EV level will define how much manual work will be required to get the cert. For DV it typically boils down going through a wizard paying and copy/pasting something or clicking something, for OV and EV you can pretty much count on needing to be contacted separately to do additional steps to confirm your identity.



End-user impression



End-users probably recognize the current EV "green bar" (which is going away), other than that they don't tend to actually look at the certificate contents.

Theoretically, though, it is clearly more helpful with a certificate that states information about the controlling entity. But browsers (or other client applications) need to start actually showing this in a useful way before that has any effect for the typical user.



Installation



Security



It is possible to do things incorrectly in ways that expose private keys or similar.
With LE, the provided tooling is set up around reasonable practices.

With a person who knows what they are doing, manual steps can obviously also be done securely.



Management



LE is very much intended to have all processes automated, their service is entirely API-based and the short lifespan also reflects how everything is centered around automation.



When buying a cert, even with a CA that provides APIs to regular customers (not really the norm at this point) it will be difficult to properly automate anything other than DV and with DV you are paying for essentially the same thing that LE provides.

If you are going for OV or EV levels, you can probably only partially automate the process.



End-user impression



If the installation is done correctly, the end-user will obviously not know how it was done. The chances of messing things up (eg, forgetting to renew or doing the installation incorrectly when renewing) are less with an automated process.



Overall



Traditional means of buying certs are particularly useful if you desire OV/EV certs, are not automating certificate management or want certs used in some other context than HTTPS.






share|improve this answer
















  • 3




    In some cases there is an insurance aspect, in the event of a CA-side compromise.
    – John Keates
    Aug 20 at 13:03






  • 21




    Do you have a source on EV going away?
    – Puddingfox
    Aug 20 at 15:14






  • 4




    @Puddingfox Good point. I will have to look up the current status and maybe qualify it more if necessary. That said, it's not EV certs that would be going away but the related "green bar" browser UI indicator.
    – Håkan Lindqvist
    Aug 20 at 15:30






  • 5




    In my experience, you can also use Lets Encrypt for mail, so it’s flexible enough for that purpose.
    – Manngo
    Aug 20 at 21:58






  • 10




    @kloddant Huh. You would run the script more than once per renewal period, and of course like any other automated process, it needs monitoring (which triggers before the certificate expires).
    – Jonas Wielicki
    Aug 21 at 15:35

















up vote
75
down vote













From a purely technical perspective:



  • The fact that the certificates are only valid for 3 months. Can be a nuisance to maintain depending on your change management procedures and infrastructure.

  • The purpose of Let's Encrypt certificates is limited. You can't use them for your email, code signing or timestamping.

    Check with: openssl x509 -in cert.pem -noout -text


    X509v3 Extended Key Usage:

    TLS Web Server Authentication, TLS Web Client Authentication




From an end-user perspective:



  • The lack of Extended Validation means "no green bar" in certain webbrowsers.

    • However, Chrome will be phasing out the green bar in September 2018 in favor of a small lock icon and eventually no special indicator and will instead only show warnings for insecure pages.






share|improve this answer


















  • 23




    Note that Chrome is actively moving towards showing nothing special for HTTPS at all and the next major release of OSX and iOS will see Safari not show anything special for EV. It appears the major browser vendors are moving away from EV. Many of the top web sites don’t even use it.
    – Greg W
    Aug 18 at 10:45






  • 18




    Regarding the point made about change management, the idea behind the 3 month lifespan is that the process of getting and renewing certs is meant to be entirely automated. Ie, if used as intended, the change would be setting up that automation, not repeatedly installing certificates manually. But if there is policy against automating that, it would probably make it a no-go.
    – Håkan Lindqvist
    Aug 18 at 11:48






  • 8




    TLS Web Server Authentication is sufficient for securing, e.g. SMTP, IMAP, POP3 servers. It's not valid for S/MIME though.
    – Michael Hampton♦
    Aug 18 at 14:12






  • 5




    To the commentators- please note that the above is a community wiki intended to be edited by anyone
    – HBruijn♦
    Aug 18 at 20:46







  • 12




    @ripper234 You mean like the serious / user facing website serverfault.com you're on right now? This site doesn't use an EV cert. Neither does google.com. Or microsoft.com. Or cisco.com. And browsers are phasing out the green bar. If an EV certificate is important to you, by all means pay for it, but surely plenty of important and user facing sites have come to a different conclusion about its value.
    – Zach Lipton
    Aug 20 at 1:19

















up vote
28
down vote













I'd like to offer some counter points for the arguments used against Let's Encrypt here.



Short lifetime



Yes, they have a short lifetime as explained in the faq: https://letsencrypt.org/2015/11/09/why-90-days.html To quote the page:




  1. They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.


  2. They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t
    continue to expect system administrators to manually handle renewals.
    Once issuance and renewal are automated, shorter lifetimes won’t be
    any less convenient than longer ones.




Lack of EV



There is no plan for EV support. The reasoning (from https://community.letsencrypt.org/t/plans-for-extended-validation/409) is:




We expect that Let’s Encrypt won’t support EV, because the EV process will always require human effort, which will require paying someone. Our model is to issue certificates free of charge, which requires a level automation that doesn’t seem compatible with EV.




Furthermore there are some that believe that EV is harmful, like this blogpost (https://stripe.ian.sh/):




James Burton, for example, recently obtained an EV certificate for his company "Identity Verified". Unfortunately, users are simply not equipped to deal with the nuances of these entities, and this creates a significant vector for phishing.




A classic real world example of this is sslstrip. Homograph sites with legitimately purchased certificates are a real-world attack for which EV doesn't provide a sufficient defense currently.






share|improve this answer



























    up vote
    5
    down vote













    Unless you need a certificate for something other than web, there are no real downsides, but surely perceived ones. Although the problems are only perceived, as the owner of a website you may have no other choice but to address them (if business interest forbids showing the middle finger).



    The single biggest downside is, for the time being, that your site will show as somewhat inferior, maybe dangerous because it doesn't have the nice green badge that some other sites have. What does that badge mean? Nothing, really. But it does suggest that your site is "secure" (some browsers even use that exact word). Alas, users are people, and people are stupid. One or the other will take your site as not trustworthy (without understanding any of the implications) just because the browser doesn't say it's secure.



    If ignoring these customers/visitors is a valid possibility, no problem. If you cannot afford that business-wise, you will have to spend money. No other option.



    The other perceived problem is the one about certificate lifetime. But it is actually an advantage, not a disadvantage. Shorter validity means that certificates have to be updated more often, both server-side, and client-side, alright.

    As for server-side, this happens with a cron job, so it's actually less hassle and more reliable than usual. No way you can forget, no way to be late, no way to accidentially do something wrong, no need to log in with an administrative account (... more than once). On the client-side, so what. Browsers update certificates all the time, it's no biggie. The user doesn't even know it happens. There's very slightly more traffic to be had when updating every 3 months instead of every 2 years, but seriously... that is not an issue.






    share|improve this answer
















    • 2




      @HÃ¥kanLindqvist: That's the exact problem. I can set up a malware site and spend $5.99, and the average user will trust my malware contents because it says "secure". The same user won't trust your entirely harmless, legitimate site with a lets-encrypt certificate. Because, well, it's not secure. But alas, these are things you just cannot change.
      – Damon
      Aug 18 at 12:58






    • 10




      The LE cert is just an example of a DV cert, though (which is most likely all you'd be getting for just $5.99). LE certs show as "Secure" in current browsers.
      – Håkan Lindqvist
      Aug 18 at 13:03






    • 1




      do you consider email servers as part of the web? letsencrypt certificates were insufficient for me because i had to run my own email server
      – hanshenrik
      Aug 18 at 14:05






    • 7




      @hanshenrik you can use LE just fine with mail servers. For example, I use github.com/hlandau/acme Let's Encrypt client not only for my HTTPS, but also for TLS in SMTP, IMAP, POP3, XMPP...
      – Matija Nalis
      Aug 20 at 10:12






    • 4




      @hanshenrik - I run LE certs for my mail server: no issues at all
      – warren
      Aug 20 at 20:19

















    up vote
    5
    down vote













    There are two groups of downsides worth considering.



    1. Downsides to using the Let's Encrypt service



    Let's Encrypt requires that the exact name, or the (sub-)domain if you're requesting a wildcard, exists in the public Internet DNS. Even if you prove control over example.com, Let's Encrypt won't issue you certificates for some.other.name.in.example.com without seeing that in public DNS. The machines named needn't have public address records, they can be firewalled off, or even physically disconnected, but the public DNS name needs to exist.



    Let's Encrypt certificate lifetimes of 90 days mean you need to automate because ain't nobody got time for that. This is in fact the intent of the service - to herd people towards automating this essential work rather than perversely doing it manually while they automate away many harder tasks. But if you can't automate for any reason it's a negative - if you have tools, appliances or whatever that block automation consider any commercial SSL cert costs as part of the ongoing cost of those tools/ appliances/ whatever in cost planning. Contrariwise offset savings from not needing to buy commercial certs in pricing of new tools / appliances / etcetera that automate this (with Let's Encrypt or not)



    The Let's Encrypt proof of control automation may not suit your organisation's rules. For example if you have employees who're allowed to reconfigure Apache but shouldn't get SSL certs for company domain names then Let's Encrypt is a poor fit. Note that in this case just not using them is the Wrong Thing(TM) you should use CAA to explicitly disable Let's Encrypt for your domains.



    If Let's Encrypt policy refuses you, the only "court of appeal" is to ask in its public forums and hope one of their staff is able to offer a way forward. This may happen if, for example, your site has a DNS name their systems decide is "confusingly similar" to certain famous properties like big banks or Google. For sensible reasons the exact policies of each public CA in this regard are not open to public scrutiny so you may only realise you can't have a Let's Encrypt cert when you request it and get a "Policy forbids..." response.



    2. Downsides to a Let's Encrypt certificate itself



    Let's Encrypt certificates are trusted by major web browsers today via ISRG (the charity providing the Let's Encrypt service) but older systems trust Let's Encrypt via IdenTrust, a relatively obscure Certificate Authority which controls "DST Root CA X3". This gets the job done for most people, but it isn't the most broadly trusted root in the world. For example the abandoned Nintendo WiiU console had a web browser, obviously Nintendo won't be shipping updates for WiiU and so that browser is abandoned, it doesn't trust Let's Encrypt.



    Let's Encrypt only issues certificates for the Web PKI - servers with Internet names which use the SSL/TLS protocol. So that's the Web obviously, and your IMAP, SMTP, some types of VPN server, dozens of things, but not everything. In particular Let's Encrypt doesn't offer certificates at all for S/MIME (a way to encrypt email at rest, rather than just when it's in transit) nor for code signing or document signing. If you want a "one stop shop" for certificates, this may be enough reason not to use Let's Encrypt.



    Even in the Web PKI, Let's Encrypt offers only "DV" certificates, meaning any details about yourself or your organisation other than FQDNs aren't mentioned in the certificate. Even if you write them into a CSR they're just discarded. This may be a blocker for some specialist applications.



    Let's Encrypt automation means you're constrained exactly by what the automation allows even if there is no other reasons why you can't have something. New types of public key, new X.509 extensions and other additions have to be explicitly enabled by Let's Encrypt on their own timeline, and of course you can't just offer to pay extra to get the features you want although donations are welcome.



    Nevertheless, for almost everyone, almost always, Let's Encrypt is a good first choice for putting certificates on your TLS servers in a fire-and-forget way. Starting with the assumption that you'll use Let's Encrypt is a sensible way to approach this decision.






    share|improve this answer
















    • 3




      I wonder if not supporting Nintendo WiiU is a big deal, considering how few websites that browser can display correctly.
      – Dmitry Grigoryev
      Aug 21 at 8:22










    • You mention downsides of the "proof of control automation", but in my experience, any DV certificate will be verified with very similar schemes anyway. For instance, here's the methods that Comodo offer, which include a very ACME-like HTTP-based approach. Protecting against rogue registrations would probably be best managed by monitoring Certificate Transparency logs.
      – IMSoP
      Aug 21 at 9:18










    • Watching a CT monitor is a good idea in this type of situation, and yes, there are only the Ten Blessed Methods (which are in fact currently I think 8 or 9 actual methods) so from one CA to another you're only going to see a different mix of methods and some variation in exactly how they work. However, the difference in which methods are offered, the potential to have contractual obligations to use your preferred method and even technical ideas like adding a CAA field to show which methods are permitted do vary by CA, and could mean it makes sense not to use Let's Encrypt.
      – tialaramex
      Aug 25 at 9:11










    • As a concrete example: Facebook has a contract with a big commercial CA. They now use CAA to specify that only that CA may issue certificates for their main domains like facebook.com and fb.com; the contract terms ensure Facebook's in-house technical security team has to clear every new certificate. The CA still has to use one of the Ten Blessed Methods but the contract requires them also to call Facebook Security.
      – tialaramex
      Aug 25 at 13:24

















    up vote
    5
    down vote













    I'll add one that forced my employer partly away from Lets Encrypt: the API rate limiting. Due to the short lifetimes and lack of wildcard support, it is very easy to come close to the rate limits during normal automated operations (automatic renew, etc.). Trying to add a new subdomain can push you over the rate limit, and LE has no way to manually override the limit once hit. If you don't back up the old certificates (who would do so in an automated, cloud-type microservices environment like LE envisions?) all of the affected sites go offline as LE won't reissue the certificates.



    When we realized what happened, there was a moment of "oh $#!#" followed by an emergency commercial certificate requisition just to get the production sites back online. One with a more reasonable 1 year lifespan. Until LE implements proper wildcard support (and even then), we're going to be very wary of their offerings.



    Tl;dr: LE wildcard + API limits makes managing something more complex than "My Personal Homepage" unexpectedly challenging, and promotes poor security practice along the way.






    share|improve this answer





























      up vote
      -1
      down vote













      Yes.



      Downside of using a free or Let's encrypt SSL Certificate-



      Compatibility Issue – Let’s encrypt SSL Certificate not compatible with all platforms. See this link to know the list of incompatible platforms –



      Less validity – A let’s encrypt SSL Certificate comes with a limited validity as 90 days. You have to renew your SSL Certificate in every 90 days. Where as a paid SSL like Comodo comes with long validity like 2 years.



      No business validation – A free SSL Certificate require only domain validation. No business or organization validation to ensure users for a legal business entity.



      Suitable for small business or blog sites – As I added in last point, A free or let’s encrypt SSL Certificate can be availed through domain ownership verification, its not appropriate for a business or ecommerce website where trust and security is a major factor for business.



      No green address bar – You can’t have a green address bar with a free SSL Certificate. An extended validation SSL certificate is the only way to display your business name with green address bar on the browser.



      No Support – If you stuck between the way with Let’s encrypt, you can get online chat or call support. You can contact through forums only to get rid of from the issue.



      Additional security features – A free SSL Certificate does not offer any extra feature like free malware scan, site seal etc.



      No warranty – A Free or Let’s encrypt SSL Certificate does not offer any warranty amount whereas a paid SSL Certificate offers warranty from $10,000 to $1,750,000.



      According to a news, 14,766 Let's Encrypt SSL Certificates Issued to PayPal Phishing Sites as it requires only domain validation



      So, as per my recommendation, paying for an SSL Certificate is really worth.






      share|improve this answer


















      • 5




        (1) LE is only incompatible with older systems. (2) Validity period is a non-issue due to automation. (3) Validation is same as any other DV cert. (4) LE cert is suitable for any type of org. (5) Green bar is for EV certs only (and will go away in near future). (6) I don't know of any cert vendor that does a malware scan and what is a site seal supposed to contribute towards?. (7) What warrant would a cert need to offter? (8) Shady paid CAs sell certs for phishing sites as well (9) The link you refer to discusses Self-Signed certificates, that's unrelated
        – GroundZero
        Aug 23 at 12:14







      • 1




        When the "incompatible systems" list is stuff like Android versions before 2.3.6, Nintendo 3DS and Windows XP earlier than SP3, it's not a concern for 99.999% of people needing SSL certs. Also, the "Why you shouldn't ..." link at the bottom of your post is ONLY about self-signed SSL, it doesn't say anything about Let's Encrypt certificates, you usage of that link is factually incorrect.
        – semi-extrinsic
        Aug 24 at 7:44


















      up vote
      -6
      down vote













      After some research I found out that Let's Encrypt certificates are less compatible with browsers than paid certificates. (Sources: Let's Encrypt vs. Comodo PositiveSSL)






      share|improve this answer




















      • Second link is broken.
        – iamnotmaynard
        Aug 20 at 18:40






      • 5




        what do you care about browsers and platforms that are a decade old not supporting something?
        – warren
        Aug 20 at 20:21






      • 1




        @warren like it or not, but a lot of devices and computers in especially large organisations still run Windows XP, or operating systems of similar age, and may require (strictly controlled, lots of firewalls and proxies) internet access to communicate with each other. Think hand held terminals talking or kiosks. Heck, I'm currently writing the serverside of a system that talks to 15 year old devices over https/ssl. While most customers have upgraded to new devices, some have not.
        – jwenting
        Aug 27 at 5:06










      Your Answer







      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "2"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: true,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f926974%2fis-there-a-reason-to-use-an-ssl-certificate-other-than-lets-encrypts-free-ssl%23new-answer', 'question_page');

      );

      Post as a guest






























      8 Answers
      8






      active

      oldest

      votes








      8 Answers
      8






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      115
      down vote



      accepted










      Certificate lifespan



      Security



      Shorter lifespan is better. Simply because revocation is mostly theoretical, in practice it cannot be relied on (big weakness in the public PKI ecosystem).



      Management



      Without automation: Longer lifespan is more convenient. LE may not be feasible if you, for whatever reason, cannot automate the certificate management

      With automation: Lifespan doesn't matter.



      End-user impression



      End-users are unlikely to have any idea one way or another.



      Level of verification



      Security



      Letsencrypt provides DV level of verification only.

      Buying a cert you get whatever you pay for (starting at DV, with the same level of assertion as with LE).



      DV = only domain name control is verified.

      OV = owner entity (organization) information is verified in addition.

      EV = more thorough version of OV, which has traditionally been awarded with the "green bar" (but the "green bar" appears to be going away soon).



      Management



      When using LE, the work you put in is setting up the necessary automation (in this context, to prove domain control). How much work that is will depend on your environment.



      When buying a cert the DV/OV/EV level will define how much manual work will be required to get the cert. For DV it typically boils down going through a wizard paying and copy/pasting something or clicking something, for OV and EV you can pretty much count on needing to be contacted separately to do additional steps to confirm your identity.



      End-user impression



      End-users probably recognize the current EV "green bar" (which is going away), other than that they don't tend to actually look at the certificate contents.

      Theoretically, though, it is clearly more helpful with a certificate that states information about the controlling entity. But browsers (or other client applications) need to start actually showing this in a useful way before that has any effect for the typical user.



      Installation



      Security



      It is possible to do things incorrectly in ways that expose private keys or similar.
      With LE, the provided tooling is set up around reasonable practices.

      With a person who knows what they are doing, manual steps can obviously also be done securely.



      Management



      LE is very much intended to have all processes automated, their service is entirely API-based and the short lifespan also reflects how everything is centered around automation.



      When buying a cert, even with a CA that provides APIs to regular customers (not really the norm at this point) it will be difficult to properly automate anything other than DV and with DV you are paying for essentially the same thing that LE provides.

      If you are going for OV or EV levels, you can probably only partially automate the process.



      End-user impression



      If the installation is done correctly, the end-user will obviously not know how it was done. The chances of messing things up (eg, forgetting to renew or doing the installation incorrectly when renewing) are less with an automated process.



      Overall



      Traditional means of buying certs are particularly useful if you desire OV/EV certs, are not automating certificate management or want certs used in some other context than HTTPS.






      share|improve this answer
















      • 3




        In some cases there is an insurance aspect, in the event of a CA-side compromise.
        – John Keates
        Aug 20 at 13:03






      • 21




        Do you have a source on EV going away?
        – Puddingfox
        Aug 20 at 15:14






      • 4




        @Puddingfox Good point. I will have to look up the current status and maybe qualify it more if necessary. That said, it's not EV certs that would be going away but the related "green bar" browser UI indicator.
        – Håkan Lindqvist
        Aug 20 at 15:30






      • 5




        In my experience, you can also use Lets Encrypt for mail, so it’s flexible enough for that purpose.
        – Manngo
        Aug 20 at 21:58






      • 10




        @kloddant Huh. You would run the script more than once per renewal period, and of course like any other automated process, it needs monitoring (which triggers before the certificate expires).
        – Jonas Wielicki
        Aug 21 at 15:35














      up vote
      115
      down vote



      accepted










      Certificate lifespan



      Security



      Shorter lifespan is better. Simply because revocation is mostly theoretical, in practice it cannot be relied on (big weakness in the public PKI ecosystem).



      Management



      Without automation: Longer lifespan is more convenient. LE may not be feasible if you, for whatever reason, cannot automate the certificate management

      With automation: Lifespan doesn't matter.



      End-user impression



      End-users are unlikely to have any idea one way or another.



      Level of verification



      Security



      Letsencrypt provides DV level of verification only.

      Buying a cert you get whatever you pay for (starting at DV, with the same level of assertion as with LE).



      DV = only domain name control is verified.

      OV = owner entity (organization) information is verified in addition.

      EV = more thorough version of OV, which has traditionally been awarded with the "green bar" (but the "green bar" appears to be going away soon).



      Management



      When using LE, the work you put in is setting up the necessary automation (in this context, to prove domain control). How much work that is will depend on your environment.



      When buying a cert the DV/OV/EV level will define how much manual work will be required to get the cert. For DV it typically boils down going through a wizard paying and copy/pasting something or clicking something, for OV and EV you can pretty much count on needing to be contacted separately to do additional steps to confirm your identity.



      End-user impression



      End-users probably recognize the current EV "green bar" (which is going away), other than that they don't tend to actually look at the certificate contents.

      Theoretically, though, it is clearly more helpful with a certificate that states information about the controlling entity. But browsers (or other client applications) need to start actually showing this in a useful way before that has any effect for the typical user.



      Installation



      Security



      It is possible to do things incorrectly in ways that expose private keys or similar.
      With LE, the provided tooling is set up around reasonable practices.

      With a person who knows what they are doing, manual steps can obviously also be done securely.



      Management



      LE is very much intended to have all processes automated, their service is entirely API-based and the short lifespan also reflects how everything is centered around automation.



      When buying a cert, even with a CA that provides APIs to regular customers (not really the norm at this point) it will be difficult to properly automate anything other than DV and with DV you are paying for essentially the same thing that LE provides.

      If you are going for OV or EV levels, you can probably only partially automate the process.



      End-user impression



      If the installation is done correctly, the end-user will obviously not know how it was done. The chances of messing things up (eg, forgetting to renew or doing the installation incorrectly when renewing) are less with an automated process.



      Overall



      Traditional means of buying certs are particularly useful if you desire OV/EV certs, are not automating certificate management or want certs used in some other context than HTTPS.






      share|improve this answer
















      • 3




        In some cases there is an insurance aspect, in the event of a CA-side compromise.
        – John Keates
        Aug 20 at 13:03






      • 21




        Do you have a source on EV going away?
        – Puddingfox
        Aug 20 at 15:14






      • 4




        @Puddingfox Good point. I will have to look up the current status and maybe qualify it more if necessary. That said, it's not EV certs that would be going away but the related "green bar" browser UI indicator.
        – Håkan Lindqvist
        Aug 20 at 15:30






      • 5




        In my experience, you can also use Lets Encrypt for mail, so it’s flexible enough for that purpose.
        – Manngo
        Aug 20 at 21:58






      • 10




        @kloddant Huh. You would run the script more than once per renewal period, and of course like any other automated process, it needs monitoring (which triggers before the certificate expires).
        – Jonas Wielicki
        Aug 21 at 15:35












      up vote
      115
      down vote



      accepted







      up vote
      115
      down vote



      accepted






      Certificate lifespan



      Security



      Shorter lifespan is better. Simply because revocation is mostly theoretical, in practice it cannot be relied on (big weakness in the public PKI ecosystem).



      Management



      Without automation: Longer lifespan is more convenient. LE may not be feasible if you, for whatever reason, cannot automate the certificate management

      With automation: Lifespan doesn't matter.



      End-user impression



      End-users are unlikely to have any idea one way or another.



      Level of verification



      Security



      Letsencrypt provides DV level of verification only.

      Buying a cert you get whatever you pay for (starting at DV, with the same level of assertion as with LE).



      DV = only domain name control is verified.

      OV = owner entity (organization) information is verified in addition.

      EV = more thorough version of OV, which has traditionally been awarded with the "green bar" (but the "green bar" appears to be going away soon).



      Management



      When using LE, the work you put in is setting up the necessary automation (in this context, to prove domain control). How much work that is will depend on your environment.



      When buying a cert the DV/OV/EV level will define how much manual work will be required to get the cert. For DV it typically boils down going through a wizard paying and copy/pasting something or clicking something, for OV and EV you can pretty much count on needing to be contacted separately to do additional steps to confirm your identity.



      End-user impression



      End-users probably recognize the current EV "green bar" (which is going away), other than that they don't tend to actually look at the certificate contents.

      Theoretically, though, it is clearly more helpful with a certificate that states information about the controlling entity. But browsers (or other client applications) need to start actually showing this in a useful way before that has any effect for the typical user.



      Installation



      Security



      It is possible to do things incorrectly in ways that expose private keys or similar.
      With LE, the provided tooling is set up around reasonable practices.

      With a person who knows what they are doing, manual steps can obviously also be done securely.



      Management



      LE is very much intended to have all processes automated, their service is entirely API-based and the short lifespan also reflects how everything is centered around automation.



      When buying a cert, even with a CA that provides APIs to regular customers (not really the norm at this point) it will be difficult to properly automate anything other than DV and with DV you are paying for essentially the same thing that LE provides.

      If you are going for OV or EV levels, you can probably only partially automate the process.



      End-user impression



      If the installation is done correctly, the end-user will obviously not know how it was done. The chances of messing things up (eg, forgetting to renew or doing the installation incorrectly when renewing) are less with an automated process.



      Overall



      Traditional means of buying certs are particularly useful if you desire OV/EV certs, are not automating certificate management or want certs used in some other context than HTTPS.






      share|improve this answer












      Certificate lifespan



      Security



      Shorter lifespan is better. Simply because revocation is mostly theoretical, in practice it cannot be relied on (big weakness in the public PKI ecosystem).



      Management



      Without automation: Longer lifespan is more convenient. LE may not be feasible if you, for whatever reason, cannot automate the certificate management

      With automation: Lifespan doesn't matter.



      End-user impression



      End-users are unlikely to have any idea one way or another.



      Level of verification



      Security



      Letsencrypt provides DV level of verification only.

      Buying a cert you get whatever you pay for (starting at DV, with the same level of assertion as with LE).



      DV = only domain name control is verified.

      OV = owner entity (organization) information is verified in addition.

      EV = more thorough version of OV, which has traditionally been awarded with the "green bar" (but the "green bar" appears to be going away soon).



      Management



      When using LE, the work you put in is setting up the necessary automation (in this context, to prove domain control). How much work that is will depend on your environment.



      When buying a cert the DV/OV/EV level will define how much manual work will be required to get the cert. For DV it typically boils down going through a wizard paying and copy/pasting something or clicking something, for OV and EV you can pretty much count on needing to be contacted separately to do additional steps to confirm your identity.



      End-user impression



      End-users probably recognize the current EV "green bar" (which is going away), other than that they don't tend to actually look at the certificate contents.

      Theoretically, though, it is clearly more helpful with a certificate that states information about the controlling entity. But browsers (or other client applications) need to start actually showing this in a useful way before that has any effect for the typical user.



      Installation



      Security



      It is possible to do things incorrectly in ways that expose private keys or similar.
      With LE, the provided tooling is set up around reasonable practices.

      With a person who knows what they are doing, manual steps can obviously also be done securely.



      Management



      LE is very much intended to have all processes automated, their service is entirely API-based and the short lifespan also reflects how everything is centered around automation.



      When buying a cert, even with a CA that provides APIs to regular customers (not really the norm at this point) it will be difficult to properly automate anything other than DV and with DV you are paying for essentially the same thing that LE provides.

      If you are going for OV or EV levels, you can probably only partially automate the process.



      End-user impression



      If the installation is done correctly, the end-user will obviously not know how it was done. The chances of messing things up (eg, forgetting to renew or doing the installation incorrectly when renewing) are less with an automated process.



      Overall



      Traditional means of buying certs are particularly useful if you desire OV/EV certs, are not automating certificate management or want certs used in some other context than HTTPS.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Aug 18 at 12:46









      HÃ¥kan Lindqvist

      19.7k33255




      19.7k33255







      • 3




        In some cases there is an insurance aspect, in the event of a CA-side compromise.
        – John Keates
        Aug 20 at 13:03






      • 21




        Do you have a source on EV going away?
        – Puddingfox
        Aug 20 at 15:14






      • 4




        @Puddingfox Good point. I will have to look up the current status and maybe qualify it more if necessary. That said, it's not EV certs that would be going away but the related "green bar" browser UI indicator.
        – Håkan Lindqvist
        Aug 20 at 15:30






      • 5




        In my experience, you can also use Lets Encrypt for mail, so it’s flexible enough for that purpose.
        – Manngo
        Aug 20 at 21:58






      • 10




        @kloddant Huh. You would run the script more than once per renewal period, and of course like any other automated process, it needs monitoring (which triggers before the certificate expires).
        – Jonas Wielicki
        Aug 21 at 15:35












      • 3




        In some cases there is an insurance aspect, in the event of a CA-side compromise.
        – John Keates
        Aug 20 at 13:03






      • 21




        Do you have a source on EV going away?
        – Puddingfox
        Aug 20 at 15:14






      • 4




        @Puddingfox Good point. I will have to look up the current status and maybe qualify it more if necessary. That said, it's not EV certs that would be going away but the related "green bar" browser UI indicator.
        – Håkan Lindqvist
        Aug 20 at 15:30






      • 5




        In my experience, you can also use Lets Encrypt for mail, so it’s flexible enough for that purpose.
        – Manngo
        Aug 20 at 21:58






      • 10




        @kloddant Huh. You would run the script more than once per renewal period, and of course like any other automated process, it needs monitoring (which triggers before the certificate expires).
        – Jonas Wielicki
        Aug 21 at 15:35







      3




      3




      In some cases there is an insurance aspect, in the event of a CA-side compromise.
      – John Keates
      Aug 20 at 13:03




      In some cases there is an insurance aspect, in the event of a CA-side compromise.
      – John Keates
      Aug 20 at 13:03




      21




      21




      Do you have a source on EV going away?
      – Puddingfox
      Aug 20 at 15:14




      Do you have a source on EV going away?
      – Puddingfox
      Aug 20 at 15:14




      4




      4




      @Puddingfox Good point. I will have to look up the current status and maybe qualify it more if necessary. That said, it's not EV certs that would be going away but the related "green bar" browser UI indicator.
      – Håkan Lindqvist
      Aug 20 at 15:30




      @Puddingfox Good point. I will have to look up the current status and maybe qualify it more if necessary. That said, it's not EV certs that would be going away but the related "green bar" browser UI indicator.
      – Håkan Lindqvist
      Aug 20 at 15:30




      5




      5




      In my experience, you can also use Lets Encrypt for mail, so it’s flexible enough for that purpose.
      – Manngo
      Aug 20 at 21:58




      In my experience, you can also use Lets Encrypt for mail, so it’s flexible enough for that purpose.
      – Manngo
      Aug 20 at 21:58




      10




      10




      @kloddant Huh. You would run the script more than once per renewal period, and of course like any other automated process, it needs monitoring (which triggers before the certificate expires).
      – Jonas Wielicki
      Aug 21 at 15:35




      @kloddant Huh. You would run the script more than once per renewal period, and of course like any other automated process, it needs monitoring (which triggers before the certificate expires).
      – Jonas Wielicki
      Aug 21 at 15:35












      up vote
      75
      down vote













      From a purely technical perspective:



      • The fact that the certificates are only valid for 3 months. Can be a nuisance to maintain depending on your change management procedures and infrastructure.

      • The purpose of Let's Encrypt certificates is limited. You can't use them for your email, code signing or timestamping.

        Check with: openssl x509 -in cert.pem -noout -text


        X509v3 Extended Key Usage:

        TLS Web Server Authentication, TLS Web Client Authentication




      From an end-user perspective:



      • The lack of Extended Validation means "no green bar" in certain webbrowsers.

        • However, Chrome will be phasing out the green bar in September 2018 in favor of a small lock icon and eventually no special indicator and will instead only show warnings for insecure pages.






      share|improve this answer


















      • 23




        Note that Chrome is actively moving towards showing nothing special for HTTPS at all and the next major release of OSX and iOS will see Safari not show anything special for EV. It appears the major browser vendors are moving away from EV. Many of the top web sites don’t even use it.
        – Greg W
        Aug 18 at 10:45






      • 18




        Regarding the point made about change management, the idea behind the 3 month lifespan is that the process of getting and renewing certs is meant to be entirely automated. Ie, if used as intended, the change would be setting up that automation, not repeatedly installing certificates manually. But if there is policy against automating that, it would probably make it a no-go.
        – Håkan Lindqvist
        Aug 18 at 11:48






      • 8




        TLS Web Server Authentication is sufficient for securing, e.g. SMTP, IMAP, POP3 servers. It's not valid for S/MIME though.
        – Michael Hampton♦
        Aug 18 at 14:12






      • 5




        To the commentators- please note that the above is a community wiki intended to be edited by anyone
        – HBruijn♦
        Aug 18 at 20:46







      • 12




        @ripper234 You mean like the serious / user facing website serverfault.com you're on right now? This site doesn't use an EV cert. Neither does google.com. Or microsoft.com. Or cisco.com. And browsers are phasing out the green bar. If an EV certificate is important to you, by all means pay for it, but surely plenty of important and user facing sites have come to a different conclusion about its value.
        – Zach Lipton
        Aug 20 at 1:19














      up vote
      75
      down vote













      From a purely technical perspective:



      • The fact that the certificates are only valid for 3 months. Can be a nuisance to maintain depending on your change management procedures and infrastructure.

      • The purpose of Let's Encrypt certificates is limited. You can't use them for your email, code signing or timestamping.

        Check with: openssl x509 -in cert.pem -noout -text


        X509v3 Extended Key Usage:

        TLS Web Server Authentication, TLS Web Client Authentication




      From an end-user perspective:



      • The lack of Extended Validation means "no green bar" in certain webbrowsers.

        • However, Chrome will be phasing out the green bar in September 2018 in favor of a small lock icon and eventually no special indicator and will instead only show warnings for insecure pages.






      share|improve this answer


















      • 23




        Note that Chrome is actively moving towards showing nothing special for HTTPS at all and the next major release of OSX and iOS will see Safari not show anything special for EV. It appears the major browser vendors are moving away from EV. Many of the top web sites don’t even use it.
        – Greg W
        Aug 18 at 10:45






      • 18




        Regarding the point made about change management, the idea behind the 3 month lifespan is that the process of getting and renewing certs is meant to be entirely automated. Ie, if used as intended, the change would be setting up that automation, not repeatedly installing certificates manually. But if there is policy against automating that, it would probably make it a no-go.
        – Håkan Lindqvist
        Aug 18 at 11:48






      • 8




        TLS Web Server Authentication is sufficient for securing, e.g. SMTP, IMAP, POP3 servers. It's not valid for S/MIME though.
        – Michael Hampton♦
        Aug 18 at 14:12






      • 5




        To the commentators- please note that the above is a community wiki intended to be edited by anyone
        – HBruijn♦
        Aug 18 at 20:46







      • 12




        @ripper234 You mean like the serious / user facing website serverfault.com you're on right now? This site doesn't use an EV cert. Neither does google.com. Or microsoft.com. Or cisco.com. And browsers are phasing out the green bar. If an EV certificate is important to you, by all means pay for it, but surely plenty of important and user facing sites have come to a different conclusion about its value.
        – Zach Lipton
        Aug 20 at 1:19












      up vote
      75
      down vote










      up vote
      75
      down vote









      From a purely technical perspective:



      • The fact that the certificates are only valid for 3 months. Can be a nuisance to maintain depending on your change management procedures and infrastructure.

      • The purpose of Let's Encrypt certificates is limited. You can't use them for your email, code signing or timestamping.

        Check with: openssl x509 -in cert.pem -noout -text


        X509v3 Extended Key Usage:

        TLS Web Server Authentication, TLS Web Client Authentication




      From an end-user perspective:



      • The lack of Extended Validation means "no green bar" in certain webbrowsers.

        • However, Chrome will be phasing out the green bar in September 2018 in favor of a small lock icon and eventually no special indicator and will instead only show warnings for insecure pages.






      share|improve this answer














      From a purely technical perspective:



      • The fact that the certificates are only valid for 3 months. Can be a nuisance to maintain depending on your change management procedures and infrastructure.

      • The purpose of Let's Encrypt certificates is limited. You can't use them for your email, code signing or timestamping.

        Check with: openssl x509 -in cert.pem -noout -text


        X509v3 Extended Key Usage:

        TLS Web Server Authentication, TLS Web Client Authentication




      From an end-user perspective:



      • The lack of Extended Validation means "no green bar" in certain webbrowsers.

        • However, Chrome will be phasing out the green bar in September 2018 in favor of a small lock icon and eventually no special indicator and will instead only show warnings for insecure pages.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Aug 22 at 13:54


























      community wiki





      2 revs, 2 users 96%
      HBruijn








      • 23




        Note that Chrome is actively moving towards showing nothing special for HTTPS at all and the next major release of OSX and iOS will see Safari not show anything special for EV. It appears the major browser vendors are moving away from EV. Many of the top web sites don’t even use it.
        – Greg W
        Aug 18 at 10:45






      • 18




        Regarding the point made about change management, the idea behind the 3 month lifespan is that the process of getting and renewing certs is meant to be entirely automated. Ie, if used as intended, the change would be setting up that automation, not repeatedly installing certificates manually. But if there is policy against automating that, it would probably make it a no-go.
        – Håkan Lindqvist
        Aug 18 at 11:48






      • 8




        TLS Web Server Authentication is sufficient for securing, e.g. SMTP, IMAP, POP3 servers. It's not valid for S/MIME though.
        – Michael Hampton♦
        Aug 18 at 14:12






      • 5




        To the commentators- please note that the above is a community wiki intended to be edited by anyone
        – HBruijn♦
        Aug 18 at 20:46







      • 12




        @ripper234 You mean like the serious / user facing website serverfault.com you're on right now? This site doesn't use an EV cert. Neither does google.com. Or microsoft.com. Or cisco.com. And browsers are phasing out the green bar. If an EV certificate is important to you, by all means pay for it, but surely plenty of important and user facing sites have come to a different conclusion about its value.
        – Zach Lipton
        Aug 20 at 1:19












      • 23




        Note that Chrome is actively moving towards showing nothing special for HTTPS at all and the next major release of OSX and iOS will see Safari not show anything special for EV. It appears the major browser vendors are moving away from EV. Many of the top web sites don’t even use it.
        – Greg W
        Aug 18 at 10:45






      • 18




        Regarding the point made about change management, the idea behind the 3 month lifespan is that the process of getting and renewing certs is meant to be entirely automated. Ie, if used as intended, the change would be setting up that automation, not repeatedly installing certificates manually. But if there is policy against automating that, it would probably make it a no-go.
        – Håkan Lindqvist
        Aug 18 at 11:48






      • 8




        TLS Web Server Authentication is sufficient for securing, e.g. SMTP, IMAP, POP3 servers. It's not valid for S/MIME though.
        – Michael Hampton♦
        Aug 18 at 14:12






      • 5




        To the commentators- please note that the above is a community wiki intended to be edited by anyone
        – HBruijn♦
        Aug 18 at 20:46







      • 12




        @ripper234 You mean like the serious / user facing website serverfault.com you're on right now? This site doesn't use an EV cert. Neither does google.com. Or microsoft.com. Or cisco.com. And browsers are phasing out the green bar. If an EV certificate is important to you, by all means pay for it, but surely plenty of important and user facing sites have come to a different conclusion about its value.
        – Zach Lipton
        Aug 20 at 1:19







      23




      23




      Note that Chrome is actively moving towards showing nothing special for HTTPS at all and the next major release of OSX and iOS will see Safari not show anything special for EV. It appears the major browser vendors are moving away from EV. Many of the top web sites don’t even use it.
      – Greg W
      Aug 18 at 10:45




      Note that Chrome is actively moving towards showing nothing special for HTTPS at all and the next major release of OSX and iOS will see Safari not show anything special for EV. It appears the major browser vendors are moving away from EV. Many of the top web sites don’t even use it.
      – Greg W
      Aug 18 at 10:45




      18




      18




      Regarding the point made about change management, the idea behind the 3 month lifespan is that the process of getting and renewing certs is meant to be entirely automated. Ie, if used as intended, the change would be setting up that automation, not repeatedly installing certificates manually. But if there is policy against automating that, it would probably make it a no-go.
      – Håkan Lindqvist
      Aug 18 at 11:48




      Regarding the point made about change management, the idea behind the 3 month lifespan is that the process of getting and renewing certs is meant to be entirely automated. Ie, if used as intended, the change would be setting up that automation, not repeatedly installing certificates manually. But if there is policy against automating that, it would probably make it a no-go.
      – Håkan Lindqvist
      Aug 18 at 11:48




      8




      8




      TLS Web Server Authentication is sufficient for securing, e.g. SMTP, IMAP, POP3 servers. It's not valid for S/MIME though.
      – Michael Hampton♦
      Aug 18 at 14:12




      TLS Web Server Authentication is sufficient for securing, e.g. SMTP, IMAP, POP3 servers. It's not valid for S/MIME though.
      – Michael Hampton♦
      Aug 18 at 14:12




      5




      5




      To the commentators- please note that the above is a community wiki intended to be edited by anyone
      – HBruijn♦
      Aug 18 at 20:46





      To the commentators- please note that the above is a community wiki intended to be edited by anyone
      – HBruijn♦
      Aug 18 at 20:46





      12




      12




      @ripper234 You mean like the serious / user facing website serverfault.com you're on right now? This site doesn't use an EV cert. Neither does google.com. Or microsoft.com. Or cisco.com. And browsers are phasing out the green bar. If an EV certificate is important to you, by all means pay for it, but surely plenty of important and user facing sites have come to a different conclusion about its value.
      – Zach Lipton
      Aug 20 at 1:19




      @ripper234 You mean like the serious / user facing website serverfault.com you're on right now? This site doesn't use an EV cert. Neither does google.com. Or microsoft.com. Or cisco.com. And browsers are phasing out the green bar. If an EV certificate is important to you, by all means pay for it, but surely plenty of important and user facing sites have come to a different conclusion about its value.
      – Zach Lipton
      Aug 20 at 1:19










      up vote
      28
      down vote













      I'd like to offer some counter points for the arguments used against Let's Encrypt here.



      Short lifetime



      Yes, they have a short lifetime as explained in the faq: https://letsencrypt.org/2015/11/09/why-90-days.html To quote the page:




      1. They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.


      2. They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t
        continue to expect system administrators to manually handle renewals.
        Once issuance and renewal are automated, shorter lifetimes won’t be
        any less convenient than longer ones.




      Lack of EV



      There is no plan for EV support. The reasoning (from https://community.letsencrypt.org/t/plans-for-extended-validation/409) is:




      We expect that Let’s Encrypt won’t support EV, because the EV process will always require human effort, which will require paying someone. Our model is to issue certificates free of charge, which requires a level automation that doesn’t seem compatible with EV.




      Furthermore there are some that believe that EV is harmful, like this blogpost (https://stripe.ian.sh/):




      James Burton, for example, recently obtained an EV certificate for his company "Identity Verified". Unfortunately, users are simply not equipped to deal with the nuances of these entities, and this creates a significant vector for phishing.




      A classic real world example of this is sslstrip. Homograph sites with legitimately purchased certificates are a real-world attack for which EV doesn't provide a sufficient defense currently.






      share|improve this answer
























        up vote
        28
        down vote













        I'd like to offer some counter points for the arguments used against Let's Encrypt here.



        Short lifetime



        Yes, they have a short lifetime as explained in the faq: https://letsencrypt.org/2015/11/09/why-90-days.html To quote the page:




        1. They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.


        2. They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t
          continue to expect system administrators to manually handle renewals.
          Once issuance and renewal are automated, shorter lifetimes won’t be
          any less convenient than longer ones.




        Lack of EV



        There is no plan for EV support. The reasoning (from https://community.letsencrypt.org/t/plans-for-extended-validation/409) is:




        We expect that Let’s Encrypt won’t support EV, because the EV process will always require human effort, which will require paying someone. Our model is to issue certificates free of charge, which requires a level automation that doesn’t seem compatible with EV.




        Furthermore there are some that believe that EV is harmful, like this blogpost (https://stripe.ian.sh/):




        James Burton, for example, recently obtained an EV certificate for his company "Identity Verified". Unfortunately, users are simply not equipped to deal with the nuances of these entities, and this creates a significant vector for phishing.




        A classic real world example of this is sslstrip. Homograph sites with legitimately purchased certificates are a real-world attack for which EV doesn't provide a sufficient defense currently.






        share|improve this answer






















          up vote
          28
          down vote










          up vote
          28
          down vote









          I'd like to offer some counter points for the arguments used against Let's Encrypt here.



          Short lifetime



          Yes, they have a short lifetime as explained in the faq: https://letsencrypt.org/2015/11/09/why-90-days.html To quote the page:




          1. They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.


          2. They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t
            continue to expect system administrators to manually handle renewals.
            Once issuance and renewal are automated, shorter lifetimes won’t be
            any less convenient than longer ones.




          Lack of EV



          There is no plan for EV support. The reasoning (from https://community.letsencrypt.org/t/plans-for-extended-validation/409) is:




          We expect that Let’s Encrypt won’t support EV, because the EV process will always require human effort, which will require paying someone. Our model is to issue certificates free of charge, which requires a level automation that doesn’t seem compatible with EV.




          Furthermore there are some that believe that EV is harmful, like this blogpost (https://stripe.ian.sh/):




          James Burton, for example, recently obtained an EV certificate for his company "Identity Verified". Unfortunately, users are simply not equipped to deal with the nuances of these entities, and this creates a significant vector for phishing.




          A classic real world example of this is sslstrip. Homograph sites with legitimately purchased certificates are a real-world attack for which EV doesn't provide a sufficient defense currently.






          share|improve this answer












          I'd like to offer some counter points for the arguments used against Let's Encrypt here.



          Short lifetime



          Yes, they have a short lifetime as explained in the faq: https://letsencrypt.org/2015/11/09/why-90-days.html To quote the page:




          1. They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.


          2. They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t
            continue to expect system administrators to manually handle renewals.
            Once issuance and renewal are automated, shorter lifetimes won’t be
            any less convenient than longer ones.




          Lack of EV



          There is no plan for EV support. The reasoning (from https://community.letsencrypt.org/t/plans-for-extended-validation/409) is:




          We expect that Let’s Encrypt won’t support EV, because the EV process will always require human effort, which will require paying someone. Our model is to issue certificates free of charge, which requires a level automation that doesn’t seem compatible with EV.




          Furthermore there are some that believe that EV is harmful, like this blogpost (https://stripe.ian.sh/):




          James Burton, for example, recently obtained an EV certificate for his company "Identity Verified". Unfortunately, users are simply not equipped to deal with the nuances of these entities, and this creates a significant vector for phishing.




          A classic real world example of this is sslstrip. Homograph sites with legitimately purchased certificates are a real-world attack for which EV doesn't provide a sufficient defense currently.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Aug 18 at 11:47









          user483794

          28112




          28112




















              up vote
              5
              down vote













              Unless you need a certificate for something other than web, there are no real downsides, but surely perceived ones. Although the problems are only perceived, as the owner of a website you may have no other choice but to address them (if business interest forbids showing the middle finger).



              The single biggest downside is, for the time being, that your site will show as somewhat inferior, maybe dangerous because it doesn't have the nice green badge that some other sites have. What does that badge mean? Nothing, really. But it does suggest that your site is "secure" (some browsers even use that exact word). Alas, users are people, and people are stupid. One or the other will take your site as not trustworthy (without understanding any of the implications) just because the browser doesn't say it's secure.



              If ignoring these customers/visitors is a valid possibility, no problem. If you cannot afford that business-wise, you will have to spend money. No other option.



              The other perceived problem is the one about certificate lifetime. But it is actually an advantage, not a disadvantage. Shorter validity means that certificates have to be updated more often, both server-side, and client-side, alright.

              As for server-side, this happens with a cron job, so it's actually less hassle and more reliable than usual. No way you can forget, no way to be late, no way to accidentially do something wrong, no need to log in with an administrative account (... more than once). On the client-side, so what. Browsers update certificates all the time, it's no biggie. The user doesn't even know it happens. There's very slightly more traffic to be had when updating every 3 months instead of every 2 years, but seriously... that is not an issue.






              share|improve this answer
















              • 2




                @HÃ¥kanLindqvist: That's the exact problem. I can set up a malware site and spend $5.99, and the average user will trust my malware contents because it says "secure". The same user won't trust your entirely harmless, legitimate site with a lets-encrypt certificate. Because, well, it's not secure. But alas, these are things you just cannot change.
                – Damon
                Aug 18 at 12:58






              • 10




                The LE cert is just an example of a DV cert, though (which is most likely all you'd be getting for just $5.99). LE certs show as "Secure" in current browsers.
                – Håkan Lindqvist
                Aug 18 at 13:03






              • 1




                do you consider email servers as part of the web? letsencrypt certificates were insufficient for me because i had to run my own email server
                – hanshenrik
                Aug 18 at 14:05






              • 7




                @hanshenrik you can use LE just fine with mail servers. For example, I use github.com/hlandau/acme Let's Encrypt client not only for my HTTPS, but also for TLS in SMTP, IMAP, POP3, XMPP...
                – Matija Nalis
                Aug 20 at 10:12






              • 4




                @hanshenrik - I run LE certs for my mail server: no issues at all
                – warren
                Aug 20 at 20:19














              up vote
              5
              down vote













              Unless you need a certificate for something other than web, there are no real downsides, but surely perceived ones. Although the problems are only perceived, as the owner of a website you may have no other choice but to address them (if business interest forbids showing the middle finger).



              The single biggest downside is, for the time being, that your site will show as somewhat inferior, maybe dangerous because it doesn't have the nice green badge that some other sites have. What does that badge mean? Nothing, really. But it does suggest that your site is "secure" (some browsers even use that exact word). Alas, users are people, and people are stupid. One or the other will take your site as not trustworthy (without understanding any of the implications) just because the browser doesn't say it's secure.



              If ignoring these customers/visitors is a valid possibility, no problem. If you cannot afford that business-wise, you will have to spend money. No other option.



              The other perceived problem is the one about certificate lifetime. But it is actually an advantage, not a disadvantage. Shorter validity means that certificates have to be updated more often, both server-side, and client-side, alright.

              As for server-side, this happens with a cron job, so it's actually less hassle and more reliable than usual. No way you can forget, no way to be late, no way to accidentially do something wrong, no need to log in with an administrative account (... more than once). On the client-side, so what. Browsers update certificates all the time, it's no biggie. The user doesn't even know it happens. There's very slightly more traffic to be had when updating every 3 months instead of every 2 years, but seriously... that is not an issue.






              share|improve this answer
















              • 2




                @HÃ¥kanLindqvist: That's the exact problem. I can set up a malware site and spend $5.99, and the average user will trust my malware contents because it says "secure". The same user won't trust your entirely harmless, legitimate site with a lets-encrypt certificate. Because, well, it's not secure. But alas, these are things you just cannot change.
                – Damon
                Aug 18 at 12:58






              • 10




                The LE cert is just an example of a DV cert, though (which is most likely all you'd be getting for just $5.99). LE certs show as "Secure" in current browsers.
                – Håkan Lindqvist
                Aug 18 at 13:03






              • 1




                do you consider email servers as part of the web? letsencrypt certificates were insufficient for me because i had to run my own email server
                – hanshenrik
                Aug 18 at 14:05






              • 7




                @hanshenrik you can use LE just fine with mail servers. For example, I use github.com/hlandau/acme Let's Encrypt client not only for my HTTPS, but also for TLS in SMTP, IMAP, POP3, XMPP...
                – Matija Nalis
                Aug 20 at 10:12






              • 4




                @hanshenrik - I run LE certs for my mail server: no issues at all
                – warren
                Aug 20 at 20:19












              up vote
              5
              down vote










              up vote
              5
              down vote









              Unless you need a certificate for something other than web, there are no real downsides, but surely perceived ones. Although the problems are only perceived, as the owner of a website you may have no other choice but to address them (if business interest forbids showing the middle finger).



              The single biggest downside is, for the time being, that your site will show as somewhat inferior, maybe dangerous because it doesn't have the nice green badge that some other sites have. What does that badge mean? Nothing, really. But it does suggest that your site is "secure" (some browsers even use that exact word). Alas, users are people, and people are stupid. One or the other will take your site as not trustworthy (without understanding any of the implications) just because the browser doesn't say it's secure.



              If ignoring these customers/visitors is a valid possibility, no problem. If you cannot afford that business-wise, you will have to spend money. No other option.



              The other perceived problem is the one about certificate lifetime. But it is actually an advantage, not a disadvantage. Shorter validity means that certificates have to be updated more often, both server-side, and client-side, alright.

              As for server-side, this happens with a cron job, so it's actually less hassle and more reliable than usual. No way you can forget, no way to be late, no way to accidentially do something wrong, no need to log in with an administrative account (... more than once). On the client-side, so what. Browsers update certificates all the time, it's no biggie. The user doesn't even know it happens. There's very slightly more traffic to be had when updating every 3 months instead of every 2 years, but seriously... that is not an issue.






              share|improve this answer












              Unless you need a certificate for something other than web, there are no real downsides, but surely perceived ones. Although the problems are only perceived, as the owner of a website you may have no other choice but to address them (if business interest forbids showing the middle finger).



              The single biggest downside is, for the time being, that your site will show as somewhat inferior, maybe dangerous because it doesn't have the nice green badge that some other sites have. What does that badge mean? Nothing, really. But it does suggest that your site is "secure" (some browsers even use that exact word). Alas, users are people, and people are stupid. One or the other will take your site as not trustworthy (without understanding any of the implications) just because the browser doesn't say it's secure.



              If ignoring these customers/visitors is a valid possibility, no problem. If you cannot afford that business-wise, you will have to spend money. No other option.



              The other perceived problem is the one about certificate lifetime. But it is actually an advantage, not a disadvantage. Shorter validity means that certificates have to be updated more often, both server-side, and client-side, alright.

              As for server-side, this happens with a cron job, so it's actually less hassle and more reliable than usual. No way you can forget, no way to be late, no way to accidentially do something wrong, no need to log in with an administrative account (... more than once). On the client-side, so what. Browsers update certificates all the time, it's no biggie. The user doesn't even know it happens. There's very slightly more traffic to be had when updating every 3 months instead of every 2 years, but seriously... that is not an issue.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Aug 18 at 12:43









              Damon

              20112




              20112







              • 2




                @HÃ¥kanLindqvist: That's the exact problem. I can set up a malware site and spend $5.99, and the average user will trust my malware contents because it says "secure". The same user won't trust your entirely harmless, legitimate site with a lets-encrypt certificate. Because, well, it's not secure. But alas, these are things you just cannot change.
                – Damon
                Aug 18 at 12:58






              • 10




                The LE cert is just an example of a DV cert, though (which is most likely all you'd be getting for just $5.99). LE certs show as "Secure" in current browsers.
                – Håkan Lindqvist
                Aug 18 at 13:03






              • 1




                do you consider email servers as part of the web? letsencrypt certificates were insufficient for me because i had to run my own email server
                – hanshenrik
                Aug 18 at 14:05






              • 7




                @hanshenrik you can use LE just fine with mail servers. For example, I use github.com/hlandau/acme Let's Encrypt client not only for my HTTPS, but also for TLS in SMTP, IMAP, POP3, XMPP...
                – Matija Nalis
                Aug 20 at 10:12






              • 4




                @hanshenrik - I run LE certs for my mail server: no issues at all
                – warren
                Aug 20 at 20:19












              • 2




                @HÃ¥kanLindqvist: That's the exact problem. I can set up a malware site and spend $5.99, and the average user will trust my malware contents because it says "secure". The same user won't trust your entirely harmless, legitimate site with a lets-encrypt certificate. Because, well, it's not secure. But alas, these are things you just cannot change.
                – Damon
                Aug 18 at 12:58






              • 10




                The LE cert is just an example of a DV cert, though (which is most likely all you'd be getting for just $5.99). LE certs show as "Secure" in current browsers.
                – Håkan Lindqvist
                Aug 18 at 13:03






              • 1




                do you consider email servers as part of the web? letsencrypt certificates were insufficient for me because i had to run my own email server
                – hanshenrik
                Aug 18 at 14:05






              • 7




                @hanshenrik you can use LE just fine with mail servers. For example, I use github.com/hlandau/acme Let's Encrypt client not only for my HTTPS, but also for TLS in SMTP, IMAP, POP3, XMPP...
                – Matija Nalis
                Aug 20 at 10:12






              • 4




                @hanshenrik - I run LE certs for my mail server: no issues at all
                – warren
                Aug 20 at 20:19







              2




              2




              @HÃ¥kanLindqvist: That's the exact problem. I can set up a malware site and spend $5.99, and the average user will trust my malware contents because it says "secure". The same user won't trust your entirely harmless, legitimate site with a lets-encrypt certificate. Because, well, it's not secure. But alas, these are things you just cannot change.
              – Damon
              Aug 18 at 12:58




              @HÃ¥kanLindqvist: That's the exact problem. I can set up a malware site and spend $5.99, and the average user will trust my malware contents because it says "secure". The same user won't trust your entirely harmless, legitimate site with a lets-encrypt certificate. Because, well, it's not secure. But alas, these are things you just cannot change.
              – Damon
              Aug 18 at 12:58




              10




              10




              The LE cert is just an example of a DV cert, though (which is most likely all you'd be getting for just $5.99). LE certs show as "Secure" in current browsers.
              – Håkan Lindqvist
              Aug 18 at 13:03




              The LE cert is just an example of a DV cert, though (which is most likely all you'd be getting for just $5.99). LE certs show as "Secure" in current browsers.
              – Håkan Lindqvist
              Aug 18 at 13:03




              1




              1




              do you consider email servers as part of the web? letsencrypt certificates were insufficient for me because i had to run my own email server
              – hanshenrik
              Aug 18 at 14:05




              do you consider email servers as part of the web? letsencrypt certificates were insufficient for me because i had to run my own email server
              – hanshenrik
              Aug 18 at 14:05




              7




              7




              @hanshenrik you can use LE just fine with mail servers. For example, I use github.com/hlandau/acme Let's Encrypt client not only for my HTTPS, but also for TLS in SMTP, IMAP, POP3, XMPP...
              – Matija Nalis
              Aug 20 at 10:12




              @hanshenrik you can use LE just fine with mail servers. For example, I use github.com/hlandau/acme Let's Encrypt client not only for my HTTPS, but also for TLS in SMTP, IMAP, POP3, XMPP...
              – Matija Nalis
              Aug 20 at 10:12




              4




              4




              @hanshenrik - I run LE certs for my mail server: no issues at all
              – warren
              Aug 20 at 20:19




              @hanshenrik - I run LE certs for my mail server: no issues at all
              – warren
              Aug 20 at 20:19










              up vote
              5
              down vote













              There are two groups of downsides worth considering.



              1. Downsides to using the Let's Encrypt service



              Let's Encrypt requires that the exact name, or the (sub-)domain if you're requesting a wildcard, exists in the public Internet DNS. Even if you prove control over example.com, Let's Encrypt won't issue you certificates for some.other.name.in.example.com without seeing that in public DNS. The machines named needn't have public address records, they can be firewalled off, or even physically disconnected, but the public DNS name needs to exist.



              Let's Encrypt certificate lifetimes of 90 days mean you need to automate because ain't nobody got time for that. This is in fact the intent of the service - to herd people towards automating this essential work rather than perversely doing it manually while they automate away many harder tasks. But if you can't automate for any reason it's a negative - if you have tools, appliances or whatever that block automation consider any commercial SSL cert costs as part of the ongoing cost of those tools/ appliances/ whatever in cost planning. Contrariwise offset savings from not needing to buy commercial certs in pricing of new tools / appliances / etcetera that automate this (with Let's Encrypt or not)



              The Let's Encrypt proof of control automation may not suit your organisation's rules. For example if you have employees who're allowed to reconfigure Apache but shouldn't get SSL certs for company domain names then Let's Encrypt is a poor fit. Note that in this case just not using them is the Wrong Thing(TM) you should use CAA to explicitly disable Let's Encrypt for your domains.



              If Let's Encrypt policy refuses you, the only "court of appeal" is to ask in its public forums and hope one of their staff is able to offer a way forward. This may happen if, for example, your site has a DNS name their systems decide is "confusingly similar" to certain famous properties like big banks or Google. For sensible reasons the exact policies of each public CA in this regard are not open to public scrutiny so you may only realise you can't have a Let's Encrypt cert when you request it and get a "Policy forbids..." response.



              2. Downsides to a Let's Encrypt certificate itself



              Let's Encrypt certificates are trusted by major web browsers today via ISRG (the charity providing the Let's Encrypt service) but older systems trust Let's Encrypt via IdenTrust, a relatively obscure Certificate Authority which controls "DST Root CA X3". This gets the job done for most people, but it isn't the most broadly trusted root in the world. For example the abandoned Nintendo WiiU console had a web browser, obviously Nintendo won't be shipping updates for WiiU and so that browser is abandoned, it doesn't trust Let's Encrypt.



              Let's Encrypt only issues certificates for the Web PKI - servers with Internet names which use the SSL/TLS protocol. So that's the Web obviously, and your IMAP, SMTP, some types of VPN server, dozens of things, but not everything. In particular Let's Encrypt doesn't offer certificates at all for S/MIME (a way to encrypt email at rest, rather than just when it's in transit) nor for code signing or document signing. If you want a "one stop shop" for certificates, this may be enough reason not to use Let's Encrypt.



              Even in the Web PKI, Let's Encrypt offers only "DV" certificates, meaning any details about yourself or your organisation other than FQDNs aren't mentioned in the certificate. Even if you write them into a CSR they're just discarded. This may be a blocker for some specialist applications.



              Let's Encrypt automation means you're constrained exactly by what the automation allows even if there is no other reasons why you can't have something. New types of public key, new X.509 extensions and other additions have to be explicitly enabled by Let's Encrypt on their own timeline, and of course you can't just offer to pay extra to get the features you want although donations are welcome.



              Nevertheless, for almost everyone, almost always, Let's Encrypt is a good first choice for putting certificates on your TLS servers in a fire-and-forget way. Starting with the assumption that you'll use Let's Encrypt is a sensible way to approach this decision.






              share|improve this answer
















              • 3




                I wonder if not supporting Nintendo WiiU is a big deal, considering how few websites that browser can display correctly.
                – Dmitry Grigoryev
                Aug 21 at 8:22










              • You mention downsides of the "proof of control automation", but in my experience, any DV certificate will be verified with very similar schemes anyway. For instance, here's the methods that Comodo offer, which include a very ACME-like HTTP-based approach. Protecting against rogue registrations would probably be best managed by monitoring Certificate Transparency logs.
                – IMSoP
                Aug 21 at 9:18










              • Watching a CT monitor is a good idea in this type of situation, and yes, there are only the Ten Blessed Methods (which are in fact currently I think 8 or 9 actual methods) so from one CA to another you're only going to see a different mix of methods and some variation in exactly how they work. However, the difference in which methods are offered, the potential to have contractual obligations to use your preferred method and even technical ideas like adding a CAA field to show which methods are permitted do vary by CA, and could mean it makes sense not to use Let's Encrypt.
                – tialaramex
                Aug 25 at 9:11










              • As a concrete example: Facebook has a contract with a big commercial CA. They now use CAA to specify that only that CA may issue certificates for their main domains like facebook.com and fb.com; the contract terms ensure Facebook's in-house technical security team has to clear every new certificate. The CA still has to use one of the Ten Blessed Methods but the contract requires them also to call Facebook Security.
                – tialaramex
                Aug 25 at 13:24














              up vote
              5
              down vote













              There are two groups of downsides worth considering.



              1. Downsides to using the Let's Encrypt service



              Let's Encrypt requires that the exact name, or the (sub-)domain if you're requesting a wildcard, exists in the public Internet DNS. Even if you prove control over example.com, Let's Encrypt won't issue you certificates for some.other.name.in.example.com without seeing that in public DNS. The machines named needn't have public address records, they can be firewalled off, or even physically disconnected, but the public DNS name needs to exist.



              Let's Encrypt certificate lifetimes of 90 days mean you need to automate because ain't nobody got time for that. This is in fact the intent of the service - to herd people towards automating this essential work rather than perversely doing it manually while they automate away many harder tasks. But if you can't automate for any reason it's a negative - if you have tools, appliances or whatever that block automation consider any commercial SSL cert costs as part of the ongoing cost of those tools/ appliances/ whatever in cost planning. Contrariwise offset savings from not needing to buy commercial certs in pricing of new tools / appliances / etcetera that automate this (with Let's Encrypt or not)



              The Let's Encrypt proof of control automation may not suit your organisation's rules. For example if you have employees who're allowed to reconfigure Apache but shouldn't get SSL certs for company domain names then Let's Encrypt is a poor fit. Note that in this case just not using them is the Wrong Thing(TM) you should use CAA to explicitly disable Let's Encrypt for your domains.



              If Let's Encrypt policy refuses you, the only "court of appeal" is to ask in its public forums and hope one of their staff is able to offer a way forward. This may happen if, for example, your site has a DNS name their systems decide is "confusingly similar" to certain famous properties like big banks or Google. For sensible reasons the exact policies of each public CA in this regard are not open to public scrutiny so you may only realise you can't have a Let's Encrypt cert when you request it and get a "Policy forbids..." response.



              2. Downsides to a Let's Encrypt certificate itself



              Let's Encrypt certificates are trusted by major web browsers today via ISRG (the charity providing the Let's Encrypt service) but older systems trust Let's Encrypt via IdenTrust, a relatively obscure Certificate Authority which controls "DST Root CA X3". This gets the job done for most people, but it isn't the most broadly trusted root in the world. For example the abandoned Nintendo WiiU console had a web browser, obviously Nintendo won't be shipping updates for WiiU and so that browser is abandoned, it doesn't trust Let's Encrypt.



              Let's Encrypt only issues certificates for the Web PKI - servers with Internet names which use the SSL/TLS protocol. So that's the Web obviously, and your IMAP, SMTP, some types of VPN server, dozens of things, but not everything. In particular Let's Encrypt doesn't offer certificates at all for S/MIME (a way to encrypt email at rest, rather than just when it's in transit) nor for code signing or document signing. If you want a "one stop shop" for certificates, this may be enough reason not to use Let's Encrypt.



              Even in the Web PKI, Let's Encrypt offers only "DV" certificates, meaning any details about yourself or your organisation other than FQDNs aren't mentioned in the certificate. Even if you write them into a CSR they're just discarded. This may be a blocker for some specialist applications.



              Let's Encrypt automation means you're constrained exactly by what the automation allows even if there is no other reasons why you can't have something. New types of public key, new X.509 extensions and other additions have to be explicitly enabled by Let's Encrypt on their own timeline, and of course you can't just offer to pay extra to get the features you want although donations are welcome.



              Nevertheless, for almost everyone, almost always, Let's Encrypt is a good first choice for putting certificates on your TLS servers in a fire-and-forget way. Starting with the assumption that you'll use Let's Encrypt is a sensible way to approach this decision.






              share|improve this answer
















              • 3




                I wonder if not supporting Nintendo WiiU is a big deal, considering how few websites that browser can display correctly.
                – Dmitry Grigoryev
                Aug 21 at 8:22










              • You mention downsides of the "proof of control automation", but in my experience, any DV certificate will be verified with very similar schemes anyway. For instance, here's the methods that Comodo offer, which include a very ACME-like HTTP-based approach. Protecting against rogue registrations would probably be best managed by monitoring Certificate Transparency logs.
                – IMSoP
                Aug 21 at 9:18










              • Watching a CT monitor is a good idea in this type of situation, and yes, there are only the Ten Blessed Methods (which are in fact currently I think 8 or 9 actual methods) so from one CA to another you're only going to see a different mix of methods and some variation in exactly how they work. However, the difference in which methods are offered, the potential to have contractual obligations to use your preferred method and even technical ideas like adding a CAA field to show which methods are permitted do vary by CA, and could mean it makes sense not to use Let's Encrypt.
                – tialaramex
                Aug 25 at 9:11










              • As a concrete example: Facebook has a contract with a big commercial CA. They now use CAA to specify that only that CA may issue certificates for their main domains like facebook.com and fb.com; the contract terms ensure Facebook's in-house technical security team has to clear every new certificate. The CA still has to use one of the Ten Blessed Methods but the contract requires them also to call Facebook Security.
                – tialaramex
                Aug 25 at 13:24












              up vote
              5
              down vote










              up vote
              5
              down vote









              There are two groups of downsides worth considering.



              1. Downsides to using the Let's Encrypt service



              Let's Encrypt requires that the exact name, or the (sub-)domain if you're requesting a wildcard, exists in the public Internet DNS. Even if you prove control over example.com, Let's Encrypt won't issue you certificates for some.other.name.in.example.com without seeing that in public DNS. The machines named needn't have public address records, they can be firewalled off, or even physically disconnected, but the public DNS name needs to exist.



              Let's Encrypt certificate lifetimes of 90 days mean you need to automate because ain't nobody got time for that. This is in fact the intent of the service - to herd people towards automating this essential work rather than perversely doing it manually while they automate away many harder tasks. But if you can't automate for any reason it's a negative - if you have tools, appliances or whatever that block automation consider any commercial SSL cert costs as part of the ongoing cost of those tools/ appliances/ whatever in cost planning. Contrariwise offset savings from not needing to buy commercial certs in pricing of new tools / appliances / etcetera that automate this (with Let's Encrypt or not)



              The Let's Encrypt proof of control automation may not suit your organisation's rules. For example if you have employees who're allowed to reconfigure Apache but shouldn't get SSL certs for company domain names then Let's Encrypt is a poor fit. Note that in this case just not using them is the Wrong Thing(TM) you should use CAA to explicitly disable Let's Encrypt for your domains.



              If Let's Encrypt policy refuses you, the only "court of appeal" is to ask in its public forums and hope one of their staff is able to offer a way forward. This may happen if, for example, your site has a DNS name their systems decide is "confusingly similar" to certain famous properties like big banks or Google. For sensible reasons the exact policies of each public CA in this regard are not open to public scrutiny so you may only realise you can't have a Let's Encrypt cert when you request it and get a "Policy forbids..." response.



              2. Downsides to a Let's Encrypt certificate itself



              Let's Encrypt certificates are trusted by major web browsers today via ISRG (the charity providing the Let's Encrypt service) but older systems trust Let's Encrypt via IdenTrust, a relatively obscure Certificate Authority which controls "DST Root CA X3". This gets the job done for most people, but it isn't the most broadly trusted root in the world. For example the abandoned Nintendo WiiU console had a web browser, obviously Nintendo won't be shipping updates for WiiU and so that browser is abandoned, it doesn't trust Let's Encrypt.



              Let's Encrypt only issues certificates for the Web PKI - servers with Internet names which use the SSL/TLS protocol. So that's the Web obviously, and your IMAP, SMTP, some types of VPN server, dozens of things, but not everything. In particular Let's Encrypt doesn't offer certificates at all for S/MIME (a way to encrypt email at rest, rather than just when it's in transit) nor for code signing or document signing. If you want a "one stop shop" for certificates, this may be enough reason not to use Let's Encrypt.



              Even in the Web PKI, Let's Encrypt offers only "DV" certificates, meaning any details about yourself or your organisation other than FQDNs aren't mentioned in the certificate. Even if you write them into a CSR they're just discarded. This may be a blocker for some specialist applications.



              Let's Encrypt automation means you're constrained exactly by what the automation allows even if there is no other reasons why you can't have something. New types of public key, new X.509 extensions and other additions have to be explicitly enabled by Let's Encrypt on their own timeline, and of course you can't just offer to pay extra to get the features you want although donations are welcome.



              Nevertheless, for almost everyone, almost always, Let's Encrypt is a good first choice for putting certificates on your TLS servers in a fire-and-forget way. Starting with the assumption that you'll use Let's Encrypt is a sensible way to approach this decision.






              share|improve this answer












              There are two groups of downsides worth considering.



              1. Downsides to using the Let's Encrypt service



              Let's Encrypt requires that the exact name, or the (sub-)domain if you're requesting a wildcard, exists in the public Internet DNS. Even if you prove control over example.com, Let's Encrypt won't issue you certificates for some.other.name.in.example.com without seeing that in public DNS. The machines named needn't have public address records, they can be firewalled off, or even physically disconnected, but the public DNS name needs to exist.



              Let's Encrypt certificate lifetimes of 90 days mean you need to automate because ain't nobody got time for that. This is in fact the intent of the service - to herd people towards automating this essential work rather than perversely doing it manually while they automate away many harder tasks. But if you can't automate for any reason it's a negative - if you have tools, appliances or whatever that block automation consider any commercial SSL cert costs as part of the ongoing cost of those tools/ appliances/ whatever in cost planning. Contrariwise offset savings from not needing to buy commercial certs in pricing of new tools / appliances / etcetera that automate this (with Let's Encrypt or not)



              The Let's Encrypt proof of control automation may not suit your organisation's rules. For example if you have employees who're allowed to reconfigure Apache but shouldn't get SSL certs for company domain names then Let's Encrypt is a poor fit. Note that in this case just not using them is the Wrong Thing(TM) you should use CAA to explicitly disable Let's Encrypt for your domains.



              If Let's Encrypt policy refuses you, the only "court of appeal" is to ask in its public forums and hope one of their staff is able to offer a way forward. This may happen if, for example, your site has a DNS name their systems decide is "confusingly similar" to certain famous properties like big banks or Google. For sensible reasons the exact policies of each public CA in this regard are not open to public scrutiny so you may only realise you can't have a Let's Encrypt cert when you request it and get a "Policy forbids..." response.



              2. Downsides to a Let's Encrypt certificate itself



              Let's Encrypt certificates are trusted by major web browsers today via ISRG (the charity providing the Let's Encrypt service) but older systems trust Let's Encrypt via IdenTrust, a relatively obscure Certificate Authority which controls "DST Root CA X3". This gets the job done for most people, but it isn't the most broadly trusted root in the world. For example the abandoned Nintendo WiiU console had a web browser, obviously Nintendo won't be shipping updates for WiiU and so that browser is abandoned, it doesn't trust Let's Encrypt.



              Let's Encrypt only issues certificates for the Web PKI - servers with Internet names which use the SSL/TLS protocol. So that's the Web obviously, and your IMAP, SMTP, some types of VPN server, dozens of things, but not everything. In particular Let's Encrypt doesn't offer certificates at all for S/MIME (a way to encrypt email at rest, rather than just when it's in transit) nor for code signing or document signing. If you want a "one stop shop" for certificates, this may be enough reason not to use Let's Encrypt.



              Even in the Web PKI, Let's Encrypt offers only "DV" certificates, meaning any details about yourself or your organisation other than FQDNs aren't mentioned in the certificate. Even if you write them into a CSR they're just discarded. This may be a blocker for some specialist applications.



              Let's Encrypt automation means you're constrained exactly by what the automation allows even if there is no other reasons why you can't have something. New types of public key, new X.509 extensions and other additions have to be explicitly enabled by Let's Encrypt on their own timeline, and of course you can't just offer to pay extra to get the features you want although donations are welcome.



              Nevertheless, for almost everyone, almost always, Let's Encrypt is a good first choice for putting certificates on your TLS servers in a fire-and-forget way. Starting with the assumption that you'll use Let's Encrypt is a sensible way to approach this decision.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Aug 20 at 13:58









              tialaramex

              65943




              65943







              • 3




                I wonder if not supporting Nintendo WiiU is a big deal, considering how few websites that browser can display correctly.
                – Dmitry Grigoryev
                Aug 21 at 8:22










              • You mention downsides of the "proof of control automation", but in my experience, any DV certificate will be verified with very similar schemes anyway. For instance, here's the methods that Comodo offer, which include a very ACME-like HTTP-based approach. Protecting against rogue registrations would probably be best managed by monitoring Certificate Transparency logs.
                – IMSoP
                Aug 21 at 9:18










              • Watching a CT monitor is a good idea in this type of situation, and yes, there are only the Ten Blessed Methods (which are in fact currently I think 8 or 9 actual methods) so from one CA to another you're only going to see a different mix of methods and some variation in exactly how they work. However, the difference in which methods are offered, the potential to have contractual obligations to use your preferred method and even technical ideas like adding a CAA field to show which methods are permitted do vary by CA, and could mean it makes sense not to use Let's Encrypt.
                – tialaramex
                Aug 25 at 9:11










              • As a concrete example: Facebook has a contract with a big commercial CA. They now use CAA to specify that only that CA may issue certificates for their main domains like facebook.com and fb.com; the contract terms ensure Facebook's in-house technical security team has to clear every new certificate. The CA still has to use one of the Ten Blessed Methods but the contract requires them also to call Facebook Security.
                – tialaramex
                Aug 25 at 13:24












              • 3




                I wonder if not supporting Nintendo WiiU is a big deal, considering how few websites that browser can display correctly.
                – Dmitry Grigoryev
                Aug 21 at 8:22










              • You mention downsides of the "proof of control automation", but in my experience, any DV certificate will be verified with very similar schemes anyway. For instance, here's the methods that Comodo offer, which include a very ACME-like HTTP-based approach. Protecting against rogue registrations would probably be best managed by monitoring Certificate Transparency logs.
                – IMSoP
                Aug 21 at 9:18










              • Watching a CT monitor is a good idea in this type of situation, and yes, there are only the Ten Blessed Methods (which are in fact currently I think 8 or 9 actual methods) so from one CA to another you're only going to see a different mix of methods and some variation in exactly how they work. However, the difference in which methods are offered, the potential to have contractual obligations to use your preferred method and even technical ideas like adding a CAA field to show which methods are permitted do vary by CA, and could mean it makes sense not to use Let's Encrypt.
                – tialaramex
                Aug 25 at 9:11










              • As a concrete example: Facebook has a contract with a big commercial CA. They now use CAA to specify that only that CA may issue certificates for their main domains like facebook.com and fb.com; the contract terms ensure Facebook's in-house technical security team has to clear every new certificate. The CA still has to use one of the Ten Blessed Methods but the contract requires them also to call Facebook Security.
                – tialaramex
                Aug 25 at 13:24







              3




              3




              I wonder if not supporting Nintendo WiiU is a big deal, considering how few websites that browser can display correctly.
              – Dmitry Grigoryev
              Aug 21 at 8:22




              I wonder if not supporting Nintendo WiiU is a big deal, considering how few websites that browser can display correctly.
              – Dmitry Grigoryev
              Aug 21 at 8:22












              You mention downsides of the "proof of control automation", but in my experience, any DV certificate will be verified with very similar schemes anyway. For instance, here's the methods that Comodo offer, which include a very ACME-like HTTP-based approach. Protecting against rogue registrations would probably be best managed by monitoring Certificate Transparency logs.
              – IMSoP
              Aug 21 at 9:18




              You mention downsides of the "proof of control automation", but in my experience, any DV certificate will be verified with very similar schemes anyway. For instance, here's the methods that Comodo offer, which include a very ACME-like HTTP-based approach. Protecting against rogue registrations would probably be best managed by monitoring Certificate Transparency logs.
              – IMSoP
              Aug 21 at 9:18












              Watching a CT monitor is a good idea in this type of situation, and yes, there are only the Ten Blessed Methods (which are in fact currently I think 8 or 9 actual methods) so from one CA to another you're only going to see a different mix of methods and some variation in exactly how they work. However, the difference in which methods are offered, the potential to have contractual obligations to use your preferred method and even technical ideas like adding a CAA field to show which methods are permitted do vary by CA, and could mean it makes sense not to use Let's Encrypt.
              – tialaramex
              Aug 25 at 9:11




              Watching a CT monitor is a good idea in this type of situation, and yes, there are only the Ten Blessed Methods (which are in fact currently I think 8 or 9 actual methods) so from one CA to another you're only going to see a different mix of methods and some variation in exactly how they work. However, the difference in which methods are offered, the potential to have contractual obligations to use your preferred method and even technical ideas like adding a CAA field to show which methods are permitted do vary by CA, and could mean it makes sense not to use Let's Encrypt.
              – tialaramex
              Aug 25 at 9:11












              As a concrete example: Facebook has a contract with a big commercial CA. They now use CAA to specify that only that CA may issue certificates for their main domains like facebook.com and fb.com; the contract terms ensure Facebook's in-house technical security team has to clear every new certificate. The CA still has to use one of the Ten Blessed Methods but the contract requires them also to call Facebook Security.
              – tialaramex
              Aug 25 at 13:24




              As a concrete example: Facebook has a contract with a big commercial CA. They now use CAA to specify that only that CA may issue certificates for their main domains like facebook.com and fb.com; the contract terms ensure Facebook's in-house technical security team has to clear every new certificate. The CA still has to use one of the Ten Blessed Methods but the contract requires them also to call Facebook Security.
              – tialaramex
              Aug 25 at 13:24










              up vote
              5
              down vote













              I'll add one that forced my employer partly away from Lets Encrypt: the API rate limiting. Due to the short lifetimes and lack of wildcard support, it is very easy to come close to the rate limits during normal automated operations (automatic renew, etc.). Trying to add a new subdomain can push you over the rate limit, and LE has no way to manually override the limit once hit. If you don't back up the old certificates (who would do so in an automated, cloud-type microservices environment like LE envisions?) all of the affected sites go offline as LE won't reissue the certificates.



              When we realized what happened, there was a moment of "oh $#!#" followed by an emergency commercial certificate requisition just to get the production sites back online. One with a more reasonable 1 year lifespan. Until LE implements proper wildcard support (and even then), we're going to be very wary of their offerings.



              Tl;dr: LE wildcard + API limits makes managing something more complex than "My Personal Homepage" unexpectedly challenging, and promotes poor security practice along the way.






              share|improve this answer


























                up vote
                5
                down vote













                I'll add one that forced my employer partly away from Lets Encrypt: the API rate limiting. Due to the short lifetimes and lack of wildcard support, it is very easy to come close to the rate limits during normal automated operations (automatic renew, etc.). Trying to add a new subdomain can push you over the rate limit, and LE has no way to manually override the limit once hit. If you don't back up the old certificates (who would do so in an automated, cloud-type microservices environment like LE envisions?) all of the affected sites go offline as LE won't reissue the certificates.



                When we realized what happened, there was a moment of "oh $#!#" followed by an emergency commercial certificate requisition just to get the production sites back online. One with a more reasonable 1 year lifespan. Until LE implements proper wildcard support (and even then), we're going to be very wary of their offerings.



                Tl;dr: LE wildcard + API limits makes managing something more complex than "My Personal Homepage" unexpectedly challenging, and promotes poor security practice along the way.






                share|improve this answer
























                  up vote
                  5
                  down vote










                  up vote
                  5
                  down vote









                  I'll add one that forced my employer partly away from Lets Encrypt: the API rate limiting. Due to the short lifetimes and lack of wildcard support, it is very easy to come close to the rate limits during normal automated operations (automatic renew, etc.). Trying to add a new subdomain can push you over the rate limit, and LE has no way to manually override the limit once hit. If you don't back up the old certificates (who would do so in an automated, cloud-type microservices environment like LE envisions?) all of the affected sites go offline as LE won't reissue the certificates.



                  When we realized what happened, there was a moment of "oh $#!#" followed by an emergency commercial certificate requisition just to get the production sites back online. One with a more reasonable 1 year lifespan. Until LE implements proper wildcard support (and even then), we're going to be very wary of their offerings.



                  Tl;dr: LE wildcard + API limits makes managing something more complex than "My Personal Homepage" unexpectedly challenging, and promotes poor security practice along the way.






                  share|improve this answer














                  I'll add one that forced my employer partly away from Lets Encrypt: the API rate limiting. Due to the short lifetimes and lack of wildcard support, it is very easy to come close to the rate limits during normal automated operations (automatic renew, etc.). Trying to add a new subdomain can push you over the rate limit, and LE has no way to manually override the limit once hit. If you don't back up the old certificates (who would do so in an automated, cloud-type microservices environment like LE envisions?) all of the affected sites go offline as LE won't reissue the certificates.



                  When we realized what happened, there was a moment of "oh $#!#" followed by an emergency commercial certificate requisition just to get the production sites back online. One with a more reasonable 1 year lifespan. Until LE implements proper wildcard support (and even then), we're going to be very wary of their offerings.



                  Tl;dr: LE wildcard + API limits makes managing something more complex than "My Personal Homepage" unexpectedly challenging, and promotes poor security practice along the way.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Aug 27 at 5:44

























                  answered Aug 26 at 11:07









                  madscientist159

                  1515




                  1515




















                      up vote
                      -1
                      down vote













                      Yes.



                      Downside of using a free or Let's encrypt SSL Certificate-



                      Compatibility Issue – Let’s encrypt SSL Certificate not compatible with all platforms. See this link to know the list of incompatible platforms –



                      Less validity – A let’s encrypt SSL Certificate comes with a limited validity as 90 days. You have to renew your SSL Certificate in every 90 days. Where as a paid SSL like Comodo comes with long validity like 2 years.



                      No business validation – A free SSL Certificate require only domain validation. No business or organization validation to ensure users for a legal business entity.



                      Suitable for small business or blog sites – As I added in last point, A free or let’s encrypt SSL Certificate can be availed through domain ownership verification, its not appropriate for a business or ecommerce website where trust and security is a major factor for business.



                      No green address bar – You can’t have a green address bar with a free SSL Certificate. An extended validation SSL certificate is the only way to display your business name with green address bar on the browser.



                      No Support – If you stuck between the way with Let’s encrypt, you can get online chat or call support. You can contact through forums only to get rid of from the issue.



                      Additional security features – A free SSL Certificate does not offer any extra feature like free malware scan, site seal etc.



                      No warranty – A Free or Let’s encrypt SSL Certificate does not offer any warranty amount whereas a paid SSL Certificate offers warranty from $10,000 to $1,750,000.



                      According to a news, 14,766 Let's Encrypt SSL Certificates Issued to PayPal Phishing Sites as it requires only domain validation



                      So, as per my recommendation, paying for an SSL Certificate is really worth.






                      share|improve this answer


















                      • 5




                        (1) LE is only incompatible with older systems. (2) Validity period is a non-issue due to automation. (3) Validation is same as any other DV cert. (4) LE cert is suitable for any type of org. (5) Green bar is for EV certs only (and will go away in near future). (6) I don't know of any cert vendor that does a malware scan and what is a site seal supposed to contribute towards?. (7) What warrant would a cert need to offter? (8) Shady paid CAs sell certs for phishing sites as well (9) The link you refer to discusses Self-Signed certificates, that's unrelated
                        – GroundZero
                        Aug 23 at 12:14







                      • 1




                        When the "incompatible systems" list is stuff like Android versions before 2.3.6, Nintendo 3DS and Windows XP earlier than SP3, it's not a concern for 99.999% of people needing SSL certs. Also, the "Why you shouldn't ..." link at the bottom of your post is ONLY about self-signed SSL, it doesn't say anything about Let's Encrypt certificates, you usage of that link is factually incorrect.
                        – semi-extrinsic
                        Aug 24 at 7:44















                      up vote
                      -1
                      down vote













                      Yes.



                      Downside of using a free or Let's encrypt SSL Certificate-



                      Compatibility Issue – Let’s encrypt SSL Certificate not compatible with all platforms. See this link to know the list of incompatible platforms –



                      Less validity – A let’s encrypt SSL Certificate comes with a limited validity as 90 days. You have to renew your SSL Certificate in every 90 days. Where as a paid SSL like Comodo comes with long validity like 2 years.



                      No business validation – A free SSL Certificate require only domain validation. No business or organization validation to ensure users for a legal business entity.



                      Suitable for small business or blog sites – As I added in last point, A free or let’s encrypt SSL Certificate can be availed through domain ownership verification, its not appropriate for a business or ecommerce website where trust and security is a major factor for business.



                      No green address bar – You can’t have a green address bar with a free SSL Certificate. An extended validation SSL certificate is the only way to display your business name with green address bar on the browser.



                      No Support – If you stuck between the way with Let’s encrypt, you can get online chat or call support. You can contact through forums only to get rid of from the issue.



                      Additional security features – A free SSL Certificate does not offer any extra feature like free malware scan, site seal etc.



                      No warranty – A Free or Let’s encrypt SSL Certificate does not offer any warranty amount whereas a paid SSL Certificate offers warranty from $10,000 to $1,750,000.



                      According to a news, 14,766 Let's Encrypt SSL Certificates Issued to PayPal Phishing Sites as it requires only domain validation



                      So, as per my recommendation, paying for an SSL Certificate is really worth.






                      share|improve this answer


















                      • 5




                        (1) LE is only incompatible with older systems. (2) Validity period is a non-issue due to automation. (3) Validation is same as any other DV cert. (4) LE cert is suitable for any type of org. (5) Green bar is for EV certs only (and will go away in near future). (6) I don't know of any cert vendor that does a malware scan and what is a site seal supposed to contribute towards?. (7) What warrant would a cert need to offter? (8) Shady paid CAs sell certs for phishing sites as well (9) The link you refer to discusses Self-Signed certificates, that's unrelated
                        – GroundZero
                        Aug 23 at 12:14







                      • 1




                        When the "incompatible systems" list is stuff like Android versions before 2.3.6, Nintendo 3DS and Windows XP earlier than SP3, it's not a concern for 99.999% of people needing SSL certs. Also, the "Why you shouldn't ..." link at the bottom of your post is ONLY about self-signed SSL, it doesn't say anything about Let's Encrypt certificates, you usage of that link is factually incorrect.
                        – semi-extrinsic
                        Aug 24 at 7:44













                      up vote
                      -1
                      down vote










                      up vote
                      -1
                      down vote









                      Yes.



                      Downside of using a free or Let's encrypt SSL Certificate-



                      Compatibility Issue – Let’s encrypt SSL Certificate not compatible with all platforms. See this link to know the list of incompatible platforms –



                      Less validity – A let’s encrypt SSL Certificate comes with a limited validity as 90 days. You have to renew your SSL Certificate in every 90 days. Where as a paid SSL like Comodo comes with long validity like 2 years.



                      No business validation – A free SSL Certificate require only domain validation. No business or organization validation to ensure users for a legal business entity.



                      Suitable for small business or blog sites – As I added in last point, A free or let’s encrypt SSL Certificate can be availed through domain ownership verification, its not appropriate for a business or ecommerce website where trust and security is a major factor for business.



                      No green address bar – You can’t have a green address bar with a free SSL Certificate. An extended validation SSL certificate is the only way to display your business name with green address bar on the browser.



                      No Support – If you stuck between the way with Let’s encrypt, you can get online chat or call support. You can contact through forums only to get rid of from the issue.



                      Additional security features – A free SSL Certificate does not offer any extra feature like free malware scan, site seal etc.



                      No warranty – A Free or Let’s encrypt SSL Certificate does not offer any warranty amount whereas a paid SSL Certificate offers warranty from $10,000 to $1,750,000.



                      According to a news, 14,766 Let's Encrypt SSL Certificates Issued to PayPal Phishing Sites as it requires only domain validation



                      So, as per my recommendation, paying for an SSL Certificate is really worth.






                      share|improve this answer














                      Yes.



                      Downside of using a free or Let's encrypt SSL Certificate-



                      Compatibility Issue – Let’s encrypt SSL Certificate not compatible with all platforms. See this link to know the list of incompatible platforms –



                      Less validity – A let’s encrypt SSL Certificate comes with a limited validity as 90 days. You have to renew your SSL Certificate in every 90 days. Where as a paid SSL like Comodo comes with long validity like 2 years.



                      No business validation – A free SSL Certificate require only domain validation. No business or organization validation to ensure users for a legal business entity.



                      Suitable for small business or blog sites – As I added in last point, A free or let’s encrypt SSL Certificate can be availed through domain ownership verification, its not appropriate for a business or ecommerce website where trust and security is a major factor for business.



                      No green address bar – You can’t have a green address bar with a free SSL Certificate. An extended validation SSL certificate is the only way to display your business name with green address bar on the browser.



                      No Support – If you stuck between the way with Let’s encrypt, you can get online chat or call support. You can contact through forums only to get rid of from the issue.



                      Additional security features – A free SSL Certificate does not offer any extra feature like free malware scan, site seal etc.



                      No warranty – A Free or Let’s encrypt SSL Certificate does not offer any warranty amount whereas a paid SSL Certificate offers warranty from $10,000 to $1,750,000.



                      According to a news, 14,766 Let's Encrypt SSL Certificates Issued to PayPal Phishing Sites as it requires only domain validation



                      So, as per my recommendation, paying for an SSL Certificate is really worth.







                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Aug 26 at 7:21









                      J F

                      1033




                      1033










                      answered Aug 23 at 9:58









                      Sanjay B.

                      92




                      92







                      • 5




                        (1) LE is only incompatible with older systems. (2) Validity period is a non-issue due to automation. (3) Validation is same as any other DV cert. (4) LE cert is suitable for any type of org. (5) Green bar is for EV certs only (and will go away in near future). (6) I don't know of any cert vendor that does a malware scan and what is a site seal supposed to contribute towards?. (7) What warrant would a cert need to offter? (8) Shady paid CAs sell certs for phishing sites as well (9) The link you refer to discusses Self-Signed certificates, that's unrelated
                        – GroundZero
                        Aug 23 at 12:14







                      • 1




                        When the "incompatible systems" list is stuff like Android versions before 2.3.6, Nintendo 3DS and Windows XP earlier than SP3, it's not a concern for 99.999% of people needing SSL certs. Also, the "Why you shouldn't ..." link at the bottom of your post is ONLY about self-signed SSL, it doesn't say anything about Let's Encrypt certificates, you usage of that link is factually incorrect.
                        – semi-extrinsic
                        Aug 24 at 7:44













                      • 5




                        (1) LE is only incompatible with older systems. (2) Validity period is a non-issue due to automation. (3) Validation is same as any other DV cert. (4) LE cert is suitable for any type of org. (5) Green bar is for EV certs only (and will go away in near future). (6) I don't know of any cert vendor that does a malware scan and what is a site seal supposed to contribute towards?. (7) What warrant would a cert need to offter? (8) Shady paid CAs sell certs for phishing sites as well (9) The link you refer to discusses Self-Signed certificates, that's unrelated
                        – GroundZero
                        Aug 23 at 12:14







                      • 1




                        When the "incompatible systems" list is stuff like Android versions before 2.3.6, Nintendo 3DS and Windows XP earlier than SP3, it's not a concern for 99.999% of people needing SSL certs. Also, the "Why you shouldn't ..." link at the bottom of your post is ONLY about self-signed SSL, it doesn't say anything about Let's Encrypt certificates, you usage of that link is factually incorrect.
                        – semi-extrinsic
                        Aug 24 at 7:44








                      5




                      5




                      (1) LE is only incompatible with older systems. (2) Validity period is a non-issue due to automation. (3) Validation is same as any other DV cert. (4) LE cert is suitable for any type of org. (5) Green bar is for EV certs only (and will go away in near future). (6) I don't know of any cert vendor that does a malware scan and what is a site seal supposed to contribute towards?. (7) What warrant would a cert need to offter? (8) Shady paid CAs sell certs for phishing sites as well (9) The link you refer to discusses Self-Signed certificates, that's unrelated
                      – GroundZero
                      Aug 23 at 12:14





                      (1) LE is only incompatible with older systems. (2) Validity period is a non-issue due to automation. (3) Validation is same as any other DV cert. (4) LE cert is suitable for any type of org. (5) Green bar is for EV certs only (and will go away in near future). (6) I don't know of any cert vendor that does a malware scan and what is a site seal supposed to contribute towards?. (7) What warrant would a cert need to offter? (8) Shady paid CAs sell certs for phishing sites as well (9) The link you refer to discusses Self-Signed certificates, that's unrelated
                      – GroundZero
                      Aug 23 at 12:14





                      1




                      1




                      When the "incompatible systems" list is stuff like Android versions before 2.3.6, Nintendo 3DS and Windows XP earlier than SP3, it's not a concern for 99.999% of people needing SSL certs. Also, the "Why you shouldn't ..." link at the bottom of your post is ONLY about self-signed SSL, it doesn't say anything about Let's Encrypt certificates, you usage of that link is factually incorrect.
                      – semi-extrinsic
                      Aug 24 at 7:44





                      When the "incompatible systems" list is stuff like Android versions before 2.3.6, Nintendo 3DS and Windows XP earlier than SP3, it's not a concern for 99.999% of people needing SSL certs. Also, the "Why you shouldn't ..." link at the bottom of your post is ONLY about self-signed SSL, it doesn't say anything about Let's Encrypt certificates, you usage of that link is factually incorrect.
                      – semi-extrinsic
                      Aug 24 at 7:44











                      up vote
                      -6
                      down vote













                      After some research I found out that Let's Encrypt certificates are less compatible with browsers than paid certificates. (Sources: Let's Encrypt vs. Comodo PositiveSSL)






                      share|improve this answer




















                      • Second link is broken.
                        – iamnotmaynard
                        Aug 20 at 18:40






                      • 5




                        what do you care about browsers and platforms that are a decade old not supporting something?
                        – warren
                        Aug 20 at 20:21






                      • 1




                        @warren like it or not, but a lot of devices and computers in especially large organisations still run Windows XP, or operating systems of similar age, and may require (strictly controlled, lots of firewalls and proxies) internet access to communicate with each other. Think hand held terminals talking or kiosks. Heck, I'm currently writing the serverside of a system that talks to 15 year old devices over https/ssl. While most customers have upgraded to new devices, some have not.
                        – jwenting
                        Aug 27 at 5:06














                      up vote
                      -6
                      down vote













                      After some research I found out that Let's Encrypt certificates are less compatible with browsers than paid certificates. (Sources: Let's Encrypt vs. Comodo PositiveSSL)






                      share|improve this answer




















                      • Second link is broken.
                        – iamnotmaynard
                        Aug 20 at 18:40






                      • 5




                        what do you care about browsers and platforms that are a decade old not supporting something?
                        – warren
                        Aug 20 at 20:21






                      • 1




                        @warren like it or not, but a lot of devices and computers in especially large organisations still run Windows XP, or operating systems of similar age, and may require (strictly controlled, lots of firewalls and proxies) internet access to communicate with each other. Think hand held terminals talking or kiosks. Heck, I'm currently writing the serverside of a system that talks to 15 year old devices over https/ssl. While most customers have upgraded to new devices, some have not.
                        – jwenting
                        Aug 27 at 5:06












                      up vote
                      -6
                      down vote










                      up vote
                      -6
                      down vote









                      After some research I found out that Let's Encrypt certificates are less compatible with browsers than paid certificates. (Sources: Let's Encrypt vs. Comodo PositiveSSL)






                      share|improve this answer












                      After some research I found out that Let's Encrypt certificates are less compatible with browsers than paid certificates. (Sources: Let's Encrypt vs. Comodo PositiveSSL)







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Aug 20 at 16:11









                      Sr. Schneider

                      1334




                      1334











                      • Second link is broken.
                        – iamnotmaynard
                        Aug 20 at 18:40






                      • 5




                        what do you care about browsers and platforms that are a decade old not supporting something?
                        – warren
                        Aug 20 at 20:21






                      • 1




                        @warren like it or not, but a lot of devices and computers in especially large organisations still run Windows XP, or operating systems of similar age, and may require (strictly controlled, lots of firewalls and proxies) internet access to communicate with each other. Think hand held terminals talking or kiosks. Heck, I'm currently writing the serverside of a system that talks to 15 year old devices over https/ssl. While most customers have upgraded to new devices, some have not.
                        – jwenting
                        Aug 27 at 5:06
















                      • Second link is broken.
                        – iamnotmaynard
                        Aug 20 at 18:40






                      • 5




                        what do you care about browsers and platforms that are a decade old not supporting something?
                        – warren
                        Aug 20 at 20:21






                      • 1




                        @warren like it or not, but a lot of devices and computers in especially large organisations still run Windows XP, or operating systems of similar age, and may require (strictly controlled, lots of firewalls and proxies) internet access to communicate with each other. Think hand held terminals talking or kiosks. Heck, I'm currently writing the serverside of a system that talks to 15 year old devices over https/ssl. While most customers have upgraded to new devices, some have not.
                        – jwenting
                        Aug 27 at 5:06















                      Second link is broken.
                      – iamnotmaynard
                      Aug 20 at 18:40




                      Second link is broken.
                      – iamnotmaynard
                      Aug 20 at 18:40




                      5




                      5




                      what do you care about browsers and platforms that are a decade old not supporting something?
                      – warren
                      Aug 20 at 20:21




                      what do you care about browsers and platforms that are a decade old not supporting something?
                      – warren
                      Aug 20 at 20:21




                      1




                      1




                      @warren like it or not, but a lot of devices and computers in especially large organisations still run Windows XP, or operating systems of similar age, and may require (strictly controlled, lots of firewalls and proxies) internet access to communicate with each other. Think hand held terminals talking or kiosks. Heck, I'm currently writing the serverside of a system that talks to 15 year old devices over https/ssl. While most customers have upgraded to new devices, some have not.
                      – jwenting
                      Aug 27 at 5:06




                      @warren like it or not, but a lot of devices and computers in especially large organisations still run Windows XP, or operating systems of similar age, and may require (strictly controlled, lots of firewalls and proxies) internet access to communicate with each other. Think hand held terminals talking or kiosks. Heck, I'm currently writing the serverside of a system that talks to 15 year old devices over https/ssl. While most customers have upgraded to new devices, some have not.
                      – jwenting
                      Aug 27 at 5:06

















                       

                      draft saved


                      draft discarded















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f926974%2fis-there-a-reason-to-use-an-ssl-certificate-other-than-lets-encrypts-free-ssl%23new-answer', 'question_page');

                      );

                      Post as a guest













































































                      Comments

                      Popular posts from this blog

                      What does second last employer means? [closed]

                      Installing NextGIS Connect into QGIS 3?

                      One-line joke