Is the TLS cert authentication method too rigid?

I’ve been doing some experiments with tls cert authentication with vault and it occurs to me that there is a capability gap in how this is implemented. Which is that you can enroll a cert and mark which roles token generated from it will get. However that requires you to know the cert in advance. It seems like it would be a real expansion of flexibility if instead of the cert you could specify a subject (and optionally signed by a specific CA so you could bucket things based on who signed/created them) instead of the specific cert. That way you could define a subject>role mapping that could persist through a client having their certificates rotated on expiry and would allow for much fewer touches.

I had presumed that there would be some capability that works as described above, but I don’t actually see any evidence of it in the documentation.

Does that make sense to anyone besides me? Would anyone be interested in a PR to add such a feature?

I don’t think the intention is that you enroll individual certs. You’re supposed to enroll a CA, and specify the name (etc) constraints that you accept for certificates signed by that CA, and that’s what Vault will then accept to authenticate to your role.

e.g. say you issue each employee with a cert from your PKI and their email address in the certificate indicates their division. You can enroll the issue CA public certificate into Vault and then set allowed_email_sans to a pattern that only matches engineering staff and map that to a particular set of policies.

ref. https://www.vaultproject.io/api/auth/cert

Well, that sounds like exactly how I want it to work, but somehow I don’t think I’d observed it to work that way. I think maybe I was holding it wrong all along, thanks.

I agree that the general documentation undersells the capability (and reinforces the notion that you’re supposed to enroll individual certificates) vs. the API documentation which is clearer.

1 Like