What is the problem with long lived certs? Is the cryptography behind PKI considered weak nowadays, that you can collect enough material on cert that you can derive privkey? Is there other fundamental cryptographic weakness?
I understand problem of still-valid certs after domain expiration, but mere rotation strikes me as similar to password rotation ... which is currently discouraged.
The main issue is lack of a working revocation mechanism.
Servers get compromised sometimes, people do stupid things with keys, etc.
We dont have a really good way of revoking keys after something bad happens. We have some bad ways, but they kind of suck.
An additional reason might be making it easier to punish a misbehabing CA (CAs are often too big to fail, you cant ban them without breaking half the internet)
No kidding. Where I use to work, certs are a nightmare.
For example, some sites were closed and we asked the site owner to revoke their cert. We got "What does that mean ?", they had lost their private key.
Also other departments had certs that expired, they had no idea what to do. I left over a year ago, and someone who knows more about certs that I do left not long afterwards. I know many certs are due expire soon, good luck to them.
The point of this is I can see 45 day certs being a huge issue for that company. When I left they were looking into non-expiring certs. I have no idea what they ended up doing.
Well with ACME theory is that certs should renew automatically so no one should cate.
But to set it all up in F500 size company, that is totally different discussion and not only TLS certs but all kind of other cert auth that happens there.
Others have answered on one level. I want to answer on another.
A few older crypto mechanisms were designed around trusting one thing totally. For example, everything's secure until the end of time provided that the user keeps a private key totally private at all times, with no interruption, ever, and if the user lapses then the overall mechanism breaks really badly.
They were complicated mechanisms held together by a screw made of a metal which was assumed to be infinitely strong.
The current fashion is to trust thing in a more limited way, and to design systems such that they won't blow up spectactularly if something breaks. Being able to revoke keys is part of that, it is a weakness that helps to avoid a really bad weakness.
> If the key is 'revokable' that is a weakness in it self.
Ish. The threat of that is part of a different risk model, and probably less serious.
A long-lived certificate that ends up being able to be used by a malicious party (perhaps due to a leak of the private key) could be serious for many users if the certificate can't be reliably revoked, which they currently can't be.
A mistaken or malicious revocation if someone were to manage that could be an issue to the service operator (users can't get in) but this is a safer failure than users connecting to a malicious shadow service due, for example, to an accidentally exposed private key and a DNS poisoning attack.
As others have mentioned: if revocation worked better currently, this would be less of an issue.
A mistaken revocation is orders of magnitude less harmful then a failure to revoke. If revocation worked pretty reliably, that would be an improvement over the status quo.
I'd read it primarily as censorship risk. If a CA is under a government that wants your website taken down, they can just lean on the CA to stop renewing any certificates for it, as opposed to futzing around with ISPs or DNS providers that can only have a local impact. Or alternatively, the CAs in the future might directly use their monopoly to decide who's good and evil (especially on "integrity of the network" grounds against those judged to be spammers et al.).
At least perceived censorship risk is why the archive.is guy always uses HTTP links and not HTTPS links for his site, iirc.
I'd classify that as very low risk. If a CA's business is compromised by a government, then it's pretty easy to just switch to using a different CA, preferably in a different jurisdiction to work around the censorship.
I don't really get the argument behind using HTTP links to avoid the censorship risk with HTTPS - just provide both and get the best of both worlds. Also, using HTTP is far more prone to being interfered with in transit - I recall BT (or their ISP business department) trialling that and injecting adverts into HTTP pages. I can't recall any instance of HTTPS being censored by restricting certificates.
FWIW, a slight clarification here would be that the majority of TLS certificates are issued by CAs in the US, but the majority of CAs are not headquartered in the US.
Whilst that could be a problem, there are some CAs that aren't based in the US. I consider it a low risk issue as I haven't heard of it happening. It'd be more likely for your IP to be cut off rather than attempting to deny an SSL cert.
As you say though, the risk of revocation is low, since anyone who wants to do that can just fail to renew (renewing and revoking are different operations).
I guess it decreases the lead time of censorship. That seems pretty minor though.
* Certs come with secrets. Long-lived secrets are riskier than short-lived ones because of window of opportunity if they're compromised in an undetected way.
* Less frequent cert rotations mean that the rotation process is inherently riskier. The old adage of "request a 2-year cert, and you're scheduling an outage 2 years from now" has a lot of truth to it. More frequent rotations increases the incentive to automate, which reduces the service risk.
Your second point is crucial in my opinion. In most organisations, there'll be a rush to get some new web service configured and an overworked admin is likely to set up the initial certificate. Without a short expiry date, you can almost guarantee that the admin hasn't got around to monitoring, automating or documenting the process and might not even still be working there in 2 years time.
That's a problem for the company, not the security of the Internet. Why do the PKI people take it upon themselves to increase the problems for these companies in order to force them to automate processes?
Reduced certificate expirations also enhances the security of the internet as it reduces the window of opportunity for nefarious uses. It could possibly reduce their number of support calls from someone who's taken over from a previous admin and is now faced with an undocumented manual process to replace certs in a hurry as their website has an expired cert.
Personally, I don't see the problem with short expiry dates, though less than a month would be too short in my opinion.
A window of opportunity of 45 days is not significantly different from one of 90 or 365 days. If it's the only protection you have from a leaked private key, then a while lot of people are gonna get MITMed.
But the argument I was replying to was saying that the main advantage of short expiration times is that it encourages companies to automate the process, which reduces the chance that the certificate is accidentally allowed to expire. This is not a security issue for anyone, least of all people using browsers.
Plus, this concept that short expiration times increase security is suspect at best. If the private key leaked, 45 days is far too long, you'd need to reduce this to hours to actually help as a revocation strategy. And even then, chances are that the new key will leak as well right away, as it's most likely that the key was stolen by some undetected malware. And if the key didn't leak, a two year old cert is just as secure as a two minute old one.
> This is not a security issue for anyone, least of all people using browsers.
I disagree. The smooth running and ease of automation of TLS certs benefits the entire ecosystem, including the end-users. Remember when the only sites that had TLS certs were the ones that could afford it?
> If the private key leaked, 45 days is far too long, you'd need to reduce this to hours to actually help as a revocation strategy.
This is a good example of the Nirvana Fallacy.
> And even then, chances are that the new key will leak as well right away, as it's most likely that the key was stolen by some undetected malware.
No certificate expiry control can protect against continuous, undetectable data exfiltration. Meanwhile, a one-time access that grants me the ability to impersonate you for 2 years is a significantly worse situation than one that only grants me that ability for a few weeks.
Privilege escalation and Dev Ops rot. Long-lived certs often get compromised when privilege escalations happen and someone gets access to an account or computer that has private keys on it.
One example scenario for privilege escalation: let's say a hacker gets access to one of your employee's or vendor's machines and associated accounts using a zero-day, or phishing, or some other method that goes undetected for some time. The attacker, as part of this attack, successfully gets access to your cert's private keys through some way or another without drawing attention to themselves.
Some time later, your firm makes several security updates. When doing this, you unknowingly patched the attacker out of your network. The attacker is now in a race against time if they want to do something with the cert before it expires, and in this kind of situation, the sooner that cert expires, the better, because the attacker gets less time to do something with it. In a perfect world, the cert expired exactly when they got patched out, but because we're not guaranteed to know if there's an attacker in the first place, "keeping the expiration time as short as is reasonably possible without impacting service reliability" is what things seem to be moving towards, to limit the blast radius during access leaks.
As for Dev Ops rot, speed has a tendency to change requirements in favor of automation. Generally, certificate rotations tend to be a pain point - they break management panes, they take down websites, they throw browser errors, they don't get updated in pipelines, and other woes happen when they expire that demand people keep track of a ton of localized knowledge and deadlines that's easy to lose or forget. However, paradoxically, the longer the time between rotations, the more painful they tend to be, because once rotations are sufficiently fast, it becomes unmanageable to do them manually: demanding speed forces people to build anti-fragile rotation systems. Making the requirement be shorter is in some sense an attempt to encode into managerial culture "you need to automate this", as a bulwark against swapping your certs out being anything besides automated or one click rotations.
I'm by no means an expert, but the difference between passwords and certs is that certs can be used without any interaction with the authority.
A leaked password will reveal itself to the authority when used. You have to connect to something to use it and when doing so, can be flagged.
A long lived certificate and key can be used with no interaction with the authority, so how do you know that it is being used maliciously? The renewal is the interaction with the authority which could pick up malicious activity, so making it more regular is beneficial.
100 year certs require a consultant when the 100 years are up on any certificate and no one has any idea how the system was set up. They require a consultant when there's a security breach and you have to figure out which of the many certs you have ever used is compromised, or let the attackers in.
The hope is that 45 day certs don't require consultants because if you don't set it right you'll find it right away... and of course the risk of leak is much lesser.
It's very easy to use free certificates (e.g. LetsEncrypt) that can use a free script to automate the renewal of them. There's also plenty of free guides on how to use them for various web servers etc. That comes to a grand total of nothing.
If you'd rather pay someone else to do it for you, then that's your own issue and not really anything to do with the length of certificate validity.
This, combined with your other responses to this thread, makes it very apparent that you’re more interested in asserting your ignorant view rather than actually learning anything. Please don’t bother commenting.
TLS cert prices have crashed to…in most cases, $0, as average certificate validity times have shortened. If there’s any cost relationship at all, it’s the exact opposite of what you’re implying.
If re-signing adds material complexity to your architecture (including the ‘hidden complexity’ of a dev / ops person needing to remember to manually renew a cert every two years) then frankly it sounds like you’ve got larger problems on your hands.
We've banned this account for repeatedly breaking the site guidelines. Please don't create accounts to break HN's rules with. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
It's particularly bad to do this when you're knowledgeable and (let's assume) correct on a topic, because then the bad parts of your comment (such as personal attacks) end up discrediting the truth. That doesn't help anyone. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
>but mere rotation strikes me as similar to password rotation ... which is currently discouraged.
Cargo culting strikes again. Forcing password rotation is bad because it causes people to choose passwords with a given pattern (eg. password1, password2, etc.), which defeats any security benefit. Rotating certificates have no such issue, because the key is (presumably) randomly generated.
You can also set your password to "password" but hopefully you don't. Guidelines and technical measures can't keep everybody safe all the time, if they are determined to be unsafe, but that is never an argument against them.
Don't you have to go out of your way to do that? You can probably choose a weak RSA key as well (ie. one that's 4096 bits but not a prime), but if you have to go out of your way to do that there's little anyone can do to stop you.
Does it terminate existing connections and re-handshake when renewing the cert then? Or does it potentially hold many keys in memory for existing sessions? IIRC a TLS session can potentially last for a long time and 0-RTT depends on it being the same key, right? Couldn't find any answers in the docs: https://caddyserver.com/docs/caddyfile/directives/tls#reuse_...
The renewal of the key does not affect existing connections/sessions because they (the sessions) don't use the key directly. The private key is only used in the beginning to agree on the symmetric key, then the symmetric key is used from there onwards.
I think it’s the same mentality as “change all your passwords every 6 months”, just a useful principle “change your password if you think you need to” because a ridiculous rule of thumb and hammer slap everything is a nail. A reasonable rule like “update your cert at least once a year” becomes “by extension wouldn’t updating your cert once a month better?”
What happened to personal freedom of letting people choose for themselves how long a certificate should last? Not really liking this trend of large companies making decisions for others and then forcing them on everyone.
I'm not sure how you think certificates work? It's not for 'yourself' - the certificate is an assertion to billions of users worldwide, called relying parties. If you don't care about those, then you can use a private CA. If you do care (and want anyone's browser to work) then it's not a 'personal freedom'.
A lot of CAs are non-american. Also not sure how encrypted HTTP and DNS allows google to snoop on your traffic? If you don't trust google then don't use their eDNS service?
Also in this case, "safety" can be defined as protecting American companies from lawsuits while ensuring they continue to make lots of money from extorting SSL certificate sales.
>while ensuring they continue to make lots of money from extorting SSL certificate sales.
Which IaaS/PaaS providers are doing this? Most of the popular ones I know (ie. not some shady shared hosting reseller using whmcs solutions) lets you upload whatever certificate you want, or has certificates for free/included in the monthly price. In other words they're not going to benefit from shorter lived certificates. In the worst case you can set up cloudflare "flexible SSL" in front of your site and get it for free.
I find it interesting that all of the arguments seem to be about the merits of whether pushing this on everyone is good or not, and they all take for granted that personal freedom does not matter anymore.
I dislike not being able to choose my SSL lifetime for the same reason I do not like a web browser deciding for me if I can use my own CA. In both cases choices are being made for me, whether I like them or not.
And making ourselves completely dependent on those certificate authorities handing out certs. Dystopian, a couple of mega corps deciding who gets a cert and who doesn't.
My site is http-only because I prefer to not be dependent on those certificate authorities handing out certs, because it's been that way for 25 years, because there is zero confidential data on it, and because the issues concerning snooping and ad insertion by intermediates is not a real threat to my limited readership.
However, there is the https-only movement to prevent web browsers from viewing my website, because it it not https and therefore not 'safe'.
This movement overlaps pretty well with the people who don't accept other different certificate authorities.
> However, there is the https-only movement to prevent web browsers from viewing my website, because it it not https and therefore not 'safe'.
Like i said, nothing is stopping you from doing whatever you want other than the fact that other people might not like it, and might choose to treat your website differently. Just like you can choose not to use https, other people can choose not to like sites that don't use https. Freedom goes both ways.
The point is that if the browsers make it hard enough to actually use HTTP sites then it doesn't really matter if the user is OK with that. Same with self-signed certificates or private CAs.
Certificates are particularly painful because it sometimes seems that every program that needs them has its own way to find them. I can't just install in one OS-wide store and say that it should work just like the certificates from the major certificate authorities.
No, I have to install it in Chrome and Firefox. Oh and I've got some Python scripts and some Perl scripts and some PHP scripts that need it, so I've got to put it where they want. And let's not forget curl and wget. And how about thing I'm running in a VM or under Docker? Or database clients.
I thought you were too dismissive with your use of "nothing is stopping you."
There is a big difference between "nothing is stopping you from starting an exercise program" and "nothing is stopping you from being the ruler of the planet" even though the construction is the same.
Sure, but we are talking about open source software you can fork and change however you like, the difficulty level is a bit in the middle. I'd put it more on the level of - if you dont like the food a resturant serves, nothing is stopping you from opening your own. Yes its hard, but certainly not impossible.
Nothing stopping you running your own CA and issuing your own certs.
Your actual problem is that the browser vendors (who decide which certs should live in the root store) have certain criteria which CAs need to meet in order to be trusted.
Why should Firefox / Chrome / etc. have to honour your desire that your arbitrary-length lifetime certs are trusted by default in their browsers? You still have the personal freedom of installing your own CA root if you like.
The networked environment of today is rapidly phasing-out anything not passing through big bulky systems (most of the time these are for-profit firms). While we wait for the moment one of them (like Let's Encrypt or Sectigo or some BS from FAANGs) will become a SPoF and mess up services anywhere, you can always roll a private CA, use SSH tunnels or SOCKS proxies.
The depends where you live, and what the government means. In some places the validity of a passport is written in a law, voted by the parliament; in other it's a operation decision by the government (e.g. the ministry of the internal affairs).
Where I live it's a law voted by the parliament.
Also TLS fingerprints and biometrical data are "hashed" data, if that's what you mean about having in common.
It's got nothing to do with what committee decides what the expiry is and how they then enforce it. The thing that certs and passports have in common is unrelated to whether the issuer is a governmental body or not.
They're both centrally revokable, attested assertions of identity, where the attestation can be validated with the attester offline.
If you try and come up with a design for any system that includes this type of assertion, you'll end up in a place where you'll probably want it to expire and need re-validation at some point. That expiry is a property of the attestation, and is therefore controlled by the person/group doing the attestation. In the case of a passport, this happens to be the government. For a cert, it's the CA.
Passport/ID document expiration dates are decided by law. Therefore it is in fact "the government." Do you think there should be a law limiting the lifetime duration of an SSL cert to 45 days?
The CAB forum is not a company (although it is made up of some) and the government does not set passport max validity lengths (they can make it shorter than 10 years, just like CAs can make certs shorter, but there is a reason no country gives out passports longer than 10 years)
This talk of automation is all well and good for systems that are permanently connected to the internet.
Let's say I've got a system on a vessel that will be at sea for two months with unreliable, or no internet connectivity. I want to allow passengers and crew to use this system with their own devices.
What do I do then? Use self signed certs, and just tell users to click through the warnings?
Mixed comments in the github issue. I can definitely see how shorter lifetimes provide better security, but I have also run into my fair share of issues caused by cert expiry. Do we have good data around the lead time between someone’s signing keys being compromised and their use in an attack? The shorter that lead time the less useful this change is.
>Do we have good data around the lead time between someone’s signing keys being compromised and their use in an attack?
Given how fast it is to set up a phishing proxy, such "lead time" is probably measured in hours rather than days. Even something like a 1 week expiry will provide security benefits.
We need more safetyism culture. We need to ban root access completely by 2030. 10-factor security for login. 256 digit OTP and you must insert a drop of blood to login.
so cool, if there was some startup to give you a full health info with that. Imagine - with your login attempt it comes a proper analysis if you are fit for purpose.
If we're going this route then maybe drop HTTPS all together, go back to port 80 and instead PGP encrypt each file with a different key and add the cool peoples public keys. This would keep malicious people and bots away from the content.
There have been proposals about shortening much further: in fact, the long-standing practice in the PKI community is that renewing certificates every 7 days is short enough that no revocation service is necessary at all. However, trying to move the entire IT industry to a 7-day renewal window is a bridge too far at this point!
Instead, I would surmise this is the first step in that process by introducing a window short enough to act as a forcing function on automating certificate issuance & renewal. It's short enough to strongly encourage leveraging automation everywhere possible, but not so short that one could argue it's impossible to do manually for things that still just can't do this automatically, of which there are still a disappointingly significant number.
Once we begin to get below 30 days, however, I suspect there will be a lot more scrutiny around the data suggesting exactly how small a window is sufficient. From a risk standpoint, if we're arguing shorter-is-better, then we should go as short as possible: someone will need to pull together the data that suggest exactly how small a window appropriately balances the various risks involved. (And then 15 others will need to argue about the validity of the data, whether the data actually suggest that, whether the data were assembled with an agenda in mind, etc., etc., etc.).
3 days is far too short. The certificate supplier could have a crucial piece of equipment or software stop working and 3 days might be too tight a timeline to get it fully resolved which then leads to lots of people having invalid certificates and the certificate supplier would be out of business shortly afterwards.
What does reducing validity actually solve? The same private key is presumably used by all certificates and CSRs - if the private key is compromised then a renewed cert doesn’t solve anything.
The only thing I can think of is domain expiry. Someone could get a certificate, sell their domain, then continue using the cert until the certificate expires.
My tinfoil hat says it's about control. Forcing people to return for another blessing from the central authority, more often. The same reason church is once a week, and not once a year.
* there is no robust revocation mechanism, so just minimizing the validity of a compromised cert is the most effective - and technically simple - tool. OCSP is not viable for myriad reasons discussed over the years. OCSP stapling is optional and browsers have to consider it such explicit (opt in) policies.
* extended lifetime means rolling certificates is a complex ceremony that means rapid response is off the table, and can take companies days if not weeks to do.
* following from that: long lived certs also breaks distrust of CAs as they (or site owners) return with “we can’t perform the task we agreed to because we’ll break our customers” (CAs often fail to understand that their primary customers are end users not site owners).
It would be OK if browsers treated self-signed certificates a little better. There are lots of contexts where a self-signed, long or non-expiring certificate makes perfect sense. But browsers and security stacks in general react as if the whole application is broken, just because they didn't see the certificate before - even when they have no evidence the certificate is malicious. SSH does it nicely, with a prompt on first use and then detecting tampering after - why has this not been adopted for TLS?
TOFU is a pretty bad trust model. Even with SSH you're supposed to validate the fingerprint with some already known trusted source. Otherwise you're just assuming that the first time you connect you aren't being MITMed.
CAs don't make this problem go away; they just shift it to a central "trusted" party. With the CA model, we're assuming that Let's Encrypt isn't being MITMed.
How does this work when a user is visiting https://bank.example for the first time? Are we supposed to let granny eat the risk of a MITM when she gets a new device? Furthermore, how is such a system supposed to work in private browsing? You either have to introduce a fingerprinting vector (by which certificates are remembered/trusted), or expose users to MITM risk every time.
I'm not proposing this for everything and high security public facing contexts can definitely do the maintenance to manage frequent certificate rotation.
I just don't want my garage door integration with my car to stop working because its certificate broke. I'd argue these privately deployed single use dedicated certificates are actually better off self-signed and issued on a TOFU basis than using public key infrastructure. It's how bluetooth and many other things work, so why on earth are browsers so bent against it.
If you want to use self-signed certificates, just load it into the relevant browsers as a trusted cert. Of course, there's issues if you want the general public to just trust a certificate that could have been generated by anyone and possibly fall for a MITM attack.
OpenSSH does it “nicely” for you maybe. I’ll maybe even accept “for most users of an SSH client”. This behaviour implemented in a browser is utterly unacceptable. The average user is orders of magnitude less technically capable.
You are not the only user of the software that you use.
Given that certificate issuance is the most vulnerable part of the process (DNS hijacking during the validation process), isn't it a bad idea to encourage renewing certificates so often?
Plus, this is yet another blow to using TLS for networks not connected to the Internet. Asking users to go through some pain of accepting a new self-signed cert every three months, which was already worse than once a year, is going to get almost untenable at 45 days. And no one is offering any realistic alternatives.
The domain verification process is indeed a weak point - but there's now the upcoming introduction of MPIC (Multi Perspective Issuance Corroboration) to help with that (essentially checking the domain challenges from multiple network perspectives to overcome the risk of BGP-hijacking and similar attacks).
Also, if there's a non-internet connected network or device that uses TLS, it shouldn't be using public/webPKI certificates. Use a private CA, get the root on the managed devices that connect to it, and the problem goes away. That's always been an option.
> Given that certificate issuance is the most vulnerable part of the process (DNS hijacking during the validation process), isn't it a bad idea to encourage renewing certificates so often?
If someone hijacks your domain they can get a certificate right away, no matter how long the existing certificate was valid for.
> Asking users to go through some pain of accepting a new self-signed cert every three months, which was already worse than once a year, is going to get almost untenable at 45 days.
Are you experiencing the former right now? I thought these policies had no impact on self-signed certs at all.
>Given that certificate issuance is the most vulnerable part of the process (DNS hijacking during the validation process), isn't it a bad idea to encourage renewing certificates so often?
I don't get it, is the domain extra susceptible to misissuance during the renewal process? If not, I don't see how this is a relevant point.
Apparently this is coming from Apple, which makes sense considering their stance on security.
I still think more enforcement and standards around IoT SSL are the way to go, with shorter timelines not necessarily more beneficial.
Let's face it, whoever is renewing every 90d is going to be renewing every 45d just fine.
It's the devices and companies that use yearly expiries (and still PAY FOR CERTS!) or don't use SSL at all that are the problem.
People seem to be under the misapprehension that Let's Encrypt / ZeroSSL certificates are "free". They are not — it's that the consumer is not the one paying the bill.
It costs tens to hundreds of thousands of dollars a year just to get the audits required to operate a public CA, much less pay for the infrastructure and staffing required. That bill has to get paid somehow. Yes, pricing on certs in the past has been questionable, but operating a public CA is -not- free, so CAs have sold certificates to pay for that service operation. That has introduced some issues of its own in terms of profit motives, although I would observe that for the majority of public CAs their public TLS certificates are frequently a loss-leader service and not a massive source of income. Put short (too late!), there's nothing wrong with the practice of paying for certificates in and of itself.
What makes me very concerned about the current model funneling everyone to "free" CAs is that those bills are being paid at the moment through donations to ISRG and other organizations. I like that ISRG is making efforts to broaden their donation base to reduce reliance on single sources! However, I'd much prefer to be paying them a monthly subscription fee for their certificate service and not have my ability to leverage it be dependent on the largesse of large corporations that frequently abruptly decide services like this should either cost money or pay up in user data. (Note that I explicitly do not think the user-data thing is happening right now, only that I'm concerned it becomes a problem in the future.)
One issue with requiring some kind of fee to get SSL certificates is that it acts as a barrier to hobbyists and kids trying to set up a website (probably to learn about the technologies involved). That barrier means that there'll likely be more unsecured websites around which is not desirable.
Maybe some kind of traffic based tax would be better - just have the biggest ISPs pay for all of the free CAs.
Don't get me wrong: I don't object to the existence of non-profit/funded CAs like Let's Encrypt! The work they've been doing on making HTTPS the norm is excellent. I just worry about a future in which the only option is a CA like that, as the other public CAs struggle with offering a product that competes with "but it's free!".
I also worry a bit about the amount of the Internet that now depends on Let's Encrypt, including a number of large enterprises. That didn't go very well the last time we had an 800-pound gorilla in the CA space, not to mention the availability problems that will occur if everyone depends on a single CA that then has an outage, a mass revocation problem, or has a disagreement with the browsers over issuance rules.
Well, here in the UK, we had the BT ISP attempt to inject adverts into plain HTTP pages that their customers were requesting. HTTPS prevents that kind of abuse, so I welcome HTTPS on every single website as we can't trust big companies to not try to mess with us.
I wish there was also some sufficiently long option in use cases where security is somewhat less critical and automatic renewal is much harder. This being devices with web interfaces in local network. Which in some cases might not even have internet connectivity. Getting new cert every 45 days there is real headache...
For public internet yes, shorter is not entirely unreasonable.
For local services, you can get certificates with CAs that support DNS validation (e.g. LetsEncrypt support that). You'll likely want a DNS provider that has a suitable API so that the e.g. ACME script can post the relevant code to the DNS record, but then you're good to go. A proper public domain name that points at an internal only IP address.
The other benefit of DNS validation is that you don't need to run it on the web server itself (e.g. if it doesn't have internet connectivity), but you can have an ordinary PC/laptop request the certificate and then copy it to where it's needed.
This is largely a solved problem. On Windows https://certifytheweb.com has provided automated certificate management for the best part of a decade and we're now branching out into large scale cross-platform tools, for those interested.
I was surprised by a customer yesterday who was looking to migrate thousands of manually renewed 1 year certs, I had no idea people were still using 1 yr certs to such a broad degree.
i rather pay money and get a 1y or 2y certificate rather than use those ephemeral let's encrypt ones for free. The overhead of automatization(implementation, maintenance, support, patching, updating...) is not worth it.
Can you get a 2-year certificate now? I thought it was already gone. On the other hand, I love Let's Encrypt, especially when paired with go-acme/lego. It works flawlessly, and I don't need to worry about my certificate expiring or forgetting to renew it each year. I can always monitor my certificates too.
So instead they will sell "subscriptions" where you get a new certificate on expiry. So technically they will still sell you multiple years, but as a subscription.
Except that you'll hit an issue with the automated renewal at some point and it'll likely be when you don't have someone available to deal with it - cue several hours of downtime. A problem could occur with the cert issuer and then you've got all of their customers with hours of downtime - not really a good idea.
90 days is a good compromise between encouraging autorenewal and allowing services to be down for a couple of days without really impacting anyone. It's short enough so that the person who set up the automation is probably still employed and thus they have an incentive to fix any issues.
Until it's too short that there's not a single worked day during the alerting period, I think it's fine. 45 days means 15 days between "it didn't renew on schedule" and "anything breaks".
I understand problem of still-valid certs after domain expiration, but mere rotation strikes me as similar to password rotation ... which is currently discouraged.