Just curious... has anyone so far decided to extend the 3-month certificate expiration deadline? I understand that for the intended use case it makes sense, but in some cases it's an overkill and having a CA support such use case could be useful. There's nothing in the technology itself that prevents us from having certs that expire in, say, a year, right?
3 months was an excellent choice because it means you _have_ to automate so it will never expire. While the 1 and 2 year certs always end up expiring on production because someone forgot about them.
It also means you have to automate things that are tied to your certificate lifetime. Apple Pay on the web requires you authenticate your server, and it uses your certificate serial num as proof you still own the server.
This means every three months you need to re-authenticate with Apple Pay. But there is no Acme client for authenticating with Apple Pay. So instead, I was having to re-authenticate something manually every 3 months. It involved logging into an Apple Developer account, downloading a PEM file, uploading to my server and then clicking a button in the Developer Account to check the file.
After doing that dance, I happily paid for 2 year certificates from RapidSSL. Now you can only buy one year certificates. I really hope the CAB isn’t successful in making those non-conforming and requiring shorter certs.
There are plenty of other environments where certificate automation is not possible. And honestly, I haven’t seen arguments as to how on-machine automation is more secure than requiring someone be involved in the process.
While I’m dreaming about improvements to the CA ecosystem, having some way to actually prove your are the company you claim would be amazing. Instead we are actively removing support for anything that tried to provide that…
I'm not sure why you choose to see this as something that "can't be automated, so must use long-expiry certs" and not "apple fails to offer an api to perform an essential-to-automate task".
I see LE as generally trading low cost certs for expensive labor. It’s great when you have scale and need hundreds of certs.
I care more about making it easy for people to pay me than getting “free” certificates that cost me hundreds of dollars in labor costs.
Everyone talks about LE like it is perfect. I’ve just determined after using it at four different orgs that for smaller shops it tends to take more time/money to get it working than using long expiring certs deployed via an automation system.
Honestly, setting up even more automation, like you suggest Apple provide, would probably cost 5x in labor as being able to purchase 3 year certs for the next 12 years.
Automation is great when you have scale. In this case, I don’t. I tend to work at smaller companies, so I’ve never worked at an org big enough for the automation to pay off versus buying certs.
> long expiring certs deployed via an automation system
If you're already automating it why stop halfway? I don't see your point.
> setting up even more automation ... would probably cost 5x in labor [than the cost of 3 year certs over 12 years].
(0. 3 year certs are going away for operational security reasons, but lets skip that for now.)
1. Are you sure it costs more in labor to automate? Are you factoring in: a) the opportunity cost of lost sales and customer dissatisfaction when the certs expire in prod? b) the time it takes to train new employees how to change the certs [which at the average turnover rate is paid at every cert change]? c) the recurring labor of finance and operations professionals and management expensing, accounting, reporting, and reviewing this irregular cost? d) the opportunity cost of avoiding setting up new https-enabled services because it's such a huge pita for the organization?
> Automation is great when you have scale.
2. Lets decompose your scale argument into "vertical" vs "horizontal" scale that is hopefully familiar to people provisioning infrastructure. Here, "vertical scale" is one company needing many certs. I agree that if your vertical scale is low (say 10 certs) then it may not be worth it to spend 200h of labor automating it by yourself. But automation can also be scaled "horizontally": if 100 companies need it they can amortize the labor cost of creating the automation between them and have plenty of hours left over to implement it. This is the central ethos of open source and the reason why it can work at all.
The reduction from 825 days to 1 year was instituted by Apple. The same people apparently forcing you to perform a manual step every time you replace the certificate.
Some people might look at that and conclude Apple is the problem, but you apparently decided it's "the CA ecosystem".
You can get proof you "are the company you claim" from CAs today, both OV and EV support that capability, but let me guess, Apple doesn't make any use of that information and so once again rather than spot where the problem is, you'll give Apple a free pass and blame everybody else.
Edited to add: As to "actively removing support for anything that tried to provide that… " EV doesn't do what people expect it to do. Maybe Apple knows whether they want to do business with the Ohio Funky Rabbit Pizza or the West Virginia Funky Rabbit Pizza, but the customer has no clue that those are even different companies, much less which is which, so the whole "Let's show the company name in the browser" doesn't achieve what its proponents wanted, not least because of course it'll turn out the "Funky Rabbit Pizza" restaurant actually in Coolville Ohio isn't run by either company but instead by Generic Food Holdings Inc. registered in New York, so with an EV cert their legitimate web site says "Generic Food Holdings Inc." which is even more suspicious, not less.
Same issue with Okta if you want to use a custom domain. The only way to update the cert is via the web UI. It's a very frustrating oversight for a security related service...
Sure, I doubt anyone who in the history of programming has even fired up a headless browser and thought "whew, I'm glad that work is finished, never to be touched again!"
But if it's a choice between _me_ (a) remembering every 3 months (b) then opening Chrome, authenticating, recalling the 18 clicks to get to the right settings screen, copy-pasting the 3 text fields, hitting submit, then logging out, or puppeteer doing that, there's absolutely no contest which of those is the better use of the company's series-A
---
Separately, I'm not sure where this falls on the HN etiquette guide, but the word is "scraper", because a "scrapper" is someone who collects and recycles metal: https://en.wikipedia.org/wiki/Scrapper
Do you have links to documentation on the Apple Pay requirement?
That sounds like Apple Pay is encouraging certificate pinning, and I suspect the Apple Root Program may have opinions to the contrary, given how it puts Apple users at risk to encourage pinning.
Except when certbot fails (silently) for some unknown and different reason every three months, and you have to ssh in anyway to fix it. Out of all the software I run on my tiny hobby VPS (a few web sites, E-mail), certbot requires more babysitting by an order of magnitude. Even more than spamassassin, which gets wedged regularly. I'm not a professional sysadmin, so something is probably configured incorrectly, but certbot's error messages are so cryptic and non-actionable that I've never been able to solve it. So, I have a calendar reminder every three months to log in to the VPS and figure out what went wrong this time...
FWIW While your "every three months ssh to the VPS and check" approach can work, I'd commend finding a service (many free ones out there for a small project) that will notify you in a way you're happy with about certificates that are expired or soon-to-expire on your servers.
I agree certbot can be a pain the the arse, specially when combined with the fact that you need to also rely on other moving parts (like DNS updates) that can fail in weird ways too. You could try your luck with acme.sh or dehydrated though.
My previous setup had a lot of weird problems, my current one seems to be doing fine though, I still think capping the certificates to 3 months is a good idea though, well unless people start taking DNSSEC seriously and adopt DANE [1]
Lego has an option to renew a number of days prior to expiration. LE recommends 30 days. That leaves me with 4 weekly attempts to renew my certificate.
Me too, also on Debian. But there have been different installation methods over the time, certbot via deb package, installation script by piping in a URL, certbot-auto, something in /opt, lost track :D
Concerns when automating and connecting with a third-party service is that you can introduce more vulnerability. (Or even introduce a backdoor if you use a malware / insecure software to do so.)
Back before the corporate browsers took over standards via whatwg and worse, unilateral moves, you could have a TLS cert for many, many years. I often set mine for 20. But because of changes browsers have made in the name of security this is no longer possible and so shifts the insecurity to another part of the process (the complex system for automation on both client and server sides).
If they insist on keeping the three month limit I wish they'd come up with some better ways to allow you to secure your server.
If you want to use the www auth you need to allow outbound connections to any IP (they specifically won't release the range they use), otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised.
> otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised
This is true, but the machine doing DNS modifications doesn't need to be accessible to any outside initiated connections at all. So if someone has the capacity to compromise such a computer, what would stop them from compromising your desktop computer or your laptop instead?
But either way it would indeed be nice to have further limits on what the box could do. But I think LetsEncrypt does not need to change anything to make this possible.
The DNS verification works by creating a DNS TXT record named "_acme-challenge" with a TXT value on the domain you are verifying.
So really what you want is for your DNS provider to implement into their API access keys that can be restricted so that the absolutely only thing the key is allowed to do is to create, change and delete the DNS TXT record named "_acme-challenge". Perhaps some DNS providers already make this possible? But the one I am using is only able to limit it to a ZONE, but not to a specific record type and not to a specific label.
In fact I wish CloudFlare would allow such specific fine-grained permissions. But even if they did they'd probably make it part of the Enterprise plan and I am still not an Enterprise customer so.
Edit: Meanwhile that I was writing this someone else posted a sibling comment about ACME DNS alias mode, which I had not heard of. https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... That's very close to good enough. Though it would still be nice if DNS providers made it possible to issue API access tokens that are limited to specific record type and specific label.
I do the challenge verification using DNS and Route 53, and the process has permission to update the challenge record and nothing else. So what you are describing is definitely possible.
I looked into this previously and was unhappy to learn that Route53 doesn’t allow permissions based on specific records. The most granular permissions were for a full zone at the time.
> Though it would still be nice if DNS providers made it possible to issue API access tokens that are limited to specific record type and specific label.
A handy CLI utility that can be used in hook scripts that can update dozens of APIs at different DNS providers:
Yes, but what I am saying is that it’d be nice for the API access tokens issued by the DNS providers to be limited to specific record type and specific label.
For example, the access tokens that you generate for giving tools like that one access to act on your behalf, when using CloudFlare as your DNS provider.
CloudFlare at the moment does not to my knowledge offer such fine grained controls as what I am talking about, on the API access tokens.
I'm doing the same for my personal/home lab stuff. I've been using https://github.com/joohoi/acme-dns for the dns server running on a small vps for all my internal certificates and I haven't had any issues with it.
This is what I do as well. I have set up acme.sh[1] on a Raspberry Pi on my home network, which isn't accessible from the outside. It is triggered every night by a systemd timer and renews (using the DNS challenge) and deploys all expiring certificates.
> If you want to use the www auth you need to allow outbound connections to any IP
Only for the time period when you're requesting the cert though: it does not have to be open to the entire Internet 24/7. While this may not satisfy your personal / particular level of security concern, but it is something worth keeping in mind. Using the dehydrated client as an example, the web server could be started and stopped (or the host's firewall rules altered) in the startup_hook() / exit_hook() functions, or the deploy_challenge() / clean_challenge() functions:
> otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised.
Let us say you want to get a cert for foo.example.com. Letting an ACME client change the value of that could be a risk, as you state. So what you can do is (manually) create a CNAME _acme-challenge.foo.example.com, and point that elsewhere, like _acme-challenge.foo.dnsauth.example.com. You then allow the ACME client to alter (just) the TXT records of _acme-challenge.foo.dnsauth.
People have even written simple DNS server that allow for updating of records via a RESTful API, so you can server just the (e.g.) dnsauth sub-domain from it, leaving your main domain untouched (besides the initial CNAME addition):
There's also a CLI utility that can handle access the APIs of several dozen DNS companies so you don't have to roll your own if you want to server the sub-domain from your current provider:
And you don't have to use a sub-domain, but something else entirely too: instead of dnsauth.example.com you can point the CNAME to example-dnsauth.com or example.org. So if your primary DNS provider doesn't have an API, you can use another one that does. The destination CNAME does not matter as long as you control and can update it.
> Let's encrypt decided for 3 month to force users to automate and avoid the burden of too much user support.
Yeah, if this is free and you have automated the process then, really, the validity period no longer matters. 1 year, 3 months, 1 month, it's all the same for the majority of purposes.
It’s a tradeoff between comfort and security since the fact that you control a domain now doesn’t guarantee you’ll be controlling it in 5 minutes, not to mention 3 months.
This is why Let’s Encrypt gives you tools to automate the renewal process. I also recall them talking about gradually lowering the certificate lifetime so you’d have no choice but to use automatic renewal.
Certificates used to be issued with validity up to 10 years way back. There's no technical bound on the validity period AFAIK, but all major browsers will now refuse to trust certificates with validity periods > 1 year so this can be considered the practical limit.
I'm not aware of a dedicated service that offers free 1-year certs in the style of LetsEncrypt, but they'll often be available from e.g. hosting providers as part of a package. Hard to imagine a use-case where 90-day renewals aren't a better option, anyway.
The bound is basically set by the CA/Browser Forum [1] where the current baseline requirements [2] are stipulating:
"6.3.2
Certificate operational periods and key pair usage periods Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. Subscriber Certificates issued after 1 March 2018, but prior to 1 September 2020, MUST NOT have a Validity Period greater than 825 days. Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST NOT have a Validity Period greater than 39 months.
For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments."
buypass (also does acme), and uses 180 days expiration on their certs.
I've been using it for a while, but they do limit certs to 5 alternate names, instead of the 99 on LE
