dextercd

This comment on the 7th of May from someone at Let's Encrypt says that implementation may be delayed until Q3 due to open issues in the specification. That might be what happened. https://community.letsencrypt.org/t/dns-persist-01-deploymen...

Perhaps more info can be found on the mailing list. https://mailarchive.ietf.org/arch/browse/acme/?q=draft-ietf-...

Apparently VeriSign plans to discontinue .name: https://itp.cdn.icann.org/en/files/consensus-policies/rsep-2...

Your comment is 100% correct, but I just want to point out that this doesn't negate the risks of bob's approach here.

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.

An account needs to be created before you can request a certificate. Some ACME clients might create the account for you implicitly when you request the first certificate, but in the background it still needs to start by registering an account.

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

This adds a new validation method that people can use if they want. The existing validation methods (https://letsencrypt.org/docs/challenge-types/) aren't going away, so your current setup will keep working.

The server that wants to authenticate clients via mTLS doesn't need the clientAuth EKU on its certificate, only the clients do.

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.

Thanks for chiming in! I remember now that you also said this on the LE community forum.

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.

All major root store programs (Chrome, Apple, Microsoft, Mozilla) have this power. They set the requirements that CAs must follow to be included in their root store, and for most CAs their certs would be useless if they aren't included in all major ones.

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.

It's a requirement from the Chrome root program. This page is probably the best resource on why they want this: https://googlechrome.github.io/chromerootprogram/moving-forw...

Interesting!

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.

2.33 km off for me. Pretty cool

You need external monitoring of certificate validity. Your ACME client might not be sending failure notifications properly (like happened to Bazel here). The client could also think everything is OK because it acquired a new cert, meanwhile the certificate isn't installed properly (e.g., not reloading a service so it keeps using the old cert).

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.

Here's the Python version I've been using: https://gist.github.com/dextercd/3bd65c1e32635b9e7bebf287b52...

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.

You can use systemd-run with --shell (or a subset of options enabled by --shell) and -p to specify service properties to run commands interactively in a similar environment as your service.

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.

A code signing certificate does not cost $500 a year. The OP links to an offering by Certum which is just $25 a year plus the cost for a reusable smart card.

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

Apple introduced this proposal. Why would they care about a CA's legal exposure?

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.

Stealing a private key or getting a CA to misissue a certificate is hard. Then actually making use of this in a MITM attack is also difficult.

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.

No idea how many are first-party or vetted by Microsoft. Probably none of them. But I really, really doubt you can only run software that ticks one of those two boxes.

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.

I learned a lot from TLS Mastery by Michael W. Lucas.

Let's Encrypt lists 10 ACME clients for Windows / IIS.

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.

If a CA or subscriber improves their security but had an undetected incident in the past, a hacker today has a 397 day cert and can reuse the domain control validation in the next 397 days, meaning they can MITM traffic for effectively 794 days.

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.

I think most orgs can get away with free ACME clients and free/cheap monitoring options.

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.

"outdated certificate data" would be domains you no longer control. (Example would be a customer no longer points a DNS record at some service provider or domains that have changed ownership).

In the case of OV/EV certificates, it could also include the organisation's legal name, country/locality, registration number, etc.

Forcing people to change passwords increases the likelihood that they pick simpler, algorithmic password so they can remember them more easily, reducing security. That's not an issue with certificates/private keys.

Shorter lifetimes on certs is a net benefit. 47 days seems like a reasonable balance between not having bad certs stick around for too long and having enough time to fix issues when you detect that automatic renewal fails.

The fact that it encourages people to prioritise implementing automated renewals is also a good thing, but I understand that it's frustrating for those with bad software/hardware vendors.

CAs and certificate consumers (browsers) voted in favour of this change. They didn't do this because they're incompetent but because they think it'll improve security.

It's really not that hard to automate renewals and monitor a system's certificate status from a different system, just in case the automation breaks and for things that require manual renewal steps.

I get that it's harder in large organisations and that not everything can be automated yet, but you still have a year before the certificate lifetime goes down to 200 days, which IMO is pretty conservative.

With a known timeline like this, customers/employees have ammunition to push their vendors/employers to invest into automation and monitoring.

NGINX detects attempts to use http for server blocks configured to handle https traffic and returns an unencrypted http error: "400 The plain HTTP request was sent to HTTPS port".

Doing anything other than disconnecting or returning an error seems like a bad idea though.

Automate it, have the ACME client send alerts if renewal fails, and also monitor the system's certificate from a different system.

By tracking the latest stable and selectively integrating changes we've been able to build libjpegturbo easily on a handful of unsupported architecture/compiler combos of the main. >We do not hate Cmake or think it's worse, just autoconf is mature and capable and 99% of the time works perfectly fine. We will maintain it as needed.

/shrug. Doesn't look like a hard fork and it's good for the folks that need it.

I don't know what issues there are with CMake and older compilers, but I trust that they are real enough to warrant this effort.

Pretty sure you don't get an email if you revoke the certificate

Not true. CA's are explicitly allowed to omit CRL support for certificates with a lifetime <= 10 days.

I'm very interested in trying this. acme.sh is planning to support certificate profiles, so hopefully that'll be ready when LE's short-lived certificates become available.

(Or I'll switch to a different ACME client I suppose)