Extended Key Usage as critical extension

[lainosantos]

Is your feature request related to a problem? Please describe. There is no way to mark the Extended Key Usage as critical in Vault.

Describe the solution you'd like An option to mark Extended Key Usage as critical

Describe alternatives you've considered Now the only way is sign (verbatim) CSR. May be a checkbox in UI or a param in API.

Explain any additional use-cases In some cases, like timestamping server (https://www.ietf.org/rfc/rfc3161.txt, topic 2.3), this extesnsion should be marked as critical.

[HridoyRoy]

Hi @lainosantos . This definitely makes sense to me as an optimization. Thanks for filing the issue!

[germanrio]

I'm having the same exact issue with timestamp certificates, would be nice to be able to mark the extension as critical. Thanks.

[delfuego]

Count me in the same boat — I'd love to use Vault to manage the PKI certs for a new timestamp service we're standing up, but RFC 3161 states that the cert used for signing timestamps must have the time stamping extended key usage field marked as critical:

The corresponding certificate MUST contain only one instance of the extended key usage field extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID having value:

id-kp-timeStamping. This extension MUST be critical.

[delfuego]

For anyone who wanders by here like I did and needs to work around this, as @lainosantos mentioned in the original post, you still can have Vault sign an externally-generated CSR that has the timestamping (or any other) extended key usage attribute marked as critical.

So what worked for me was to use OpenSSL to generate a new key and CSR with the needed extensions:

openssl req \
    -newkey rsa:4096 \
    -nodes -keyout key.pem \
    -out csr.pem \
    -addext "keyUsage=critical,digitalSignature,nonRepudiation" \
    -addext "extendedKeyUsage=critical,timeStamping"

I then used the Vault HTTP API to submit that CSR to Vault to be signed; an example, using the PKI mount orgpki and role timestamping (and your own Vault access token) to issue a cert for a CSR for 365d-validity would be:

curl -X "POST" "https://your.vault.server/v1/orgpki/sign/timestamping" \
    -H 'X-Vault-Token: **********' \
    -H 'Content-Type: application/json; charset=utf-8' \
    -d $'{
        "csr": "***text of your CSR***" ,
        "ttl": "365d",
        "common_name": "Your certificate common name",
        "format": "pem"
    }'

That generated the cert I needed for my timestamp server.

[delfuego]

@ncabatoff @kitography @victorr Do y'all think there'd be any interest in there being a way to specify in a role's definition that a given EKU should be marked as critical when it issues certs? (Please forgive the direct tagging if it's unwelcome; y'all are among the most recent folks who have touched the relevant PKI API code that handles adding the EKUs to generated certs.) As it stands now, if a cert usage requires that an EKU be marked as critical — as timestamping does — then there's currently no way at all to use Vault to issue those certs, either via the UI or API or any other way.