Feature Request: PKI engine copies IP address as DNS name into SAN extension

[gnugnug]

When creating a PKI role in Vault and issuing a certificate via

vault write pki/issue/rolename common_name=10.0.0.1

Vault creates a certificate with a Subject Alternative Name extension with the value "DNS:10.0.0.1"

The created certificate is invalid, since 10.0.0.1 is not a DNS name.

Expected Behavior:
It would be more convenient if Vault would check whether common_name is an IP address and copy it as IP address:10.0.0.1 into the SAN extension.
Otherwise you have to work around this behaviour on the client side by performing the same check and in case of an IP address set exclude_cn_from_sans=true and ip_sans=10.0.0.1

[catsby]

Hello @gnugnug - thanks for writing in this feature request. I'm not yet convinced this is a good feature to add, specifically because as you mention that 10.0.0.1 is not a valid common name. I worry that adding logic to accept IP addresses for common_name and instead use that value for Subject Alternative Names (SAN) (especially when we offer an ip_sans attribute) introduces unexpected behavior to Vault.

This scenario sounds very specific to a use case you may have. Is there any other widely used case that would add support for this idea?

[gnugnug]

Thank you for your response @catsby

I believe there is a misunderstanding. I didn't write that 10.0.0.1 would be an invalid common name, in fact as far as I know the specification allows to put any kind of string into the common name field.

I'll try to explain our use case in more detail:
We issue certificates for systems via 'pki/issue/ { "common_name": "..." }'

• For systems where common_name is a DNS name (eg example.net) this works as expected. We get a certificate back with CN=example.net in the subject as well as dnsName=example.net in the Subject Alternative Names extension
• However if we request a certificate for a system with only a IP address (eg 10.0.0.1), Vault returns a certificate which cannot be used in practice, with CN=10.0.0.1 and dnsName=10.0.0.1 in the SAN extension. The CN is fine, but adding 10.0.0.1 as a dnsName to the SAN extension will not be accepted by clients.

I am not aware of a scenario where having an IP address in the dnsName field would be desirable, so I do not believe that this adds unexpected behaviour to Vault - hence my feature request that Vault should not produce such certificates.

[mju]

An IP can be a legit common name. See https://stackoverflow.com/questions/5136198/what-strings-are-allowed-in-the-common-name-attribute-in-an-x-509-certificate. The only constraint on CN is the length, which is not enforced everywhere. OpenSSL does check whether a CN is longer than 64 chars.

We also would like to be able to specify exclude_cn_from_sans on a PKI secret engine role. It makes sense to have it
when a role has "allow_any_name" already. Non domain like CN's are common for client certificates. In such a case,
things that help debugging, logging, etc. may go into CN. And those should not be copied as a DNS SAN.

It makes sense to specify exclude_cn_from_sans on a role when we know already the role is 100% for issuing
client certificates and when "allow_any_name" is true.