other SAN OID x.x.x.x not allowed by this role

[trinitronx]

Description

When creating a new PKI backend for use with 1 Intermediate CA (max_path_len=1) with Vault 0.11.1 as root token, and using other_sans field, the error is returned:

other SAN OID x.x.x.x not allowed by this role

It's unclear what "role" is being used when utilizing the pki/root/generate/internal API with a root token, and where the default allowed_other_sans setting can even be modified in this case.

To Reproduce
Steps to reproduce the behavior:

1. Run vault mount -path=pki_example -description="Example Root CA for bug reproduction" -max-lease-ttl=105120h pki
2. Run vault write pki_example/root/generate/internal common_name="Example Root Authority for bug reproduction" ttl=105120h key_bits=4096 key_type=rsa exclude_cn_from_sans=true max_path_length=1 ou="Zombie Emergency Response Organization" organization="Defense Communication Agency" country="US" province="Foo" locality="Bar" street_address="123 Fake Street" postal_code="12345" other_sans="1.3.6.1.4.1.52683;UTF-8:Zombie Emergency Response Organization"
3. See error:

Error writing data to pki_example/root/generate/internal: Error making API request.

URL: PUT https://vault-prod.local.efp/v1/pki_example/root/generate/internal
Code: 400. Errors:

* other SAN OID 1.3.6.1.4.1.52683 not allowed by this role

Expected behavior

A certificate should be issued under the PKI using the OID specified in other_sans

Environment:

• Vault Server Version (retrieve with vault status): 0.11.1
• Vault CLI Version (retrieve with vault version): Vault v0.11.1 ('8575f8fedcf8f5a6eb2b4701cb527b99574b5286')
• Server Operating System/Architecture: Container Linux by CoreOS 1855.4.0 (Rhyolite)

Vault server configuration file(s):

storage "consul" {
  address = "127.0.0.1:8501"
  scheme  = "https"
  path    = "vault/"
  tls_cert_file = "/vault/config/tls.crt"
  tls_key_file  = "/vault/config/tls.key"
  tls_ca_file   = "/vault/config/ca.crt"
}
ui = true
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable = 0
  tls_min_version = "tls12"
  tls_cert_file = "/vault/config/tls.crt"
  tls_key_file  = "/vault/config/tls.key"
}

disable_mlock = true

Additional context

This command would work in previous versions of Vault such as 0.9.1 without presenting the error. However, the resulting certificate was created without any additional OIDs added, as if Vault was simply ignoring them. In these older versions of Vault, it also appeared to ignore all the other fields such as ou, organization, country, province, etc...

In newer Vault 0.11.1, if we take off the other_sans field, the rest are respected without ignoring. So for example, the resulting cert for the command above would have:

Subject: C=US, ST=Foo, L=Bar/street=123 Fake Street/postalCode=12345, O=Defense Communication Agency, OU=Zombie Emergency Response Organization, CN=Example Root Authority for bug reproduction

[jefferai]

other_sans didn't exist in Vault until 0.9.4, hence why adding that parameter didn't do anything.

[trinitronx]

other_sans didn't exist in Vault until 0.9.4, hence why adding that parameter didn't do anything.

Totally makes sense as to why it was silently ignored then 😉
Thanks for such a quick bugfix! Look forward to testing it out in the new docker container version 😃