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.
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.
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.
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.
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.
Perhaps more info can be found on the mailing list. https://mailarchive.ietf.org/arch/browse/acme/?q=draft-ietf-...