Let's Encrypt Enterprise Solution

Hi Folks,

I know this topic has been covered several times before, but I’m trying to understand if Let’s Encrypt is an “enterprise” savvy solution that can be used for a large enterprise managing thousands of certificates. This would be in contrast to using either a private CA or another public CA (we currently do business with e.g. Globalsign, Digicert, also supporting ACME).

Considering the rate limiting and bandwidth constraints, and not guarantee of service from an availability perspective (as well as customer support), Im leaning towards using a commercial grade public CA, but who doesn’t like free certificates? I do understand there is a form that companies can use to increase the rate limits, but how successful have others been? I’d like to understand what others are think in this capacity. I’ve listed the pros/cons below as a starting point.

Thanks,
-Forbin

The advantages and disadvantages are as follows:

Advantages:
* Certificates are free.
* Supports ACME.
* Browser trust is installed in every major browser.

Disadvantages:
* Rate limiting and max cap associated with new certificate issuance as noted here.
* Max issuance of new certificates are potentially capped at 50 new certificates per week, which will negatively impact deployment.
* No guaranteed service level agreement in the event the service was to become unavailable.
* Any changes to the stack, including required certificates revocation as noted here, will impact operational performance of the systems and service availability.
* Certificates issued by Let’s Encrypt have a validity period less than 90 days. With that said, certain systems require a controlled, scheduled time slot for when this occurs. If this can’t be done within 90 days on the system in question, then Let’s Encrypt is not a viable solution for these systems.
* No strong, paid customer support.

2 Likes

You can get an exception to this, for what it’s worth.

I’m not entirely sure but I think the BRs do require a certain level of uptime, but maybe not as strong guarantees as a SLA.

There is no paid customer support, or any real support, period – there is the community forums which they are actively engaged in, but that’s about it.

I don’t believe Let’s Encrypt really targets enterprise use cases — the interest seems to be more in the long tail of small sites that didn’t have HTTPS before.

This, too, is a significant reason why Let’s Encrypt is not the end-all of the CA industry. While all other CAs should still adopt ACME, there’s plenty of space for other, commercial CAs to offer enterprise features.

FWIW, requiring long cert lifetimes is kind of anti-pattern in the field, and all new deployments, policies, and infrastructure really should support fully automated renewal (or management) of certificates as much as possible. (Not an LE-specific thing.)

4 Likes

I agree with the analysis from both @colforbin5 and @mholt and I might add this perspective:

  • Let’s Encrypt is run in a serious way by people who are proactively trying to keep up with technological developments and best practices. The people behind the CA spend a lot of time thinking about how to make sure things work reliably and also follow the industry rules, and I think are respected by other participants in the industry for their sophistication and meticulousness. But as a risk management matter, Let’s Encrypt isn’t able to accept your money to insure against specific kinds of outages or other kinds of risk. If you need to pay someone to manage those risks, it will probably have to be a paid CA that can negotiate an individual contract with you.

  • Let’s Encrypt is most optimized for use by public-facing web servers where the administrator can broadly control and upgrade the software environment, for example perhaps by switching to easy-to-use modern web server software like @mholt’s. :slight_smile: If you have systems that don’t have a very flexible software environment because they are embedded, non-Internet-facing, highly regulated, highly mission-critical, or whatever, Let’s Encrypt might not be the best solution for those machines. (It’s definitely not the best solution if the machines don’t need to participate in the public web PKI—if the certificates aren’t going to be consumed by the general public or by organizations with no prior relationship with your organization.) The paid CAs have the advantage that they can customize your certificate issuance, and not require frequently-repeated technical proof of control of specific subdomains; they can in some cases effectively allow you to operate your own RA and VA service which is constrained to requesting certificates only within your own domain. Let’s Encrypt won’t do that in exactly that form.

  • In some environments you could nonetheless make your own “proxy” that handles all of the certificate requests and issuance for you, typically using the DNS authentication method. (I guess you could also think of this as a form of middleware.) This system could handle all communications with Let’s Encrypt, all authorizations and key material, etc. Then the new certificates and keys can be transferred over to individual machines where they’re needed on your own schedule, perhaps with some delay. That needn’t require making significant software or configuration changes to the machines where the certificates are going to be deployed. The main downside to centralizing issuance this way is that this key-management machine is a central point of failure within your infrastructure, and might also centralize security risks because the security consequences of compromising that machine would be larger. But I think it’s quite practical in principle.

4 Likes

Arguably this applies to all public CAs, not just Let’s Encrypt.

This rate limit is per registered domain. If all goes well, that means a registered domain can have 50 certificates each week, with each certificate covering 1000 fully qualified domain names under than domain (i.e. the purchased domain or any of it’s subdomains can appear on a max of 50 certs).

In a worst-case scenario, you will only be able to generate 5 certificates for the domain in a given week.

If you have to service large amounts, you can purchase new domains for systems, for as little as $8. That cost is considerably cheaper than most certificate vendors. LetsEncrypt is used by major hosting providers and content delivery networks that handle tens/hundreds of thousands of domains.

There is a way to apply for exemptions to this limit, but a lot of people who worry about it really do not need to.

Please show me a certificate vendor that offers this, along with customer testimonials. Most vendors in this industry are resellers and/or notorious for bad customer support.

But yes, there is absolutely no customer or official support.

Every consumer and enterprise contract I have been involved with - even those above $1MM with “Enterprise” industry leaders - has handled SLA violations with refunds or credits against the current billing cycle. Sometimes you get a human on the phone to yell at too, but they can’t do anything.
Usually a violation triggers something like a 10minute block of downtime might be reduction in the bill of for 1 hour to 1 day. If a vendor were to go down and you were able to invoke the SLA, you would - at best - end up paying nothing, which is what LetsEncrypt charges. SLAs are not an insurance policy and after years of dealing with Sales Teams highlighting them, I haven’t seen one that isn’t meaningless garbage.

This equally applies to paid CAs. There have been a handful of incidents in the past few years where commercial vendors had similar issues that lead to revocations, browser blacklists, and even corporate shutdowns.

90 days is quickly becoming an industry standard, and is endorsed by major browser/operating-system vendors. The max lifetime was recently cut to 825 days, and major browser vendors have been calling for a max of 397 days; it is likely to get even smaller within the next 3 years.

While there is still plenty of time to run systems that require longer certificates, at this point relying on them is just accumulating technical debt.

2 Likes

I tend to agree. Unless you engage in legal action against the SLA violator, the SLA is just BS paperware.

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