LE wouldn't see this as a legitimate reason to raise rate limits, and such a request takes weeks to handle anyway.

Indeed, some rate limits don't apply for renewals but some still do.

`certbot register` followed by `certbot show_account` is how you'd do this with certbot.

Most of the time you set up mTLS by creating your own self-signed certificate and verifying that the client has that cert (or one that chains up to it). I'm wondering what systems exist that need a publicly trusted cert with clientAuth.

Only think I've heard of so far is XMPP for server-to-server auth, but there are alternative auth methods it supports.

Right, that explains it. So the use would be for things other than websites or for websites that don't need to support Chrome (and also need clientAuth)?

I guess I find it hard to wrap my head around this because I don't have experience with any applications where this plus a publicly trusted certificate makes sense. But I suppose they must exist, otherwise there would've been an effort to vote it into the BRs.

If you or someone else here knows more about these use cases, then I'd like to hear about it to better understand this.

I don't think the root programs take these kind of decisions lightly and I don't see any selfish motives they could have. They need to find a balance between not overcomplicating things for site operators and CAs (they must stay reliable) while also keeping end users secure.

A lot of CAs and site operators would love if nothing ever changed: don't disallow insecure signature/hash algorithms, 5+ year valid certs, renewals done manually, no CT, no MPIC, etc. So someone else needs to push for these improvements.

The changes the root programs push for aren't unreasonable, so I'm not really concerned about the power they have over CAs.

That doesn't mean the changes aren't painful in the short term. For example, the move to 45 day certificates is going to cause some downtime, but of course the root programs/browsers don't benefit from that. They're still doing this because they believe that in the long term it's going to make WebPKI more robust.

There's also the CA/Browser Forum where rule changes are discussed and voted on. I'm not sure how root programs decide on what to make part of their root policy vs. what to try to get voted into the baseline requirements. Perhaps in this case Chrome felt that too many CAs would vote against for self-interested reasons, but that's speculation.

On the Google search results page at the bottom there's a city name + "From your IP address" link. Clicking it shows a map with a circled region. It seems to match with what Google maps opens by default.

It's a little less accurate than Cloudflare in my case.

I have a simple Python script that runs every day and checks the certificates of multiple sites.

One time this script signaled that a cert was close to expiring even though I saw a newer cert in my browser. It turned out that I had accidentally launched another reverse proxy instance which was stuck on the old cert. Requests were randomly passed to either instance. The script helped me correct this mistake before it caused issues.

Another issue I just ran into is that a colon separated value for ExecSearchPath doesn't work in systemd-run/-p. You have to specify each path as a separate -p argument.

There are some minor annoyances like that, but it's not too hard to work around.

This can help troubleshoot issues and makes experimenting with systemd options faster.

I think there's been some talk about adding a built-in way for systemd-run to copy settings out of a .service file, but it doesn't exist yet.

I've written Perl/Python scripts to do this for me. They're not really aimed at working with arbitrary services, but it should be possible to adapt to different scenarios.

https://gist.github.com/dextercd/59a7e5e25b125d3506c78caa3dd...

There are some gotchas I ran into. For example, with RuntimeDirectory: systemd deletes the directory once the process exits, even if there's still another process running with the same RuntimeDirectory value set.

Personally, I recently acquired a certificate from HARICA which costs $55 a year if you only buy one year at a time.

Lower the lifetime of certs does mean that orgs will be better prepared to replace bad certs when they occur. That's a good thing.

More organisations will now take the time to configure ACME clients instead of trying to convince CA's that they're too special to have their certs revoked, or even start embarrassing court cases, which has only happened once as far as I know.

Theories that involve CAs, Google, Microsoft, Apple, and Mozilla having ulterior motives and not considering potential downsides of this change are silly.

Still, oppressive states or hacked ISPs can perform these attacks on small scales (e.g. individual orgs/households) and go undetected.

For a technology the whole world depends on for secure communication, we shouldn't wait until we detect instances of this happening. Taking action to make these attacks harder, more expensive, and shorter lasting is being forward thinking.

Certificate transparency and Multi-Perspective Issuance Corroboration are examples of innovations without bothering people.

Problem is, the benefits of these improvements are limited if attackers can keep using the stolen keys or misissued certificates for 5 years (plus potentially whatever the DCV reuse limit is).

Next time a DigiNotar, Debian weak keys, or heartbleed -like event happens, we'll be glad that these certs exit the ecosystem sooner rather than later.

Certify The Web has a 'Microsoft Partner' badge. If that's something your org values, then they seem worth looking into for IIS.

I can find documentation online from Microsoft where they use YARP w/ LettuceEncrypt, Caddy, and cert-manager. Clearly Microsoft is not afraid to tell customers about how to use third party solutions.

Yes, these are not fully endorsed by Microsoft, so it's much harder to get approval for. If an organisation really makes it impossible, then they deserve the consequences of that. They're going to have problems with 397 day certificates as well. That shouldn't hold the rest of the industry back. We'd still be on 5 year certs by that logic.

If an organisation ignores all those options, then I suppose they should keep doing it manually. But at the end of the day, that is a choice.

Maybe they'll reconsider now that the lifetime is going down or implement their own client if they're that scared of third party code.

Yeah, this will inconvenience some of the CA/B participant's customers. They knew that. It'll also make them and everyone else more secure. And that's what won out.

The idea that this change got voted in due to incompetence, malice, or lack of oversight from the companies represented on the CA/B forum is ridiculous to me.

CAs have now implemented MPIC. This may have thwarted some attacks, but those attackers still have valid certificates today and can request a new certificate without any domain control validation being performed in over a year.

BGP hijackings have been uncovered in the last 5 years and MPIC does make this more difficult. https://en.wikipedia.org/wiki/BGP_hijacking

New security standards should come into effect much faster. For fixes against attacks we know about today and new ones that are discovered and mitigated in the future.

This will be painful for people in the short term, but in the long term I believe it will make things more automated, more secure, and less fragile.

Browsers are the ones pushing for this change. They wouldn't do it if they thought it would cause people to see more expired certificate warnings.

> Unfortunately the CA/B is essentially unchecked power, no individual corporate member is going to fire their representatives for this, much less is there a way to remove everyone that made this incredibly harmful decision.

Representatives are not voting against the wishes/instructions of their employer.