We could very easily make the cert lifetimes one year, or anything else. We chose 90 days for the reasons outlined here:

https://letsencrypt.org/2015/11/09/why-90-days.html

Additionally, long cert lifetimes are dangerous because revocation is ineffective and things like heartbleed happen.

I appreciate what Let's Encrypt is doing, and have even donated, but internally at our org (as a DevOps), I cannot sell certs that expire every 90 days; $300/year for a wildcard cert is a small price to pay for 1 year expirations.

I think LE's 90-day expiration reason #2 is really the key: encouraging automation. So what it really is investing effort once and working for arbitrarily period of time. If the TLS certificate renewal process cannot be automated but must be manually done for some reason, that perhaps LE certificates are really not what you are looking for.

The chances of automation failing is higher than the chance our SSL certs will need revocation.

With that said, still a big supporter of Let's Encrypt for folks who can tolerate the constraints.

Automation failing once shouldn't be a catastrophe; you could renew after 30 days and issue a pager alert if it fails. Then you'd have 60 days to figure out what went wrong, manually update it, and fix the issue with the automation.

At fully loaded engineer costs, if someone takes more than an hour or two to investigate, its already more expensive than a wildcard cert.

The few times I've had Let's Encrypt's automation fail it's taken a few minutes, not hours, to investigate and fix. Anecdotal, sure, but I don't see it taking hours to fix

Anecdotal, but managing thousands of VMs, hundreds of ELBs, service discovery, several CI pipelines, and so on, its never a few minutes unless its a blatant misconfigured flag.

It sounds as if your organization would be a customer for a different service than the one that LE provides.

If you're issuing lots of internal certificates, you may be interested in using Anchor [1] instead. It's designed for that use case and with own service you don't need to worry about rate limits, name limits of similar issues.

While it's designed to cycle all your certificates every day, you can still configure it for weeks/months. It's also based on credentials rather than domain verification (shameless plug, I'm Anchor developer)

[1] https://github.com/openstack/anchor

Apples/oranges comparison.

You're comparing engineer time to the wildcard cert transaction price. You're neglecting to include the time for dealing with the wildcard cert (including manually remembering to renew that).

With process automation, you (or better: a collaboratively supported tool) gets progressively better at nailing renewals.

JoshTriplett's "renew every 30 days, 60 days to fix the problem" approach strikes me as inspired.

How much does it cost to manually renew your certificate every year? How much does it cost if you forget to manually renew it, or make a mistake with one of the manual steps?

This is only true if all of your engineers are operating at 100% capacity all the time. In my experience that's generally not true (and if it was they'd probably burn out pretty fast). Unless you're staffed entirely by contractors and pay by the hour?

If all you care about is money, sure.

> The chances of automation failing is higher than the chance our SSL certs will need revocation.

Given a 90-day duration, set up automated renewal for every 30 days, and if that renewal fails, you'll have 60 days to deal with it.

Or just do what Let's Encrypt suggests and have a cron job that runs certbot-auto's renewal command twice a day, every day? It doesn't actually renew until nearing the end of the 3 month cycle, but by having two attempts per day it will make it far more likely to go through if the network is down or something otherwise prevents it from renewing one of the times. They, of course, also will email you repeatedly as you near the end if you haven't yet renewed.

Sounds like a great strategy!

If critical automation failure is treated as a serious bug in LE, then it should really just be a matter of time before 99.9% of them are fixed and LE can enter a state of maintenance rather than development. LE (the client) don't need to expand until it can read mail.

Yeah, I hear that frequently and I get it. The important thing, really, is that you have a cert and that you deploy HTTPS. If you can afford it and it's what you need to do to deploy HTTPS, then whether or not you get your cert from Let's Encrypt is not so important.

There are some good reasons behind the automation practices we encourage though, and if you're doing that stuff then the lifetime doesn't matter much. Worth considering regardless of who your CA is.

Thanks for your support!

Same here. But you and I (or, more specifically, our firms) are not really the market for LE, at least at this point.

I fully expect over time for others to compete with LE, using free certs as a loss leader for other services. I also expect the NSIs and Symantecs to continue making money catering to businesses for multiple reasons, some possibly reasonable, some stupid.

Of course, LE could make themselves more attractive to firms like mine, given the automation angle - I've had cert vendors try to offer tools to do this, but they have all been terrible, broken, security nightmares, or all three. Get this part bullet proof and I can imagine companies switching right after someone forgets to renew...

I'd absolutely love to have wildcard certificates as well. I think Let's Encrypt has plans to offer them, as soon as they finish producing a new version of the ACME standard that supports authorizing them.

It looks like that should be happening soonish if I read the Github issues correctly.

https://github.com/ietf-wg-acme/acme/pull/124 is "Enable the server to specify requirements for issuance" which seems to include wildcard cert support, but was only merged into master about 5 weeks ago. I presume further discussion is ongoing.

Personally I'm glad that they're taking the time to get this right. They could have probably supported wildcard certs a while ago, but it would have been through some mangled and limited method. The method they're now looking at seems to be much more future proof.

Of course, I may be completely wrong about this, but the above is what I gather from following the issues.

> What I find more inconvenient than any of those limits (as a non-power user) is the 3 month lifetime of certs. I am a windows user. Running a VM once a month just to renew my 3 certs is a huge headache. Will it really be that much of a burden to have like a year?

You shouldn't do anything by hand to renew certificates. The short certificate lifetime encourages you to automate the process.

Clients exist for Windows, and web servers exist for Windows that include native support for ACME and Let's Encrypt.

I experimented with LetsEncrypt a few months ago, and found the process to be VERY manual. This was on a bog-standard Debian install running common web software (lighttpd) with a few vhosts. Certbot does not seem to support lighttpd, so it's: download this third party script, run this, copy that, run this, cat these files together, restart the web server process, etc. Sure, that can all be cobbled together with your own mega-script, but at that point, you start just looking for another provider (which OP did). If I were not as comfortable with the command line as I am, I'd have found the initial setup to be daunting, let alone automating it.

Even better than certbot supporting it would be if lighttpd supported ACME natively. You might file a feature request with lighttpd requesting native ACME/LE support.

Those aren't really an option for me, I use shared hosting without command line access. I realize this is an issue specific to my case but I know many other people that have their own small sites running on similar hosting as mine.

If continuing to use your current hosting provider is important to you, I suggest you ask them to integrate Let's Encrypt on their end. (That could include just letting you get Let's Encrypt certs through cPanel; it doesn't necessarily have to mean a lot of coding for them.) We've been talking to a number of providers of various shapes and sizes who are doing this or planning to do it. It's the best option for hosting environments where the customer doesn't have administrative access.

Your web hoster should integrate a way to automatically get certificates. Many already do. If they don't offer that you may want to consider using another webhoster.

If you have it scripted in a vm, I think that you should set up a vps that turns on every month and runs it.

Ah. I think the trouble is that Lets Encrypt was created and promoted by tech people like me who like having their own VPS with root access.

What certificate issuance through a public API (ACME) allows you to do is have your server software automatically request and deploy a certificate for your hostnames (like Caddy[1]). That's probably the simplest process you can get in this space, even compared to things like certbot (which does similar things, but is not a first-party component of the web servers it supports). There's no need for any kind of UI, the best case is: give your server software the URL to an ACME server (Let's Encrypt), your hostnames and (optionally) your email address, and it'll take care of things for you. It's a bit like DHCP leases - you're probably not managing those manually either, and there's certainly no need for a fancy UI. It just works behind the scenes.

The problem is, if Let's Encrypt were to just operate like any other CA and provide certificates with lifetimes of one year (or more), there wouldn't be much of an incentive to go through any of that trouble in the first place, and users would just continue to manually renew things once every year (or not). SSL configuration would still be a PITA. With short-lived certificates, there's a big incentive for server software, control panels, shared hosting providers, etc. to provide first-party support for ACME. Clients will keep nagging them to do so or move on to competitors. This strategy seems to be working out just fine, as we're seeing many control panels (like cPanel), hosting providers (OVH) and other software (Synology DSM) add ACME support. I would not be surprised to see ACME support for all mainstream server software (think: apache, nginx, postfix, IIS, etc.) similar to Caddy within the next year or so.

What I'm getting at is that while the "forced automation" bit is currently a bit of a drag for some users, this strategy is the most likely to lead to a 100% (transport-layer) encrypted web eventually.

[1]: https://caddyserver.com/

Our you can save all the trouble and just continue staying on http.

My point was that it incentivizes developers of server software to remove the "trouble" from your equation.

Of course (and to put it bluntly), you're free continue to put your users at risk, just like browser vendors are free to gradually break sites served via HTTP somewhere down the line.

If you don't care about security and don't mind missing out on HTTPS-Everywhere users.

Regarding your experience getting and managing certificates, I'm sorry to hear that you're having a difficult time.

Our goal is to encrypt the entire Web, and that means working with an almost innumerable combination of operating systems, server software, hosting providers, management interfaces, permissions, deployment strategies... Most people have a very positive experience using Let's Encrypt but it's difficult to ensure that everyone does.

It's not possible for us to build the tools necessary for every situation (financially or otherwise). Our strategy, which has been working pretty well so far, is to focus on running a secure, stable, and well-documented CA API and let our community decide what clients need to be built (and build them). This has resulted in a range of client software suitable for different situations and preferences:

https://letsencrypt.org/docs/client-options/

This includes web-based interfaces for getting certificates from Let's Encrypt (see the "Browser" section of the client options document). Hopefully one of these will work well for you.

I was on that very page a few weeks ago. I used ZeroSSL to generate my last cert. It works great! And I understand your strategy, providing an API and letting the community work over is the absolute best you can do with the resources you have. My frustration was as a newbie fiddling with command line tools. Being completely lost. I had to read up for two straight days. Then give up for a few months. Return back, read up for two days again, discover ZeroSSL and finally have my cert. Barrier to entry was very high. Now that I'm in, it's a lot better.

"..via cpanel"

Then you need to look at this. CPanel just released their awesome plugin for letsencrypt. No need to do any command line stuff.

https://features.cpanel.net/topic/provide-support-for-lets-e...

>Running a VM once a month just to renew my 3 certs is a huge headache.

Not overly familiar with Windows administration (or the tools available to work with SSL/TLS stuff), but you can use Docker to automate basically all of that; IIRC it's supported on Windows now.

>Not to mention the whole process is so very incredibly fugly.

On the contrary, the process is pretty simple, even if you're going fully manual!

1. Generate a CSR for the domains you want to register

2. Place a proof of ownership somewhere on your server in a way that Let's Encrypt can verify it's there

3. Contact LE's API and tell it what domains you want to register, what you want to get signed, and where your proof is

4. Get a signed cert back. The rest is just server configuration to point to the cert.

If you use something like `certbot-auto`, it's basically a GUI step-through process.

I'm pretty sure there are letsencrypt windows clients. Which you can run every week to make sure they auto-renew. And you could do this as well by running the VM regularly, automatically.

The point of letsencrypt is to have auto-renewed certificates. It's intended to force you to automate the process.

I can't run those scripts. My site runs on shared hosting, I don't have command line access. All I have is a file manager for my 'htdocs' and standard cpanel stuff.

So... this is less an issue with Let's Encrypt and more an issue with restrictions imposed by cPanel and your choice of host.

In fact isn't shared hosting the most common type of hosting? Any larger sites can afford paid certs anyways so letsencrypt is especially suited for smaller sites like mine, that can't afford the cert but also don't have the luxury of a dedicated machine/vps.

You're right that it's a pain for users trying to do it themselves, but some shared hosters already offer integrated LE, like DreamHost[1]; hopefully most will, if users push for it.

[1] https://www.dreamhost.com/hosting/ssl-tls-certificates/

@Achshar: VPSes have gotten exceptionally affordable lately. DO and AWS -- some of the current market leaders for cloud instances -- both offer reasonably-performant setups with high uptime for about $5/month, and that includes command-line access.

I'd argue that among people who know about Let's Encrypt, VPS hosting is more popular than cPanel-style shared hosting.

I am a tiny single person company, VPS require a ton of setup and maintenance (for me, a noob). Believe me, I tried. I bought a vps with the intention to move over, but it was too much. I am not a unix user, I can manage xampp, but installing and making changes via command line, setting up php/mysql/apache/whatever else is more work than I get paid for. Something that just works is far more preferable to me as a college student.

Don't switch. I got a VPS for my personal site and projects a year or two ago (after 15 years of shared hosting) and if you're not comfortable on the Linux command line your server will get owned and be part of a botnet before a week is up.

FWIW, cPanel just announced Let's Encrypt integration with their AutoSSL feature: https://blog.cpanel.com/announcing-cpanel-whms-official-lets...

Several shared hosting services offer native support for Let's Encrypt now. One of many lists: https://community.letsencrypt.org/t/web-hosting-who-support-...

It looks like current versions of CPanel now have native support for Let's Encrypt: https://features.cpanel.net/topic/provide-support-for-lets-e...

Either change host or automate submission of cpanel's certificate. This could need modifying an ACME client. It might mean letsencrypt is not ready for you (yet).

I'd wait for your host to update its cPanel (unless you absolutely need https, then I'd either change hosts or buy a certificate elsewhere).

Even if you do not have command line, you probably have ftp or sftp access. If you search for filezilla in your share hosting forums, you will probably find the protocol and url.

Yeah I have FTP. But can I install certs via ftp? I mean yeah sure I guess since they are just files but won't that be like too much work? Knowing what to put where and how. cPanel is a lot simpler. Paste cert and private key, press submit.

It's not a huge time investment to learn how to do something like FTPing a cert (much less so for someone getting a Masters in Computers). Your time would be much better spent learning how to do it than spam replying "I don't have the time to learn" all over the thread. /rant

get a better hosting environment.

cPanel now supports LetsEncrypt natively:

https://blog.cpanel.com/announcing-cpanel-whms-official-lets...

Disclaimer: I work there

I find the command line interface much less "fugly" than a GUI would be.

I don't know, a service like ZeroSSL (email/domains, submit, upload verification, submit, that's all) very much simpler than any command line utility, especially for simple tasks, to be done my newbies.

I think you are going to have a tough time convincing the HN crowd that a web GUI is simpler than a CLI utility; it is much more difficult to automate web GUIs than CLI utilities, and doing something like this by hand is going to seem unnecessary, given how rote this sort of task is.