Pros and cons of 90-day certificate lifetimes


#345

Yeah, it’s almost as if he’s being intentionally vague so he can keep moving goalposts while decrying any solution presented.

Almost :wink:


#346

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?


#347

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!

I’m trying! I really really am!


#348

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.


#349

Those words are words that, I think, do not fit into this forum. They are, the least, not polite.


#350

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.


#351

the more intresting question would be whether this can be dont practically or even automated, mostly, well not really.

let me quote this from the leaving beta blog post:

We set out to encrypt 100% of the Web.

so it literally is their goal to encrypt everything.

also let me quote this little gem:


#352

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.


#353

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.


#354

An additional problem is that not all of the major servers support automation, meaning I have to manually update certs every 90 days. Doesn’t scale.


#355

and even then you cannot automate everything.


#356

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.


#357

Which major web servers don’t support automation?


#358

:expressionless:

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.

Thanks.


#359

You’re awesome, thanks for promoting rationality :smile:


#361

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.


#362

Let’s Encrypt works perfectly well on CentOS

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 )


#363

Ever heard of Internet Information Services (IIS)?


#364

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.


#365

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