Let's just say a widely-used commercial one for which a plugin for LE exists. The hosting provider (not entirely my choice, but then it's not me paying for it) does not have that plugin installed and appears to have no plans to do so at present.
Each renewal for the site in question requires use of one web form: one textarea for the new certificate and (maybe) one textarea for the intermediate certificate (which I can omit if I don't mind certain SSL checking sites complaining about an extra fetch being required).
Paid-for certs are overkill since there's no commercial activity on the site, and I'm avoiding self-signed because, though I'm happy to add an exception for a certificate which I know that I've created, I can't say that others who'll be using the SSL part of the site would accept it or even properly understand.
Yes, I have the actual generation of the certificate automated and I should be able to automate checks of remaining lifetime and actual certificate installation now that I've gathered some info about using openssl to check such things. (The locally-installed docs faithfully follow the age-old Unix tradition of being useful if you already know everything about the program and just need a reminder.)
Re. thread topic: I have a certificate renewal period which I'm… approximately happy with. I'm not convinced about two-monthly renewal, and I'd definitely set quarterly if the certificate lifetime adequately covered that. (Which could be why it's set to a little short of your typical common or garden three-month period.)
Full automation – yes, would be nice, but it does look like that'll have to wait.
I'll just set them down, net properly attached, next to and facing this conveniently large wall. Is that okay?
Enough with the weasel words. What are you using? Why is it a big secret? The only reason I can think of for hiding what you're using is so you can continue the charade of how much work LE is.
The official LE client has a plugin for Apache but I didn't have to use it to have a functioning automated system.
There are plenty of people in this forum asking honest questions about how to use LE (e.g. "This is my situation, what are my options?"), but you're intentionally obfuscating and dodging direct questions.
You didn't even acknowledge my suggestion of starting your regular copy 'n paste with a manual renewal. If you've got your heart so set on doing things manually, what's the problem with one extra step? (Though I think it's ridiculous that you can't simply use a client that checks weekly whether renewal is required.) Or failing that, write a script that renews every calendar month and enters the cert for you.
Nobody can help you if you intentionally choose to hide important details of your scenario. I have no idea what you think you're gaining by contributing noise a forum where you have no desire for a solution.
People are providing you answers and suggestions, but no! Here's another detail I just made up forgot to mention earlier!
2 words: Embedded devices (think firewalls, routers etc). One of my biggest potential use cases is for Cisco ASA firewalls for SSL VPN/administration. Not trivial to automate, but at least with 1 year renewal, manual provisioning would be tolerable. With 90 days, forget it.
I don't think they really fall within the scope of LE's key goals, at least not at this early stage. I don't think it's unreasonable for a commercial product to use a better suited commercial service. It is not a part of LE's goals to be everything to everyone.
Let's Encrypt's primary goal is to provide a free certificate to anyone that owns a domain. In the case of embedded devices, who owns the domain? Is it the responsibility of the vendor, or the purchaser? How do current embedded devices renew their certs after a year? Do they renew their certs at all?
I don't see this as being a con, especially since having a one year certificate wouldn't solve the problem. (e.g. How long did that device sit on the shelf before being sold?) Any embedded system that can renew one year certs can renew 90 day certs. (Especially given LE's second goal, automation.)
They weren't. But they still afforded My1 vastly more respect than his posts deserved.
A slight correction: Note that we said "the Web," not everything. We definitely do care about the many many other protocols (like VPNs) that use X.509 certificates, but our main focus at the moment is on the public Web, and our strategic decisions will reflect that.
To further clarify jsha's correction, "the web" really really really shouldn't include your home router or firewall. External/internet access to your router and firewall settings should be off by default, and only switched on in very specific circumstances. Unfettered internet access to your home router and firewall configuration pages is a great way of getting yourself cracked. As a commercial product, it is not unreasonable to have the vendor provide the solution, and not expect the end user to roll their own.
If we're talking about a work router or firewall, again, this function should either be provided by the vendor for small businesses or managed by the head of IT for larger ones.
If, however, you are building up your own router, then you should be considering the updating and renewal mechanism at the design stage. It wouldn't be hard to automate renewal on such a system.
And yes, automation should be a means to an end, not the end itself, and I think it's pretty obvious from the responses the LE team is giving that this is the case. Especially given how much the LE service and the client has improved over the last few months. (And it continues to develop to address valid limitations and issues raised.)
I'm automating certificate renewal on my home server (which is a brilliant way to encrypt the web), but I spent the time to do the initial configuring myself. That's not a bad situation, given that LE was in beta and the client was still v0.3. The service is now out of beta and the client has significantly developed since I first used it in "production" - you shouldn't frame the situation as if nothing has changed since the closed pilot last year.
Of course you can. You, the system administrator, just has to put forth some modicum of effort to enable it. Managing a web host was never billed as being easy, but you're constantly whining that it should be 100% turnkey, and that it's completely useless if it isn't. They might as well fire you and install an automated system if that's what you expect *nix administration to be. Because once LE and ACME become mainstream, that's exactly what'll happen to anyone who claims basic TLS is hard or lets a cert expire.
You don't have to automate everything. As I said (and you didn't respond to), Let's Encrypt is making it easy for as many people as possible to encrypt their sites. The fact that every single situation isn't accounted for isn't Let's Encrypt's problem.
How about we frame the situation like this - Can Let's Encrypt be automated for you? If not, why not? Please present your situation to us and explain why it can't be automated.
If it can be automated for you, and that automation can be demonstrated, please stop posting noise to the forum.
My sites are hosted on Bluehost. But the LE client cannot be used on Bluehost since they use CentOS Linux. Fortunately an LE certificate can be obtained via https://gethttpsforfree.com/ and used on Bluehost. I have gone through that process and am waiting for the Bluehost techs to finish manually installing my multi-domain certificate.
But if I will need to manually renew my certificate then I would much prefer to only have to do that once per year instead of 4 times/year.
And of course Bluehost is one of the larger hosts.
Bluehost do use cpanel as a control panel for many accounts, which currently doesn't support Let'e Encrypt. That is being worked on though, so I suspect there will be a way that Bluehost can easily then incorporate that with no difficulty.
Agreed. There is an argument though that if it was only once per year, then there would be no incentive for companies like cpanel / Bluehost to incorporate automation and Let's Encrypt. With it being 4 times / year there is an incentive and some pressure to find a way to automate it ( and hence a method is being worked on via cpanel )
Sure. Are you saying that automatic issuance and renewal aren't possible with IIS? Because the developer of letsencrypt-win-simple would appear to disagree with you.
When an attacker compromises a certificate's private key, they may bypass revocation checks42 and use that certificate until it expires. Shorter lifetimes decrease the compromise window in situations like Heartbleed16.
Howmany private keys are reported stolen so far? LE wants everyone suffer for 0.000000000000000000000000000000000000000000001% keystolen incident ? who created the private key is solely responsible for this
Offering free certificates with a shorter lifetime provides
encouragement for operators to automate issuance. Automated issuance
decreases accidental expiration, which in turn may reduce
warning-blindness in end-users.
no it gives only headache and tension, webmasters don't want their site visitors see site not secure warning because of ssl expiry.
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.
so literally LE wants every website visitors see site not secure warning after 90 days? if its a capacity problem how other ssl authority offering ssl certicate for 1year 2 year ....5 years 10years
when, no IF the automation works, users wont get the expiry warning because the automation would have already exchanged the cert, assuming the automation works.
well it is a headache having to check the automation 6 times a year whether it works etc in my opinion.
sadly not always the maker of the key is at fault. sometimes there can be faults that can either give possible leakage of the key (heartbleed for example) or just create bad keys (in older debians there was a problem in the RNG so there were only like 65536 or so different keys per key length possible, which anyone could have generated)
5 or 10 years is something I doubt, at the very least for DV certs. iirc the baseline requirements for CAs say maximim of like 3 years or so.
short lifetimes can be annoying especially if you want to have control over the whole certificate process but there are other even free CAs that can help you with longer lifetimes. startssl does 1 year certs for free (and now even with up to 5 SAN entries)
The Baseline Requirements were changed, first to restrict all certificates to 60 months (5 years) or less, and then to restrict most certificates to 39 months or less (3 years plus 3 months grace to encourage people with paid certificates to renew by adding the months left on their old certificate onto the new one). I believe a resolution to outlaw the 5 year certificates entirely passed recently. So no, hotwap is wrong, no TLS server certificates you can use on the public Internet are now issued for “5 years 10years”
There are still a few valid certificates issued prior to the BRs coming into existence, some of those were issued with 10 year lifespans. Of course they’re 1024-bit RSA certificates with SHA-1 (at best) signatures, so they’re pretty weak which is why it was a bad idea to give them such a long lifespan.
The commercial CAs are inclined towards probably limiting all certificates to 27 months (2 years plus the 3 month grace) the way that EV certificates are now. There is not yet a ballot for that, but I could see one passing this year.
