Request support for more dynamic mTLS client cert/csr management

What would you like to have changed?

An interface to produce/configure the mTLS client CSR, or possibly allow the existing one to ignore it altogether.

Ideally, I'd like to be able to issue a custom CSR based on the information about the server and destination backend. Bonus points for being able to decide the details of the client cert during the TLS negotiation at the CertificateRequest phase (caddy server/module, server offered CAs, configured san, etc).

Why is this feature a useful, necessary, and/or important addition to this project?

Right now when using mTLS only the common name of the certificate can be set and it must be hard-coded (even replacers aren't supported). In a TLS negotiation a server may offer support for multiple CAs (which means different possible valid client certs we might chose from) or a client may want to use different client certs depending on destination backend. In effect, the reverse of a just-in-time server cert issuance by leveraging the CertificateRequest step of the TLS negotiation.

I am implementing Vault PKI issuance support in my application, but Vault is somewhat picky about the cert request details and I'd like to be able to more fully specify the details of the request dynamically (or just use the REST api pki/issue/$thing that gives me back a pkey instead of the sign api pki/sign/$thing which uses a CSR as an input). Unfortunately, Caddy/Certmagic's interface here don't let me manipulate (or outright ignore) the internally produced CSR.

What alternatives are there, or what are you doing in the meantime to work around the lack of this feature?

If I attempt to be sneaky about it (say by making my module also a KeyIssuer and then caching the key internally in a pubkey mapping) the cache storage engine gets confused. There might be a bug there in fact if the subject in the CSR when it's being stored != the subject that's actually in the cert. It attempts to read the wrong path on disk and fails. Regardless, it's a bit of a hack to take this approach.

Please link to any relevant issues, pull requests, or other discussions.

https://ldapwiki.com/wiki/TLS%20Full%20Handshake
https://www.vaultproject.io/api-docs/secret/pki#generate-certificate-and-key
https://www.vaultproject.io/api-docs/secret/pki#sign-certificate

BTW, thank you! The caddyserevr project's extensible design is really something amazing.

No file or test entry point is named. Start by locating the existing internally produced client CSR, the KeyIssuer path, and the cache storage behavior; done would be a supported way to configure or bypass CSR details dynamically during mTLS negotiation without cache subject mismatches.