Yes, that’s a good point too. But as I said - As of Feb 2015, when we set up the site, we hadn’t actually had a discussion about certificate lifetimes.
Yes, I know it is over year old but situation changed since then and I thing it is good to show you are using your own product now
BTW, I agree on short lifetime. It has good side effects - better motivation for HA solution (life reloads of websites) and scripting certificate renewal.
I see. There is different situation if your Discourse is hosted. I understand. I am using LE certificate on my on-premise Discourse without problem (there is no Win XP issue there because Disc is not supporting it neither ).
well but I also heard of people who dont like the automation because they dont want software to get the certs and mess with their servers. and I can understand that point which is a MAJOR disadvantage of LE…
It is not a “MAJOR disadvantage”, as changing server config only happens if the user specifically asks the client to.
I didnt mean server as in “the webserver daemon and its stuff” but the server as a whole.
So… your complaining that when the user runs the certificate client, certificates are placed on the server’s drive? Under what circumstances would a user want to obtain certificates but not actually receive them?
The official client saves the requested certs on the drive (or saves renewed certs) unless the user specifically requests otherwise. Please explain what this does to the “server as a whole”.
Because it really looks like you’re making up things to complain about. You’ve been contributing in this forum for a while, and have provided valuable feedback to LE and good advice to other forum members, but then there’s this bafflingly strange area where you have a blind spot to reality, and you start using vague terms (e.g. “mess with the server”) that you later redefine or backtrack on.
This is the second thread about 90 day certificates where you’ve done this, shifting goalposts from incorrect claims about 90 day certificate limitations to claims of LE “messing” with people’s servers. I just don’t get it.
Let me state for another time that I don’t like 90-day certificates because I would like full control of the process of renewing and therefore, this forces me to manually renew every 60 days or so… I would really like 1-year certificates.
So you’re saying that there are server admins who are simultaneously (1) willing to run an arbitrary web server, which is far too large and complex for them to personally code-audit; (2) unwilling to run other software they haven’t code-audited; and (3) unable to code-audit a 200-line Python script? How many such admins do you think there are?
The client has to do exactly one thing: obtain a cert. The official client can do a number of other things, but they’re all optional, and many of the other clients don’t do them. If the server admin is absolutely unwilling to have any software do that on an automated basis, it seems pretty obvious that Let’s Encrypt is not for him. Your stated concern seems to depend on a curious blend of paranoia and incompetence that don’t seem to be suitable for a server admin.
unlike LE apache (probably nginx too) is pretty old stuff and have recieved probably more than enough scrutiny.
also apache can run with lower rights (e.g. read only whereever it doesnt need to) while LE runs as ROOT!
…unless you use one of the many alternative clients that don’t run as root. What’s the next red herring?
Edit: Unless it’s going to use an existing CSR, the client needs to be able to read your private key, which ordinarily should have very restrictive permissions (usually owned by root, and readable only by owner). For this configuration, the client would need to run as root. You could create a group (e.g., “letsencrypt”), with only root and letsencrypt as users, make the private key readable by that group, and run the client as that user; in that case the client wouldn’t need root permissions. Or you could create the CSR once as root, and allow the client to submit that. In that case, the client only needs to read the CSR, which doesn’t contain the private key.
The other permissions needed depend on the validation mechanism you’re using. For http-01 auth (probably the simplest to complete), the client needs to be able to write to whatever directory appears as http://yourserver/.well-known/acme-challenge/. For DNS, it somehow needs to be able to update your DNS entries (if your DNS provider has an API, this can be simple; otherwise it may require manual intervention).
But really, I think we’ve had this conversation already, in this very thread. Your complaint is that the 90-day lifetime makes manual renewal a PITA. My observation is that the LE team doesn’t care–their focus is on automated issuance and renewal, and they aren’t particularly interested in dealing with that manually. You keep repeating that concern in slightly different ways as though it’s something new, but it isn’t–the LE team is aware that this lifetime makes manual issuance and renewal inconvenient, and they clearly don’t care. Or, at least, they don’t care enough to change it for that reason.
Then LE isn’t a solution for them… But there are a dozen of different clients out there, the one more simple than the other… And all open source as far as I known. Besides, most servers run open source code while the server operator hasn’t checked every line of code of those programms… Why make a fuss about LE and/or one of the 3rd party open source clients?
not just the 90 days but the way validation and the LE client work in general. if they had a walk up procedure (aka I dont need to confirm each and every subdomain) it would be MUCH easier.
if it would work similar like startssl where it’s (aside from the fact that you sometimes have to wait for the actual cert) usually pretty quick, especially because I can just create a blank CSR and give them the domains later on.
even CACert where they have t get a realistic CSR (pre-filled with SANs with can be a bit annoying on the cmdline) is still easy to use (but they really need an expiry for the domain validations)
also I dont think I need to talk much more about shared hosting without SSH. where creating larger SANs is very difficult.
Yes, but this thread is about the lifetimes. Your other concerns belong in other threads (as at least the walk-up suggestion is).
well but the lifetimes do play in a bit because what is worse? doing the overly tedious task once a year or 6 times a year?
It’s a bit of a arlésienne with the same talk being repeated over and over…
LE is designed to be used with an automated tool, of which several are available which make the “overly tedious task” a non-event. If a server admin is just philosophically opposed to installing any third-party software to manage certificate issuance and renewal, then LE just isn’t for him, and he should use a different CA. Yes, you can use LE manually, but you’re working against the design of the system. Using a tool for something it wasn’t designed for is almost always going to be more difficult than using the right tool for the job.
If it’s a matter of running as root, as I pointed out above, there are plenty of clients that don’t need to run as root. If it’s a matter of not trusting the code, most (if not all) of the clients are open-source, and some of them are really small–the admin can easily read through a few hundred lines of code to see what it’s doing.
Automation is one of the key principles of LE, second only to “free”. It seems clear, by observation, that the LE team aren’t interested in simplifying manual usage of the system–that just isn’t a problem they ever intended to solve. If you want them to care about this use case, you need to show them why they should, but you haven’t made any attempt to do that that I can see. Simply repeating “manual usage is inconvenient”, over and over again, isn’t likely to do it.
So continue paying for the “convenience” of manually managing your SSL Certs.
This is an improvement for > 90% of the people needing or wanting SSL certs. For those who can’t or won’t use it, nothing has changed.
This has already been pointed out repeatedly. Not everything can reload certificates with breaking connections, and this is unlikely to change any time soon. Not to mention isolated systems where automated renewal isn’t acceptable.
That the LE team isn’t following up on these points, doesn’t mean that the arguments are not being made.
Do you have example of such piece of software, that cannot reload a certificate without breaking connections ?