nice explanation @schoen one for the FAQ 
3 Likes
tl;dr:
- Many services that require SSL will not be webservers and almost all of these services require restarts to update their certificates. This is not acceptable. Frequent restarts of critical services will ruin those services.
- Smaller organisations running these services are particularly vulnerable as they tend to have smaller or non-existent technical staff that may not remember to update their certs and restart the services.
- The Let's Encrypt team seems to be very about controlling the routines of their users/clients. There are established ways to do things - there are good reasons for certificates to be issued for periods of one year or longer, which is shown in the fact that everyone that currently issues certs does this.
That sounds like missing the point, to be honest. As @rakiru explained, your HTTPd is far from the only thing you're going to be running that might require SSL. You might be running mail servers, an IRCd or IRC bouncer, any number of chat services, VPNs or other proxies, and so on - and practically none of these things can traditionally have their SSL certs updated without restarting the software and kicking all the clients, potentially missing critical mail or breaking the connection of people using your VPN.
It's very easy to shove this problem off and ignore it, saying automate it as if that comes close to solving the issues caused by restarting critical services all the time, or by declaring it not our problem and stating that the software should adapt to the Let's Encrypt model or certificate lifetimes, but realistically, neither of these things are going to help fix the problem and may, in fact, be a huge factor in people not using Let's Encrypt entirely.
Let's also not forget that many organisations that may end up using Let's Encrypt will be small-to-medium-sized communities (like mine) with small technical staff - perhaps even totalling one person (again, like mine) - that simply stand zero chance of remembering to renew their certs. When you consider that you simply can't feasibly automate everything, this can be a huge issue for those communities.
And really, if my Reddit session ID is important, my NickServ password is magnitudes more worthy of protection. You can't just ignore other services because they aren't HTTPds.
Additionally, and as other users above me have noted, the Let's Encrypt team appears to be very into controlling the routine of its users. There are established ways of doing things that have been there for quite some time. I feel like we would have found better ways to do these things in the huge amount of time we've been doing them. CAs issue certificates for a year or more at a time, and while I'm not in a position to enumerate why they do this, I'm sure there are good reasons for doing so.
I remember reading at some point that people thought that the 90-day thing was a good idea because it will force people into a good routine but this sounds ludicrous to me. As a pretty forgetful person myself, it's clear that you can't learn to remember things better - If my certificate expires every 3 months instead of every 12 months, I'm just going to get annoyed and revert to semi-shady free cert sites because I don't have to worry about it so much - the 90 day system wouldn't make me remember to renew my certs more often, it would add stress as my certificates expire and all my services break down.
Apologies for the essay. I think I ended up rambling a bit too much but I hope I got my points across - I've been massively hyped about Let's Encrypt since I heard about it a long time ago, but this 90-day thing makes it almost completely unusable for me, and I'm sure I'm not the only one.
8 Likes
I think instead of complaining about small certificate lifetimes (which really is a good practice), all of this energy should go to bug trackers of software thatâs unable to gracefully restart itself. I bet itâs a win-win thing to do.
6 Likes
I agree - this would all be moot if the non-http services were able to reload their config files OR just the certificate files OR a graceful restart.
1 Like
Thatâs a pretty narrow way to look at things - you canât expect swathes of software developers to suddenly adapt to one single serviceâs way of thinking. Theyâll just tell people to go elsewhere for their certs.
EDIT: Also, a âgraceful restartâ is still a restart.
5 Likes
Iâm going to assume by âgraceful restartâ you mean a reload rather than a restart, as any form of restart is still out of the question for many things. While in an ideal world that would be the best way forward, weâre not in an ideal world; weâre in the real world. While we can certainly start creating tickets on issue trackers everywhere, it doesnât mean theyâre going to be resolved any time soon, if at all. Itâs a rather self-centred way of viewing it if you think all software is going to rush to address this issue just because one CA goes against the norm[1], especially in areas where SSL/TLS either isnât considered important, or even considered at all. I thought the point of this project was to help encourage service operators to provide higher security for their users?
Additionally, the âit should be 90 days to encourage automation to make sure people donât forgetâ argument is a poor excuse. I donât forget to renew my domains and thatâs a yearly thing at minimum. I also donât forget to renew my hosting, which can be paid for months/years in advance.
[1] A year is far less of an issue as pretty much everything needs a restart at least once a year for updates anyway.
4 Likes
Will they ever be for 1 year long lifetime or 3 years long life time
2 Likes
Jacob already addressed this earlier in this topic.
1 Like
I already addressed those responses.
1 Like
Both. Think of nginx model of doing this. (Sections âChanging Configurationâ and âUpgrading Executable on the Flyâ)
It probably is. One of the most recent changes in CA/B Forum Baseline Requirements says:
Subscriber Certificates issued after 1 April 2015 MUST have a Validity Period no greater than 39 months
(Section 6.3.2. Certificate Operational Periods and Key Pair Usage Periods)
I very much expect, that this period will only decrease over time, and as far as I can see, the âreal worldâ converges with the âidealâ in this regard, so itâs probably a good idea to be prepared for such changes by implementing reload/restart mechanisms in relevant software, instead of impeding progress in security tech/practices. And yes, if you really donât like these constraints, there are still plenty of other CAs.
See nginx model of restart I linked above, it implements 0-downtime restart, if youâre worried about that.
2 Likes
Oh, donât worry, I know how awesome nginx is. However, nginx is a HTTPd, handling a protocol that is very suited to short sessions/connections that are closed quickly.
Conversely, much of the software Iâve pointed out is based on long-running connections, where restarting will immediately knock off all your users. Besides, what are you supposed to do when the cert changes, even if youâre reloading it without restarting? Should you disconnect everyone using SSL or let them use the old cert potentially forever? Iâd assume the former is much more secure, but then weâre back where we started.
2 Likes
Yes, I think itâs pretty reasonable for connections to be dropped once in a couple of months, to be reconnected in a matter of seconds that is. For irc example it should work very well (Freenode netsplits much more frequently than two months anyway). Mail servers donât have persistent connections afaik, so they can reload their stuff a la nginx. And it isnât like you daily renew certificates anywayâŚ
1 Like
While I understand why, as an admin, one might find that reasonable, many users will not (and, historically on my network, have not). Freenode is kind of a bad example since itâs so big that netsplits are inevitable - Smaller networks like my own often do not netsplit at all, or only once every few years.
Mail servers have web-like sessions, yeah, but often will have long-running connections due to large email attachments and the like. I think the concern there really depends on how much your mail server is being used. Note also that most mail systems are postfix-based (eugh) and therefore have several components that need restarting, so itâs not like youâre just taking down smtp - the whole thing goes down, including webmail, and the fact that there are multiple components will mean that the restart will take considerably longer than a single component.
Also, one of the examples I gave you was VPN services - an area where security is a huge priority, particularly in parts of the world where they are used to get around oppressive censorship. I suppose one really could argue that key exchanges or some other form of security would be more suitable there, but SSL is still going to be widely used.
Slightly offtopic: Why is a short revocation considered a good idea? People have said âOh, staff might change in a year, or⌠Maybe itâll get people into good habitsâ but the former point is addressed through good management, and the latter makes no sense since you canât learn to not be forgetful, so⌠I donât see it.
5 Likes
I guess at this point Iâll rest my case and reiterate the primary goal of the project, as far as I understand it, that is: making http connections encrypted (green/grey lock in the browser address bar). Anything else goes beyond the initial scope.
2 Likes
Those large attachments are not problem. The master will just spawn new workers and the old workers will stop accepting new connections, but handle the remaining ones.
The point is that you should automate it, so you don't even have to think about it anymore. No other CA provides this as of now.
2 Likes
Yeah, but then we've just come full circle, lol. We can't automate everything. And expecting projects that don't support live-reload of SSL certs (such as IRC servers) to suddenly implement that is a narrow, somewhat greedy view of the situation.
I agree that automating this stuff is the ideal end goal, though. Automatic certificate renewal? Fantastic! But it's just not possible right now.
5 Likes
If you donât start now, when do you want to start? Itâs time to implement zero-downtime restarts now, itâs 2015.
1 Like
I can see both sides, but as to when do you start - most folks (who are not system admins i.e. end users) will only start when automated process are available through the web stack or software providers own offered software. For example, when apache, nginx and other TLS using software can natively offer such automation to make the process easy.
2 Likes
Totally agree with you, but I feel like a sledgehammer approach won't help much - perhaps allowing only the 90-day certs to be managed automatically while still allowing the traditional one-year certs for manual generation only? That way you're still encouraging people to automate (as the process would be a lot easier), but not leaving others out to dry.
Later on, when software's been updated, you could switch entirely to the 90-day cert.
Probably not the ideal situation if you're trying to get people to automate everything, but it seems like a good middle ground.
5 Likes
So Iâve read this thread twice, and I keep coming back to this observation, the primary stated goal of this project appears with in reach. A vast swath of websites will easily benefit from the Letâs Encrypt model. While other implementations may not as described earlier. I tend to think of Letâs Encrypt as another tool at our disposal for administrative duties.
Each use case will need to be evaluated regardless before implementing a structural change to an environment that could potentially effect the core security of customers/clients. So while I do understand both sides of the coin, I am not thinking of this model as a pro or con, but more along the lines of, âwill this user case scenario work well for this environment?â.
In my case, I can see this model working for 80-90% of my clients.
ââŚArcher
4 Likes