I love LE and the devs are doing a great job, and I donate every year because I feel projects like this should be well funded and have community support.
On the other hand, I would like to point out some things which are causing me a lot of work/trouble to the point where I have gone back to getting my SSLs from other providers. I know these may not have easy or elegant solutions but regardless I would appreciate if you take this into consideration please.
The 90 day renewal is difficult for me because not all my requests can be automated. For some projects I have geo-filtering set up and I have to manually disable geo-filtering, run the certobot then re-enable it. This task is burdensome and I am afraid if leading to configuration errors one day.
The challenge response comes from a several countries (this is my understanding) although my servers are in the USA. Can't this be geo-located?
Some of the challenge responses come from IP address blocks which I have block-listed (I block ISP ranges for hosting providers with badly behaving customers) and on top of geo-filtering I have to look for IP ranges sometime and unblock them.
Is there an easier way? I don't want to have to reduce my security posture in order to automate.
Hello 9pepe and thanks for the quick reply. The blocking happens at the edge of my network and using DNS challenge outside my blocking ranges also requires manual work.
I don't mind the manual work involved even in what I mentioned in the post, it's just that doing it every 90 days is a bit much, especially when multiplied by x number of servers at disparate client sites.
In 2017 NIST determined that requiring users to change their passwords every 90 days actually lowered security because it caused users to find insecure workarounds to a cumbersome policy.
90 days is great if automation works but in my case it's causing me to tinker with firewall settings constantly (increasing the chance of introducing errors) and I'm sure that I'm not the only person in this pickle.
How do you mean? The challenges are from different countries on purpose. The main validation actually comes from the US.. Some of the others don't. On purpose.
Let's Encrypt may utilise any provider for their remote validation points. I believe currently it's AWS, but this could change at any time at any moment.
And no, Let's Encrypt is NOT going to increase the 90 days lifetime. You might want to use BuyPass which offers free certs using ACME which have a double lifetime of 180 days though. That said, you should be able to automate everything anyway, so 90 days or 180 days, meh
Using acme-dns should solve your problem, but only if your authoritative dns are visible and reachable from the whole internet.
There's just no way to get a longer lasting certificate from Let's Encrypt (there may be a way from other CAs but that's not a long lasting solution given current CA/B policies and probable future ones.)
It wasn't what I was hoping to hear but thanks for the quick reply. If I find a way to make my situation work, I'll post here. Allowing traffic from random countries is not an option for us.
Realistically, you're going to have no choice eventually. The governing body for public certificate authorities is moving towards requiring multi-perspective validation which means all public CAs will eventually be required to validate challenges from multiple vantage points on the Internet likely including countries or ranges you're trying to indiscriminately block.
At the very least, your public DNS zones will need to be queryable from anywhere on the Internet for the duration of your certificate validation.
Why dont you use the free dns api from acme-dns like others have said. Just run this command in your terminal and point your acme domains to the API and you are done. You do not even have to self host it.
Note that using a third party acme-dns instance does have security implications. You put all your trust in the people that run that instance, current maintainer and future maintainers for as long as your _acme-challenge label points to it.
Hosting it yourself (which also is very easy to do) is safer.
Hello Osiris, I completely agree with you... looking at it from a security first point-of-view.
Delegating the acme-dns is not an option for me and self hosting brings us back to the original conundrum.
From your LE perspective, a multi-perspective validation and shorter renewals are better... but for me, access of least privilege is safer.
In the end I think these decisions are gonna be made by people with higher pay grades than you and me. I just wanted to post what my challenges as an SMB are... thanks for posting and for caring.. I appreciate everybody who has commented.
Automation has been a core principle of Let's Encrypt for as long as it's been around--"short cert lifetimes make it hard for me to operate manually" just isn't something they care about addressing. It was brought up repeatedly during this epic thread several years back:
You only need to allow access to the path /.well-known/acme-challenge/ using HTTP which doesn't pose any security risk, as nothing should be accessible there beside a challenge file once in a while.
Unfortunately the best I can do is reiterate what these very kind volunteers have already said: Let's Encrypt will not ever issue certificates with lifetimes longer than 90 days, we cannot turn off our secondary validation from various network perspectives around the world, and both of those (shorter lifetimes and multi-perspective validation) are coming to all other CAs in the near future.
Geoblocking traffic from certain regions of the world is not notably successful at fending off attacks; malicious actors have access to VPNs just like the rest of us. Geoblocking traffic to authoritative DNS nameservers is even less useful, as they are not generally vulnerable to the same classes or attacks as human-facing webservers. My advice is to use a CNAME to delegate your _acme_challenge. subdomain to an authoritative DNS server which serves only that zone, make that server globally-accessible, and conduct all of your validation via the dns-01 method. If that still gives you concern, then I advise looking into CAA records with the validationmethods and accounturi parameters to wholly lock down issuance.
A domain using dns-01 with a DNSSEC-signed CAA record locking issuance to that method and a single account is truly maximally secure -- cryptographically protected at every step of validation -- and doesn't require you to expose your webservers to the rest of the Internet.
To expand on the other suggestions regarding DNS domain validation, the easiest form of DNS validation is to automate your existing DNS provider but there are various reasons why that may be undesirable or impractical.
So the second approach is to delegate your _acme-challenge records to a different zone, a simple version of that would be to create a sacrificial zone just for challenge responses such as acme-auth.yourdomain.com in AWS Route 53 (for instance), then any domain/subdomain you need just has a CNAME _acme-challenge.subdomain.yourdomain.com pointing to a corresponding name in your new zone. You then instruct your ACME client to substitute the challenge response domain to be your new zone (this varies by client).
At https://certifytheweb.com we are planning a new Certify Management Hub product which offers self-hosted DNS challenge response services (either on your primary zone or a delegated zone on any DNS provider), this provides an API your ACME client can use (with minimal privileges and per-application scoped API keys) to request that an _acme-challenge record be created/updated on their behalf. You will also get optional renewal attempt monitoring for various ACME clients.
You're comparing passwords (symmetric/shared keys) to certificates (asymmetric keys).
Indeed, changing shared keys frequently is security theater, tedious, and difficult to automate. Changing them provides almost no actual benefit. So glad that dumb NIST rule was changed.
Changing asymmetric keys frequently, however, can be more easily automated (in the context of TLS servers) and limits the scope of breaches.
I think you may be missing the point of my example. The point is: sometimes we create policies with the best of intentions, and those policies have the opposite effect of what we are trying to achieve. i.e. penny wise and dollar foolish. At least NIST revisits, analyzes and is malleable, implementing change if they see it beneficiary.
BTW: NIST has not changed the rule: The passwords are still focused on length instead of complexity and frequency.
The old NIST guidelines were not really rooted in research and production experience as much as... guessing. Or what sounded good.
Shorter cert lifetimes are backed by research and decades of production experience. It's provable that a shorter cert lifetime limits the feasible exploit time of compromised keys due to robust TLS implementations everywhere, while also fixing revocation (a broken security procedure) by eliminating a need for it.
The new password guidelines look much better actually. We're getting off-topic, but:
For passwords specifically, length is the single most important factor for its strength. Complexity and frequency (do you mean change frequency or character frequency?) matter much less -- and are irrelevant if the password isn't unique. Your password could be all capital "A"s but at 9273 chars long it'll be unique and hard to guess. (EDIT: lollllll I just read last week's xkcd: xkcd: Scream Cipher)
Anyway, looks like plenty of discussion about how to help automate your case has been suggested above.
