Vault: PKI backend: Allow to set O (Organization) values in the subject field of issued certificates.

[puja108]

Currently, it seems that it is only possible to set OU (OrganizationalUnit) values in the subject field of issued certificates through the roles API route.

However, if a user wants to use the cert for authentication and authorization purposes in cases (like for example in Kubernetes), where roles can be assigned based on CN and Os only, there needs to be an option to also set O values.

From looking through issues (https://github.com/hashicorp/vault/issues/388#issuecomment-147408862) it seems that using a CSR, it is possible to get the full DN set in the CSR into the cert's subject field, but that feels a bit cumbersome, just for adding O values to the cert.

[jefferai]

This is already implemented in master! :-)

[chetanagrawal]

@puja108 - Can you please help, how can I create CSR using Vault to have full DN?

I am referring to this blog http://cuddletech.com/?p=959 for PKI certificate generation but not able to get required DN in final server certificate. It seems only O, OU and CN are supported.

[puja108]

Not sure how to use Vault with CSRs, we use the issue route of the API and in combination with roles on a PKI backend. However, we also only use CN and O, nothing else, full DN might need CSR, but I have no experience with that.

[thertweck]

@jefferai Is it somehow possible to set O and OU for root and intermediate certificates as well?

[jefferai]

@thertweck it isn't currently, although it'd be a pretty easy PR if someone wants to tackle it.

[macgahe]

@jefferai has the PR been requested? It will be beneficial to have this, I am setting in my CSRs' subject when they are created the following attributes

-emailAddress
-OU

So my CSR looks like the following

Gabriels-MBP:~ gabo$ openssl req -noout -subject -in GABRIEL.company.dev.csr
subject=/C=NZ/emailAddress=gabriel.[email protected]/ST=Wellington/L=Wellington/O=My Company/OU=IT Infrastructure Department/CN=GABRIEL.company.dev

The idea is to use vault PKI backend to sign the certificates, then have a job in jenkins running regularly checking the certificate expiration date, so when the certificate is about to expire I can read the certificates issued by a specific role, extract the emailaddress from the subject and use that email to notify the user the certificate is about to expire or even better, issue a new certificate automatically

At the moment when I sign the CSR, even though the CSR subject has those attributes included, because the same attributes can't be defined in the role in vault, they are removed..

Gabriels-MBP:~ gabo$ openssl x509 -noout -subject -in gabriel.email.cer
subject= /C=NZ/O=My Company/CN=GABRIEL.anz.dev

Is this something doable? any chance to have this feature? cheers

[macgahe]

Sorry, I forgot to mention I tried the endpoint sign-verbatim but still the email was now showing up.. I know in the subject are multiple fields that can be added.. what are the chances to allow vault to include them all. I tried quoting the @, escaping it with "\", but none of those things worked...

Here is my CSR and the signed cert by VAULT

Gabriels-MBP:~ gabo$ openssl req -noout -subject -in GABRIEL.anz.dev.csr
subject=/C=NZ/emailAddress=gabriel.buenader'@'example.com/ST=Wellington/L=Wellington/O=My Company/OU=IT Infrastructure Delivery/CN=GABRIEL.anz.dev

Gabriels-MBP:~ gabo$ openssl x509 -noout -subject -in GABRIEL.SIGN-VERBATIM.cer
subject= /C=NZ/ST=Wellington/L=Wellington/O=My Company/OU=IT Infrastructure Delivery/CN=GABRIEL.anz.dev

[jefferai]

@macgahe emailAddress is not a standard PKIX subject attribute and I think there is a (trivial) bug preventing this value from being copied over when using sign-verbatim. I'll fix this, but I also encourage you to use email SANs instead as those are purpose-built for email addresses.

[macgahe]

Thanks @jefferai I reckon I need to read a bit more the RFCs in regards this standards.. I do appreciate you pointed it out.. I reckon i have a pretty good idea how to enforce how to sort out my use case above.. I know many people still uses in their Subject , the email address instead of adding this info in the SAN...

You are free to do this if it is not too much of a hassle, but with your direction I know how to address my use case..

Cheers mate, much appreciated!!!

[jefferai]

@macgahe Fixed in #5245

[macgahe]

thanks heaps!!! @jefferai