@serverco If you feel comfortable sharing those scripts, I’d appreciate it as maybe they could help me get started on my own. If I recall, the conversions were hair pulling (the JKS was especially bad in my memory). It’s too much of a fantasy I guess to hope that there could just be a single format for SSL that every operating system could understand. Sigh, one day…
A single storage format would be ideal lol (but that’s way beyond Let’s Encrypt ) - I don’t mind sharing scripts - I’ll PM you.
Getting a proper JKS set up is painful the first time, but once you have the commands set up, it’s the same thing every time and decent to automate.
PFX is just a PKCS12 file, and OpenSSL itself can handle conversion in and out of that with and without passwords.
Some Java setups can support PKCS12 in addition to JKS, so you could look at if that’s possible for you. Hopefully @serverco’s scripts will help.
I strongly support the option for people to choose a 1 year certificate if they so desire. I agree with all of the Cons mentioned, and as for the Pros:
This should simply be down to the server admin to decide on whether to take that risk. I consider my server to be very secure and I have never had an SSL cert compromised. It’s not much of an argument for forcing 90 day certs on everyone.
This is a very weak argument. Any competent server admin is not going to “forget” to renew their SSL cert. As for warning-blindness in end-users, that might have applied back in the days when they merely got a popup window. Nowadays, however, in most browsers they get a big red warning about expired certs that actually makes it quite hard for them to visit the site. This is another reason, by the way, that a server admin is not going to forget to renew their cert. Not for long, anyway. Their site traffic will plummet.
[quote]Let’s Encrypt’s total capacity is bound by its OCSP signing capacity, and LE is required to sign OCSP responses for each certificate until it expires. Shorter expiry period means less overhead for certificates that were issued and then discarded, which in turn means higher total issuance capacity.
I don’t understand why a shorter expiry period means less overhead; perhaps someone could explain.
I seem to recall reading a comment somewhere stating that (and I’m paraphrasing and possibly misremembering) while Let’s Encrypt provides a service for website owners and/or server administrators, that’s not really who they’re working for - they’re working for users to allow them to communicate securely with websites. If you think about it from that perspective, it makes sense to opt for the safer setting rather than let server admins make a choice that could potentially harm them and their users.
As for never having been compromised - if your server software used OpenSSL in any way (which would be the case for pretty much any mainstream web server on Linux), you were likely vulnerable to Heartbleed at some point, and would’ve potentially benefited from shorter certificate lifetimes. Just because it hasn’t happened to you yet doesn’t mean it’s not worth thinking about.
That doesn’t match my experience, which is closer to “any manual recurring process will be forgotten or messed up at some point.” There’s news of some high-profile site having their certificates expire every couple of months (though I feel like it’s been getting better in the last 1-2 years or so).
OCSP responses are only valid for a certain period. Let’s assume you accidentally issued 20 certificates for your domain while implementing Let’s Encrypt for the first time. With a one-year lifetime, Let’s Encrypt would have to sign OCSP responses for each certificate every couple of days (typically ~3) for a whole year. I think even in case they’re revoked, response signing would need to continue until the expiration date. With 90-day certificates, that’s significantly less load over the course of a year.
Note that if you were vulnerable to Heartbleed, you could have had your private key stolen and not know it happened. With a long-lived certificate where you didn’t revoke it manually, that’s a lot of time for a potential attacker to have access to private data.
Where I work (medical startup) we had a client that ignored our warnings that their provided certificate was near expiration until it actually expired after hours in the middle of a week. Suddenly, it was an emergency as they had a customer needing to use the service the next day. We’ve moved the subdomain they use over to Let’s Encrypt and won’t have to worry about that kind of mess with them anymore.
Suffice to say, it isn’t always the admin that “forgets” to renew. Also, sometimes circumstances delay action and that can create an issue where the certificate doesn’t get renewed in time. Automating renewals resolves the problem of needing human intervention as a matter of course.
Obviously this isn’t directly related to certificate lifetime. You can automate for one or three year expirations, but the process is more likely to fail since it’s run so rarely. Besides that, if you can automate why not also gain the security benefits of short lifetimes?
That’s my understanding as well. The OCSP servers have to respond that the certificate is revoked until past the expiration date. This means that signing still has to take place.
OCSP signing requirements for revoked certificates
3 posts were split to a new topic: OCSP signing requirements for revoked certificates
OCSP signing requirements for revoked certificates
As someone still cursing the hostility to StartSSL - I was happy with how StartSSL worked.
- You validate the root domain; then
- You can create certs for any subdomain under that domain.
That works extremely well for systems that don’t have web servers - and nobody should really let automated processes punt data into their DNS.
Validating every god damn subdomain with LE is going to be a major PITA. Couple this with a 90 day renewal and would increase my workload for this stuff by at least 600%.
So, my thoughts would be:
- Allow AT LEAST a 1 year expiry (and consider 2 or 3 year); and
- Allow a root validation (ie mydomain.com) to be valid for all subdomains.
These two factors are major limiting factors in what can be achieved with LE.
I’m in the same boat as you. Same problems. Finding that LE’s offering is very sub-par to what StartSSL offered.
My approach is to delegate a subdomain, let’s say acme.$domain, to a dedicated host, that does nothing but ACME cert retrieval.
For each host that needs a cert, I have to create a CNAME from _acme-challenge.host.$domain to host.acme.$domain only once. Then that host can upload its CSR and download its cert via SFTP from the dedicated ACME host.
No running a web server on your mail server or opening up your DNS to permanent updates. Private keys also stay on each host.
From a beginner with Let’s Encrypt:
I have been playing with computers since '72, and it’s still my main activity, and hobby.
I have only 2 domains and a mere 13 sub-domains, one at 4th level. (Nothing compared to a major business.)
I use one domain for small business eCommerce activities.
I use shared hosting on Linux/Apache server with cPanel access.
My host has not enabled LE functionality in cPanel, and likely never will. (It would cut into their own cert sales revenue.)
I also host the majority of the sub-domains on my home computer, also Linux/Apache.
I came into this knowing nothing about certs or openssl, etc.
I have 3 certs from LE covering about half the sub-domains, as well as both domains themselves.
I have not tried to use any clients to automate the cert process, and have not scripted any part of the process.
I used zerossl.com for the original certs, and for the renewal - with HTTP verification in all cases.
I have reorganized, renamed, and scrambled my local server’s config multiple times.
I have read this thread from top to bottom.
The time spent, so far, in getting and configuring my certs, plus what renewals and experiments will likely take for the next two years, is less than the time I spent reading this single thread.
I can boil down everything “important” said, on topic, in this thread to one phase: "I’m too lazy to read."
IMHO 90 days is plenty of time for a cert’s lifetime.
I’m sure there are plenty of “edge” cases that could be found - maybe even my own - where 5-6 manual renewals per year is a PITA, but “manual” isn’t what LE is about.
I will automate, if I ever figure out what I’m doing, but manual wasn’t a PITA for me, a rank tyro, so how could it be any harder for those who claim to know what they are doing?
As many “members” have said herein, I have read nothing to justify the need for a longer lifetime, optional or not, manual or not.
Final though: keep it at 90-day lifetime, for now, and possibly reduce to 30 if the automation and LE’s OCSP signing capacity permit it.
Plan to provide a sub domain for non-technical minded web users to manage the install of SHA-2 Certs
You never know when some stupid update or similar breaks your system. I’ve had updates to SAMBA authentication break my media player. With a, typically, 60-day renewal cycle you’ll have a better chance of finding the break than you would if you waited 365 days to renew.
True – if it’s one person automating for one person. if it’s 50 people automating for 100,000 people, it flips the script in favor of automation. If it’s only a handful (5 if you use my hand,) and 250,000 benefit, then it’s even better. Henry Ford knew that a long time ago.
this is something I can sign off. if you can automate, and do so easily, well
well if you use the site yourself, you will find it out anyway. and if you automate the hell out of it it may become a “I wont touch this ever again” system at some places, you know how sadly sometimes IT really runs on a “never change your running system” way. while if you do your renewal manually once a year those ppl may at least think about updating their systems when they are at it anyway.
I would like to point out (what we consider) a MAJOR concern with the short lifetime of these certificates. Recently, Mozilla released a web vulnerability tool called “Observatory”.
One of the recommended security options they tell you to include is called HPKP or public key pinning.
The issue here is this, the “Key Pin” is related to the active cert for a domain and MUST be regenerated at every renewal. Now, we implemented this on a recommendation from our security scanning firm, but having to regenerate these pins at every single renewal involves too much hands on work to justify (And since this key has to be added to httpd.conf for each host every time a cert is renewed, and that in itself requires an apache restart, that step really doesn’t seem to be a candidate for automation)
Doing this once a year (Or really, even once every several years) is a lot more reasonable than allotting time every three months. I wish you would allow users like us to choose how long registration will be for (similar to pretty much every other certificate issuer out there). That way the people who WANT to use shorter lifetimes can, while people who desire to not have this restriction can also go about their business as usual. Just my two cents.
And that’s not everything. Wuth having to change the key every less than 90 days that again means you need to have very short pins (if you are going for auto renewal every 60 days then it’s even shorter) and you pretty much always need the next key online on the machine sobit can do the renewal.
When you can do it yourself like every year, you could safely store the next key offline and/or encrypted for more safety making the pin more secure. Also with such short pins they hardly help rarely visiting people.
But instead of hpkp i woild think tlsa with the “still validate the ca” flag would be better (if it would be supported) because in a worst case you just change the records and don’t have to keep the site down for the rest of the pin’s life.
Just my 2 certs…
HPKP works, as the name indicates, on the public key level, rather than pinning to a specific certificate. It is perfectly acceptable to reuse the same key across multiple renewals.
certbot just happens to generate a new key for each renewal by default, as that’s the best choice for anyone not using HPKP (which is the large majority of users). If you’d like to reuse the same key, you can do that using the
--csr flag or with one of the other ACME clients.
certbot will likely gain a flag to reuse the key during normal (i.e. no
--csr) operations in a future release as well, making this even easier.
More details on HPKP and Let’s Encrypt can be found here:
As @pfg has already pointed out, it isn’t the certificate that’s pinned, but the public key (or, more precisely, a hash of the public key), and it’s certainly possible to reuse the same keypair across multiple certificates. Further, it isn’t required (and, in fact, it tends to be discouraged) to pin your “leaf” public key as the only option. It’s often recommend to pin the public key of your CA, and often of a potential backup CA, instead; this will completely avoid the problem you mention.
Only if you’re pinning the public key of your leaf certificate(s). You don’t need to do this, and there are some fairly strong reasons not to (one of which being exactly what you mention). You can also, or instead, pin public keys of your intermediate or root CA.
unless you just so happened to pin for exammple startcom as primary and wosign as backup.
well for intermediate certificates, see them changed, maybe even with a new key -> you’re screwed and even roots wont help when CAs see oblivion, like startssl and wosign. and this is the part where TLSA with PKIX-EE: Service Certificate Constraint mode, in other words the key (or certificate, depending on what you like) must match and the cert must pass CA validation.
the other good thing is, in case of a worst case you can just switch out the records and everything is fine.
and since TLSA runs on DNSSec you can forget manipulation.
sadly TLSA isnt widely supported yet (it really should be, though)