Pros and cons of 90-day certificate lifetimes


#325

I did read the getting started page when I got into the private beta stage on 16.11.2015 obviously the option was not there. and I cant always check the docs and stuff for changes. I am usually in the forum and read announcements about that stuff (as long as it’s pinned)


#326

@Adi

Are you able to “reload” Apache instead of stopping it? I’m on FreeBSD, so my cron script looks more like:

/usr/local/bin/letsencrypt renew
/usr/local/etc/rc.d/apache reload
/usr/local/etc/rc.d/postfix reload

That way you don’t kill any active connections to your server :slight_smile:

EDIT: Oh, and I used webroot to create my cert, so I don’t need to stop Apache to make the connection! (I can’t believe I forgot to mention that.)


#327

Except for the other OSes it supports, like mine. And so what? Use one of the bash clients, then it’ll run on anything from linux to the BSDs to Windows to OSX. You’re actively looking for reasons you can’t do what everybody else can.

Why are you here? You obviously don’t want to use Let’s Encrypt. So don’t. Move on. Just stop spreading FUD.

No, it’s not. It’s been a part of the documentation since last year. You just don’t want to know.

And you thought the client would be in beta forever? That functionality would be static and the increasing version number was purely aesthetic? You don’t always have to check “the docs for stuff for changes”, but if you’re going to constantly post in this forum and make adamant claims about lack of functionality, you should at least take a peek to see if you’re wrong. (You really should, you’re often wrong.)


#328

there have been update announcements in the forum.
and I dont think I saw multi webroot in those, not sure.


#329

@DarkSteve - the letsencrypt client complains that it cannot handle my httpd.conf setup and it will only work in certonly mode - for that it needs to listen to port 80/443, so no… renewing certs while httpd is running is not working for certonly mode… already tried it and the client complained that port 80 is already in use (which was correct - httpd was running).

i have to stop httpd to free up those ports for the letsencrypt client mini-server… if it would be possible to run the letsencrypt client in certonly mode but without it needing ports 80+443 i think it could work without stopping httpd.

if it were possible to have the certonly mode use, for example, local port 79 instead of 80 and 442 instead of 443 then i think that stopping httpd would not be required… but as it is now… stopping httpd while the certonly mini-server runs seems to be the only way.


#330

@My1 - certonly mode requires the letsencrypt client to run separately as it’s practically a mini-webserver during the verification process and it needs to listen and serve the verification tokens on tcp port 80 (and 443 i think).


#331

I know that and that’s exactly one of the problems of the client. when it wont integrate in your webserver for whatever reason than you have to restart it every time you wanna try renewal.

and to everyone who flagged the post. with the “nice joke” part I meant that any half serious website certainly doesnt want an off-time each day.


#332

Note that certonly doesn’t imply standalone. You can use the webroot plugin, which uses your existing web server to serve the challenge files. You don’t need to stop your existing web server and you don’t need the client to listen on port 80 or 443. It doesn’t have to integrate with your existing web server (as in: understand the configuration) for that to work.

As a reminder to everyone, this is a discussion about the pros and cons of short-lived certificates. Having too many off-topic posts will make it very hard for people to follow this thread or contribute to it without repeating something that’s already been discussed. I encourage everyone to consult other threads or create a new one (you can use “Reply as linked Topic”) if you’re wondering how to do certain things with the client.


#333

Ah ha! Not necessarily! I’m one of those control freaks that doesn’t want the client to mess with my config (and I have all my vhosts in a single file, so the client can’t handle it anyway). But that doesn’t stop you using webroot.

Webroot uses the file system, not Apache or Nginx. Provided you have write access to the file system, it works, and means you don’t have to stop Apache.

It is for me, and has for many months :slight_smile:

No it’s not. Did you read anything I wrote above? Are you being intentionally ignorant of what the client can do? Adi’s wrong about the client, but instead of actually understanding how the client works, and what Adi is missing, you simply use Adi’s mistake as a means to justify your existing false beliefs. You’re Let’s Encrypt’s equivalent of a creationist.


#334

interesting… i don’t think i saw the webroot option mentioned when i looked in the client manual a couple of months back when i set it up… will look again now… hopefully the EPEL repo for centos has the letsencrypt rpm with that plugin.


#335

maybe I was a bit unclear in the wording.
I mean if you cant get your automation to run for whatever reason then have fun using manual mode (actually, it’s not fun)
it would be a lot easier if the same code would be used for all domains in the same verification process…


#336

Uh, yeah, sorry about that.

It’s just that after 330 comments, I haven’t actually seen any valid reasons against 90 days. Every complaint either applies to 365 day certs (e.g. “You get out of practice when automating!”) or is simply wrong (e.g. “It’s harder to automate multiple domains in a cert!”)

When you guys first announced you were sticking with 90 days, I thought you were wrong and being short sighted. But now I’ve created my certs and set a cron job… that’s it! There’s nothing else to say. You were right.

First, you generally can’t set a cron for 1 year certs (since you normally need to actively do something manual to renew), and you’ve made it so easy to renew I generally don’t have to look at it again. The only issue I’ve had was a broken port in the FreeBSD ports tree which gave me an error for one renew attempt.

Apart from My1’s imagined dystopia, what issue is there with LE’s system?


#337

but when the automation is so epic why do you do 90 days and not just a week or overdriving it, make certs that last one hour. (obvious overstatement, not meant to be this serious)


#338

It works great, and if you look through the forums I think people have already asked how to renew via webroot after creating with standalone (I created with webroot, so I didn’t pay too much attention).

Good luck!


#339

Why would you use a mode that doesn’t work for you? That’s an honest question - why would you use standalone if you couldn’t then automate renewal?

And why doesn’t it? Are you still maintaining that webroot doesn’t handle multiple domains with different webroots, even after I gave you multiple examples and even linked you to multiple documentation pages?

You can if you want, using -renew-by-default.

But from LE’s perspective, they’re balancing service load with their stated goals. Having a cert last a week gives very little time to fix issues if something goes wrong, and is a significant load on their system. 90 day expiry (defaulting to renew after 60 days) gives plenty of time to address potential problems, still incentivises automation, isn’t a huge load on LE servers, and promotes LE’s goals.

This is pretty obvious if you think about it.


#340

We know that a sizeable minority of web clients have their local clocks set wrong. In most cases they’ve added or removed summer time in the wrong place, or they set an adjacent time zone. Visibly their clock may seem “right” but its sense of UTC (the “Universal” civil time used by certificates on the web) it’s wrong. And surprisingly large proportion of humans are even OK with clocks that visibly show the wrong time by an hour or so. Personally it bothers me and I fix them but that’s just me.

Anyway, if the web client clock is wrong by an hour, a brand new certificate may seem not to be valid yet, or, at the other end, a certificate with almost an hour left before expiry may seem to be expired already. In both cases the client gets an error and most users won’t say “Huh, my clock is wrong, I’ll fix that” but instead “This site is broken” or maybe “This browser is broken”.

So, one hour certificates, while superficially interesting can’t actually work with enough systems to be practical. Ninety days doesn’t have that problem. I’m sure there are people with system clocks that think it’s January, or 2015, or even 1986 but not enough of them for us to worry about, much as we don’t worry about whether IE4 works with web sites any more.


#341

…especially any valid reasons that weren’t raised in the first post in the thread. Yes, 90-day lifetimes make manual issuance/renewal more inconvenient. Yes, the LE folks know that–it’s mentioned, in several different ways, in the first post here. No, there’s no reason for one individual to have 72 posts so far in this thread, virtually all of which are some variation on “but it makes it harder to get certs manually, for the increasingly rare and bizarre edge cases I keep coming up with.”


#342

[quote=“DarkSteve, post:315, topic:4621”]Why is this an issue for you? I don’t understand the problem, I have no idea how “93 days” fixes anything for you.

You can renew at absolutely any time you want with the -renew-by-default flag, […] Once configured, you never have to do anything regarding the certificates ever again.[/quote] Not strictly true. If you can get the new certificate installed by purely scripted means, yes, fine, no problem. But (warning: extra information) not all of us, for whatever reasons, have that option. Some of us have to paste certificate text into web forms (and we don’t always get to choose the hosting which we’d prefer).

I’ve settled on acme-tiny since that’s conveniently available via apt-get and gets the certificate with a minimum of fuss; nice simple tool. If run every day, it will get a new key every day, so it doesn’t get run every day. I can see ways of improving things – check the certificate’s remaining lifetime and whether the current one’s installed, running acme-tiny or generating a reminder as needed. Or I could just set up cron to run it occasionally (which either works well or fails hard).

The mathematically correct department says that six times per year is every 60⅚ days or, for a leap year, every 61 days. The wetware department says every two months rather than 60 days for calendar-related reasons.

Maybe if every month always had the same number of days – let’s say 30, for convenience…

[quote=“DarkSteve, post:317, topic:4621”]
Do you know what it takes to automate renewal of a single domain in a single certificate?
letsencrypt renew[/quote]
Oh, nice. It automatically handles web forms (and login and naviation to the form) too, for where you have to paste the certificate into a textarea? I didn’t know that…!


#343

There are some alternate scripts that do - yes. It depends which “control panel” you have (so I’ve no idea if there is one for your specific control panel yet, or not, without knowing which “control panel” you use).


#344

Let’s Encrypt is designed, from the beginning, to be an automated system. It’s designed to set up once (point your stuff at the symlinks), set cron, and you’re done. If you’ve chosen to go another route, fine, pay for whatever certs you want.

Don’t want to pay for your cert? Fine, move to a better hosting service. You can’t because this is for work? Stop complaining, you’re being paid to copy and paste stuff into web pages.

I don’t know what to say about that. You’ve chosen a client that superficially seemed easy, but you’re projecting that client’s limitations across the board. Don’t do that. You can paint the floor any way you wish, but if you paint yourself into a corner, don’t blame the paint or the floor.

Given the information you’ve provided in your above paragraph, I’d set the cron job to run once a month. Done. Problem solved. No issue. I don’t get what’s stressing you.

Hehe! And I thought I was OCD! :wink:

If you have to manually paste stuff around, just manually renew before you manually paste.

I don’t have to paste anything, and neither do you. You paste the location of the certificate once when setting it up. That’s it, you don’t need to keep pasting.

If you are using incredibly badly designed web apps that require constant maintenance, then you can either get better web apps, or suck it up and pay for a cert somewhere else. LE isn’t for you.

If this is for work, then you’re being paid to copy and paste, either stop complaining that you’re being paid to do your job or change jobs. You could become a musician!

“You can automate if you want to,
You can leave My1 behind,
Because crzlwdlwyc don’t automate,
and if he don’t automate,
Then, he’s no friend of mine…”
-Men Without Facts

(Now I think about it, most people in this forum probably weren’t born when that song hit the charts. Sigh, I miss my C64.)