I have big problem with ours short period certificate issue.
I count that I have about 30 - 40 subdomains on my primary domain (means something.example.com). You don’t want issue wildcard certificate… that means for my that should create 40 certificates
and than log into each server and add certificate… and this I should do every 90 days??? Are you crasy???
we have many servers based on 3rd party solutions… like mail server, backup server, domain server, remote management server, vmware etc … this server will never support auto revocation of certificate. Is absolutely needed for this server have certificate with validity in YEARS !!!
Same problem i with your policy that you don’t want issue WILDCARD certificate … that’s means, I will be forced setup another sertificate on each server. That is nightmare.
yeah i have some domains with 80+ subdomains behind a single wildcard SSL… that clearly isn’t suited to letsencrypt usage so i’d probably stick with a ssl wildcard certificate for $40/yr instead.
single domains probably more ideal for letsencrypt usage right now.
40$ per year? that’s really cheap where did you get that?
also you dont need to issue 40 certs but if you have multiple domians running on each server, then you can create a SAN (Multidomain) cert that covers all domains used on one server.
I think @eva2000 refers to this offer, and if you closely look, it’s even down at $39/yr for a 2-year wildcard cert. It looks as if the discount offer would be still valid, even if it claims to have ended e/o October 2015, but I haven’t proven that.
I think that LE is targeted primarily for supported servers which will do the process of re-aquiring certificates fully automatic, so there is no such thing as a LE nightmare in this scenario, for any number of domains. This is actually the preferred solution and the reason, why LE and ACME exist.
LE does offer manual application of certs and even manual creation of keys and CSRs, but this is only suited for people who can live with the drawbacks. Funny thing is, some people might see it as a benefit that LE offers only such short lifetimes as it is hard to get such certificates regularly from most commercial signing CAs.
New certs every 60 days (or even more frequent) means also higher security. That’s what you want. If you’re still on the dinosaur track of manually installing certificates you definitely should rethink your approach irrespective of LE’s short lifetimes.
well offering short lifetimes is one thing. enforcing them is another.
especially I have the combination of Win plus XAMPP (apache webserver) and there the stuff gets annoying. the only win client for LE is IIS compatible, which obviously wont help me, so my only way is booting up my raspi and use manual mode, which is a bit annoying but works splendidly, and having to do that every 3 months, well I dont exactly like that. I hope the challenge stays the same so I dont have to update that everytime.
Well, the short lifetimes of LE certificates are one of their selling points for security. Everything else has to be fixed in the LE client. I think they will update the client so it can be used with Apache on Windows as well. I wouldn’t question their selling point – as already mentioned, there are other companies with different targets which do support your (old) certificate renewal approach, so perhaps it’s better to go with them if you can’t wait for that feature or participate in development.
I’m not a dinosaur, but at most of server’s global companies as DELL, HP, EMC and many others that you must use in “bigger” company are the dinosaurs…
there is no way to get certificates to this 3rd party solution servers by fully automatic way :o(
And thinking that short term certificate is much safe than 1 year certificate is non-sense. If would be possilble to crack itm in 60 or 90 days… so this type of certificate (encryption) would not noone use or trust them … like SHA-1
but there are parts where the small lifetime and automation are not really things that work well, like in a non-HTTP environment for example then stuff gets rather complicated especially since LE literally cant support everything I think that for the stuff that CAN and be and is automated get a max of 90 days and that manual-mode certs CAN get a longer time IF the yrequest it, keeping the default at 90.
@petr.svec well it is at least a lot easier on CRLs since they can be cleared faster also they are “safer” in the way that an algorhythm is cracked the users can be forced to switch faster, what is at least one point of higher security.
when someone made a 3 year cert 1 year ago where SHA1 was still more or less the standard then they probably keep it for the next 2 years and SHA1 is broken, even through not yet in a practical way. with 90 days length or even just a year they have to change quicker meaning that a massive hole like SHA1 has a LOT shorter exploitation time.
@Nemis why? @kelunik well, ms is not the only player, also some CAs (like startssl) are (for whatever reason) still offering sha1 for 1 year certs so it’s not really dead yet, even though I always use SHA512 to get it a bit more secure.
i have access to lot of hardware with web-gui, printers, servers (iDrac), switchs, routers, antennas … every device has an ssl selfsigned or signed by vendor. more or less not valid on last browser. (or next year) .
need to use all LE ssl? NO. only trust the SSL that hw use.no need to change.
and petr.svec ask if LE are “crasy” cause they give free SSL 90day long…
I do have long-lived certificates where ssllabs.com complains “weak signature. When renewing, ensure you upgrade to an all-SHA2 chain”. So if I didn’t test this and got active before the certificates end of life, the renewal might be in a few years, leaving me in the deprecated situation for so long. With short-lived (and automatic) renewals, benefits of improved crypto (as far as implemented on the CA side) would be rolled out within a few months without the any need for intervention.
The longest-lived https-certificates (decades, really) that I encounter in the field are in fact those of stupid appliances that insist on having a https-only interface protected by a built-in certificate that is supposed to be changed by way of firmware update only (if at all) - a procedure most folks don’t follow on anything like a regular schedule. Here the consequence of logevity is often that the webinterface of the appliance cannot be accessed at all - because all modern browsers reject the crappy encryption these devices offer (though they would happily talk http if offered).
In summary, I suppose that short-lived certificates do serve a pupose even if the short lifetime is in no way related to an expectd short time to decrypt. (But, yes, in all but highly automated situations, their maintenance would be a mess)
You can actually think of OCSP as short-lived certificates for certificates. Using OCSP Stapling, the server actually regularly fetches these short-lived certs … this is quite similar to short lifetime TLS certificates, although different mechanisms and security/approval is in place for OCSP and TLS certificates.
Having a short lifetime doesn’t have anything to do with how long it takes to crack a certificate - with enough computing power you could certainly crack it in less than 60 days or 90 days or whatever.
The short lifetime helps if the certificate is compromised: if it’s compromised, but doesn’t expire for 2 years, then damage could be done any time in that 2 year period. If it expires in 60 days, then the bad guys are going to have to act faster.