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)

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.

As far as I understand it, two problems:

* 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.

>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.

> What is the problem with long lived certs?

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 think the problem that 100 year certs don't require a complicated SaaS and consultant riddled circus as much.

It is like credit cards. The more problem the more money is to be made by middlemen.

(Currently) there is no reliable way of revoking compromised certificates.

It's because of the risk of leaked private keys being used for a long period of time.

Additionally, short renewal periods encourages automation which is more secure than a manual process.

Password rotation is discouraged because usually it means that users will create weaker passwords.

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'.

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.

You're free to not use CAs. What about their freedom? Or even not use TLS.

And what about the right for users to privacy and security, when there's no drawback on the host other than their misguided sense of "freedom"?

Anyone can create a certificate with any duration they like. Getting others to trust that certificate is the tricky bit.

These "large companies" put restrictions on what certificate authorities are allowed to do so that they can keep their users safe.

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.

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.

Same reason you cant choose the expiry on your passport or drivers license.

Why would he speak out against this? He will be able to sell much more certificates. I bet he lobbied it.

nil certificati sine lucre

>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.

> The same private key is presumably used by all certificates and CSRs

That's a choice. Certbot changes the private key with every renewal by default. I suppose in principle CAB might start disallowing key reuse.

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.

You're supposed to use a new private key for the new CSR. There is no reason to reuse the previous key.

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.

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.

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.

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.

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.

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.

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.

At that point, I feel self signed is entirely fine. Off the Internet, nobody outside of your control is trying to verify

> (and still PAY FOR CERTS!)

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.)

>Apple, which makes sense considering their stance on security.

How does it help? A lot of cert would expire prematurely and the folks will learn to accept expired cert as a norm.

For extra security I always use already expired certs.

Generate a new certificate for your connection for every round trip.

You are being downvoted, but it is a reasonable question. If you can renew every 45 days, why not every, say, 3 days?

OSCP stapling except without the oscp stapling part.

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.

At least, we’ll be super secure!

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.

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.

The overhead of automation? It's one script that can be set to run each day - exactly the kind of thing that is really easy to do with computers.

CAB rules apply to your fancy paid certs as well.