Maximum (and minimum) certificate lifetimes?

I also disabled telemetrie. But of sample i think must be per connection.
I do not believe that are that much FQDN’s with certificate active visited by beta users.
And if it is per connection google with youtube etc and many images will be overrated.

How is your client going to update the certificate in rdp server? Or maybe in a router? If i enable rdp on my workstation, I like to use a valid certificate so i dont get this ms notification.

I think it is a little bit strange approach starting with the short periods. Is it not more logical to have the 1 year period (at least available) and then when your software is fully tested and operational, scale down this period?

1 Like

The list keeps growing and still no useful reply.

It does remind me of how Robert Mugabe single handedly destroyed the economy of Zimbabwe to the benefit of only multinational mining companies but in the name of the people. I believe he was not acting as his own man. From their behaviour we can suspect that LE has also already been compromised and it is best to find an alternate way to achieve the free (long life) certificate goal.

Just a few more use cases where automation is not ideal.

With an automated system on small sites with just one sysop after a sysop change if the automation breaks there will be little knowledge in most cases of how to recover to manually issued certs. Having the cert update application provided by the cert supplier as default is pretty much a conflict of security interests. It places two significant components into the same basket. If the app fails and takes LE down with it the syop will have to learn how to manually sign in a hurry from a new CA, he may not be up to the task

Another use case relating to IoT that adds to my previous comment of limited time deployment. Yes there may not be a need to protect my pop.up toaster but what about battery operated sensors that have expected mission profiles of a couple of years and do not have reliable or regular internet access and must rely on passing hot-spots to communicate. It seems that having a certificate that is valid for the duration (39 months battery life matches the max cert lifetimes VERY nicely in my opinion) of their mission profile would make a lot more sense. Having to pay for a long life cert on a US€5 sensor does seem a bit much though.

Also please to all those citing Google use, enough already, I have not seen a single Google person come here saying they want LE certs to be 90 days, they are not shopping for free 1 years certs so they are not the target market, start listening to the potential customers.

I thought this was a bit of a quiet thread when I commented earlier and thought, do so few care, but it seems that not everyone had thought it through and now that a lively chorus has been raised LE ignores it.

As I have written somewhere else, “Quacks like a duck?”


I’m sorry, but you’re taking it too far. Comparing Let’s Encrypt to a dictator? What would be the point of compromising a free CA, when you have tens of other CAs in your jurisdiction which you could compromise just as easily (and probably already have)? CAs which do not support things like Certificate Transparency?

There seems to be a big misunderstanding in terms of what you call “ignoring” the feedback. There’s been plenty of feedback to the points that were raised, both here and in the blog post on this topic. Their goals don’t have to align with yours to 100%, I don’t know what makes you think that should be the case.

Their goal is to push for 100% TLS deployment, with better security and better tooling. Most security experts agree that security needs automation. Most security experts agree that shorter certificate lifetimes have major benefits over long lifetimes (and that’s the reason Google keeps being brought up, not because they are the target market). That is the reason they are sticking with 90 days, not because they are somehow “compromised” (and I can’t believe someone would make that claim).

1 Like

but unlike us google essentially signs their own certs, making stuff a lot easier

The point being that they’re brought up as an example because it’s good security, not because they’re the target market.

Also, I don’t buy into there being a huge difference between having your own CA: true certificate you use to sign your webserver certificates with, or using something like Let’s Encrypt. Sure, you’re relying on a third-party dependency, but that’s about it. You will need monitoring for either solution, and manual intervention if something goes wrong. The truth is that it’s quite likely Google has some similar mechanism to ACME internally to issue certificates and protect their root (they wouldn’t get a CA: true cert from any trusted CA otherwise).

well it might be better if if automation is really the target why not just make 24 hour certs because if anything is really compromised 90 days should be more than enough and there’s stll the revocation…

also maybe it’s simpler as you think. instead of the webserver asking for a cert it might just be that a cronjob makes a new cert on the server, puts it in place and lets it restart which is far easier to make than this whole acme thing which runs with a self-updating potentially insecure/unstable client (what happens if their gitgub acc gets compromised? there’s no signature or anything that lets the user verify that the client is okay and in an automated environment no one is going to check the source of each update…

also even if 90 days might be a bit more secure I think there should be an OPTION for manual mode users to get longer certs.


Because even though it has been a stated LE desire that level of automation is only a goal and at this point nothing more than a pipe dream. Very far from reality.

@NOYB this was sarcasm, nothing more, I cant actually mean this seriously.

With the amount of nonsense on the internet I never put it passed anyone what they could actually mean seriously. Further more I don’t try. I take them at what they write. It they are joking their are emtionicons that can be used to indicate that. If they don’t use them then I have no way of know. And I’m not going to try mind reading over the internet with someone I don’t even know.

but well I am on the side for longer certs, so there’s no way I would seirously want them to make certs that are valid for a day, well the die-hard ultra-security people could maybe make it with an option but I want to be able to make longer certs in manual mode.

[quote=“My1, post:239, topic:264”]
instead of the webserver asking for a cert it might just be that a cronjob makes a new cert on the server, puts it in place and lets it restart which is far easier to make than this whole acme thing which runs with a self-updating potentially insecure/unstable client (what happens if their gitgub acc gets compromised?
[/quote] isn’t that essentially what Letsencrypt webroot authentication does and can do (regarding cronjob) ?

That’s what I am doing with my integration of Letsencrypt client (via webroot) and automating renewal every 60 days via a cronjob (that is auto generated at Nginx vhost domain creation time)

well not exactly, google doesnt need any verification and google could set an access from the “CA Server” to the webserver so the “CA server” SCPs the cert into its location and restarts the webserver via SSH which is doable in less than 20 lines.
to line it out:

CA signs cert -> access to webserver -> puts cert in place -> restart/reload webserver
these 4 steps get cron’ed and make a pretty short script which can be easily audited

while the whole acme implementation has a python script with iirc more than 10k lines and more than enough dependencies (why create a vm environment?)

while with acme you have to do a verification and you are dependent on a pretty large software with probably quite a list of dependencies (takes half an eternity to start this thing because it updates itself at every start)

not if you run ./letsencrypt as opposed to ./letsencrypt-auto command for webroot authentication

but still the Google has it’s own CA males it a lot easier since when the CA is on a server with one-directional access to the webserver to copy files and execute commands automation is quite easy and doesnt require a large-scale software as le-auto which probably has enough failure points (one of them being the compatibility)

even I might be able to write a bashscript that creates a key, CSR and sign that and push it over to a server and I have not much knowledge with bashscripts.

when DANE is a thing I might even use my raspi as CA-server…

Well in real world, you make do with what you have to work with and we are no Google in terms of man power or $$$.

It takes 7.8 seconds to run a cronjob to auto renew a Letsencrypt SSL certificate via webroot authentication - I timed it :smile:

wow, when I invoke the command in the email plus -a manual it takes MINUTES for it to start asking for sudo and again some minutes for the virtual environment ojn my raspi.

i don’t use letsencrypt-auto command for cronjob this is my webroot authentication commands in the cron file at /usr/local/nginx/conf/ssl/

/root/.local/share/letsencrypt/bin/letsencrypt -c /etc/letsencrypt/webroot.ini --user-agent centminmod-centos6-webroot --webroot-path /home/nginx/domains/ -d certonly

well for you it’s still easier, I have compatibility issues, my Win-PC with xampp aint compatible with LE, making automation useless for that one.

yeah windows not sure… maybe virtualbox or vmware linux guest OS ?