I'm inquiring about technical details of HTTP verification, as part of a prospective use case at Block, Inc.
We are a large company and have many teams that build services using internal tools and infrastructure. We have a small number of external facing domains, and when an internal service needs to receive HTTP traffic from the open internet, there is tooling available to map a specific segment beyond one of these domains to a specific internal service. For example,
internal.cash.app/route1/... would be forwarded to one internal web service, and internal.cash.app/route2/... would be forwarded to a separate internal web service
If we attempted to pass HTTP validation for internal.cash.app, my understanding is we would have to accept requests at internal.cash.app/.well-known/..., and there is no way to configure these requests to instead be directed to e.g. internal.cash.app/our-route/.well-known. Is that correct? Is there anything that can be done to use Let's Encrypt in this scenario, short of creating and maintaining an entirely new domain for this purpose?
Generally, you'd have certificate validation and installation set up on whatever "routing" http server is sitting in front handling all those requests and forwarding them to the internal services. The internal services wouldn't be trying to do validation themselves, and even if they did what would they be able to do with the certificate if they're not what's handling the incoming traffic?
Our goal is to use the issued certificates for mTLS authentication for outbound API (HTTP) requests. So we need to accept inbound requests for certificate issuance/renewal, but we wouldn't necessarily be using them for authentication of inbound traffic. Does that make sense?
You're probably best off using a private CA for that kind of use case. You might be able to cobble something together using Let's Encrypt (through DNS authentication, or having your incoming router understand what validation requests are in progress and route traffic accordingly, or the like), but Let's Encrypt is trying to get out of the business of having Client Authentication enabled on their certificates (partly because Chrome is pushing for such certificates to be issued by separate roots). For internal-use services to authenticate to other internal systems, a private PKI will probably suit your needs better than the public Web PKI anyway.
Note that support for using Let's Encrypt certificates as client certs is going to end sometime next year, per updates to Google Chrome's program. You don't want to do this.
I'm happy to have a conversation if you're interested in more - I previously built most of Block's mTLS infrastructure before joining Let's Encrypt
Thanks for the heads up. To be clear, this client authentication use case would be for authentication with a third party, rather than authentication between internal systems. But regardless, it definitely sounds like Let's Encrypt isn't the way for us to go if client authentication in general is being phased out.
Yeah, you'd need to see what CAs the third party that you're connecting to is expecting to use. Usually it'd be something from their own private CA. There are cases where they support many publicly trusted CAs, but that's not really common, and will likely need to evolve as the public PKI continues to change.
