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.
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.