If I want a client certificate, it sounds like that won't be available any longer from LetsEncrypt
> These new intermediates do not contain the “TLS Client Authentication” Extended Key Usage due to an upcoming root program requirement. We have previously announced our plans to end TLS Client Authentication starting in February 2026, which will coincide with the switch to the Generation Y hierarchy.
So we use this to authenticate based on our fixed-IP/PTR/DNS to connect server to server to a 3rd party.
If we don't have the Client Authentication bit set, then the cert will be invalid for outgoing connections.
So, you will need a CA that are trusted by all parties involved, and one that is not tied to the Web PKI ecosystem.
One option is to build your own PKI with it’s own root certificate, and then tell all involved parties to import that into their root cert stores.
That’s a lot of work though. If you want to, I think you can buy “private-PKI-as-a-service” from companies like Digicert and Sectigo. And probably from AWS/Google/Azure too.
I don’t know the specifics of your environment but it might also be possible to do encryption and signature verification above the transport layer. I.e. sign (and possibly encrypt) the payload itself. Then you might not need mTLS for the connection itself.
Yeah, we've gone down the private CA PKI route, trouble is that you need to start managing your roots and your CA/RA properly, it needs to be auditable etc etc.
Cost of a Private CA on AWS is $400/month for a CA that issues certs more than 7 days in duration. That's for one signing CA. If you want PKI with a root, intermediates, and leaves, then the root has to issue intermediates every 7 days as well, or you have your root signing the leaves.
On top of that is the infrastructure of the RA, because if you want to automatically issue certs (eg to devices in the field), you need to implement ACME, but you can't necessarily use DNS methods for verification.
So you have to roll your own, from a Secure Element that contains a base key that gets diversified by the device's own ID, so it can sign a CSR or an internal DNS server that adds an TXT record for the dns-01 challenge.
Then you need the human processes of building the RA, authorizations, ceremonies, etc etc.
> These new intermediates do not contain the “TLS Client Authentication” Extended Key Usage due to an upcoming root program requirement. We have previously announced our plans to end TLS Client Authentication starting in February 2026, which will coincide with the switch to the Generation Y hierarchy.
So we use this to authenticate based on our fixed-IP/PTR/DNS to connect server to server to a 3rd party.
If we don't have the Client Authentication bit set, then the cert will be invalid for outgoing connections.
What do we use instead?