[FEATURE REQ] Add basic_constraints to KeyVault Certificates

[heaths]

@rickmark commented on Thu Dec 03 2020

Azure.Security.KeyVault.Certificates

While the rest API supports additional properties such as basic_constraints which allows a CA to be created in a Key Vault, the .NET SDK does not let these properties be set in a certificate create operation.

Where the REST endpoint may have additional options, the .NET objects should allow them to be set as a key/value dictionary to allow the feature to be used without waiting on a new client binary.

R

---

@jsquire commented on Fri Dec 04 2020

Thank you for your feedback. Tagging and routing to the team member best able to assist.

---

@heaths commented on Fri Dec 04 2020

basic_constraints seems to be returned in responses, but is not documented: https://docs.microsoft.com/rest/api/keyvault/createcertificate/createcertificate#x509certificateproperties (or in swagger from which those docs and our source comes: https://github.com/Azure/azure-rest-api-specs/blob/master/specification/keyvault/data-plane/Microsoft.KeyVault/stable/7.1/certificates.json). We do allow authoring other X509 properties.

Was there a particular property you were wanting to set?

@jlichwa @RandalliLama should users be able to specify basic_constraints for certificate creation?

---

@msftbot[bot] commented on Fri Dec 04 2020

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @RandalliLama, @schaabs, @jlichwa.

Issue Details

---

Azure.Security.KeyVault.Certificates

While the rest API supports additional properties such as basic_constraints which allows a CA to be created in a Key Vault, the .NET SDK does not let these properties be set in a certificate create operation.

Where the REST endpoint may have additional options, the .NET objects should allow them to be set as a key/value dictionary to allow the feature to be used without waiting on a new client binary.

R

Author:	rickmark
Assignees:	heaths
Labels:	Client, KeyVault, Service Attention, customer-reported, feature-request
Milestone:	-

---

@rickmark commented on Fri Dec 04 2020

Hey there (Azure Team Alumni here BTW)

So I'm building an old pattern from Secret Store called "poor man's PKI". I'm trying to 1) create a self signed root CA with a non-exportable private key directly in Azure Key Vault itself. (Will be able to do from my own code, due to the undocumented feature). Once that is there, I can use it and Bouncy Castle's ISignatureFactory to sign leaf certificates. The targeted "leaf certificates are WinRM certificates for Azure IaaS. This will require creating private keys, signing a certificate via sign on the certificate object I created, combining into a P12 and storing in a secret object for the Azure IaaS plugin to pickup. This same process could actually be used on new machines to secure RDP as well.

Breakdown of Suggestions:

Support Root/Intermediate CAs:

1. Support 1st class self-signed CAs in Azure certificate objects (CA:True) 1a) Create a new operation type called "issue" which is a sign operation while placing the resulting certificate into Key Vault for an audit trail. (Root CA would deny sign, but allow Issue to its users) 1b) Allow selecting a CA:True certificate as the issuer field 1c) (Stretch) Use Azure Functions to be able to validate a CSR before issuance

Export Certificate to PFX Secret: 2) Support the creation of an exportable private key, out of band issuing of a certificate, and direct export of PFX to a Key Vault secret object. 2a) Generate an exportable key in KV (can do today) 2b) Create a certificate object from that key via out of band or issue from CA 2c) Operation to export certificate and key into a new secret object which holds a PFX containing both. (This is what IaaS expects to be able to pick up, https://docs.microsoft.com/en-us/azure/virtual-machines/windows/winrm)

After those are complete the IaaS team could simply issue certificates directly via Key Vault. 3) IaaS selects the Key Vault certificate of the Issuing CA 3a) During IaaS placement, the key is generated on the machine 3b) The IaaS placement agent creates a compatible RDP/WinRM CSR from the key generated 3c) The IaaS resource manager gets the CSR signed by a Key Vault CA and places the certificate on the IaaS VM

Using this method, someone creating a farm of IaaS VMs only creates a Root CA in Key Vault, downloads, and places it into the local trust store. Upon VM creation there would be TLS immediately to WinRM and RDP without further configuration.

---

@rickmark commented on Fri Dec 04 2020

Argh: Another idea, went to go and derive CertificateProperties to add the additional field, and while the class is not sealed, all the members are non-virtual. When creating serializers/deserializers making the functions virtual would have allowed me to quickly add the desired behavior... I'm stuck with "rolling my own" Key Vault client to get at these settings now...

---

@heaths commented on Fri Dec 04 2020

The models are not designed to be extensible. We actually read and write to UTF8 streams without reflection using System.Text.Json.

This sounds like a service feature to which @jlichwa and @RandalliLama will need to address. Right now, the basic_constraints property isn't defined in swagger (not even in a response-only model) and using Key Vault as a PKI (for what operations you defined it would need to do, like keep an audit trail) are features the service would first have to implement.

Since the client is open source, you might consider forking it and make any adjustments you need. Could save a lot of extra coding. Just a thought in the interim.

[rickmark]

Just FYI: According to this it does seem to be respected on the request model:

https://stackoverflow.com/questions/56388628/azure-key-vault-certificate-create-basic-constraints-catrue

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @RandalliLama, @schaabs, @jlichwa.

Issue Details

---

@rickmark commented on Thu Dec 03 2020

Azure.Security.KeyVault.Certificates

While the rest API supports additional properties such as basic_constraints which allows a CA to be created in a Key Vault, the .NET SDK does not let these properties be set in a certificate create operation.

Where the REST endpoint may have additional options, the .NET objects should allow them to be set as a key/value dictionary to allow the feature to be used without waiting on a new client binary.

R

---

@jsquire commented on Fri Dec 04 2020

Thank you for your feedback. Tagging and routing to the team member best able to assist.

---

@heaths commented on Fri Dec 04 2020

basic_constraints seems to be returned in responses, but is not documented: https://docs.microsoft.com/rest/api/keyvault/createcertificate/createcertificate#x509certificateproperties (or in swagger from which those docs and our source comes: https://github.com/Azure/azure-rest-api-specs/blob/master/specification/keyvault/data-plane/Microsoft.KeyVault/stable/7.1/certificates.json). We do allow authoring other X509 properties.

Was there a particular property you were wanting to set?

@jlichwa @RandalliLama should users be able to specify basic_constraints for certificate creation?

---

@msftbot[bot] commented on Fri Dec 04 2020

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @RandalliLama, @schaabs, @jlichwa.

Issue Details

---

Azure.Security.KeyVault.Certificates

While the rest API supports additional properties such as basic_constraints which allows a CA to be created in a Key Vault, the .NET SDK does not let these properties be set in a certificate create operation.

Where the REST endpoint may have additional options, the .NET objects should allow them to be set as a key/value dictionary to allow the feature to be used without waiting on a new client binary.

R

Author:	rickmark
Assignees:	heaths
Labels:	Client, KeyVault, Service Attention, customer-reported, feature-request
Milestone:	-

---

@rickmark commented on Fri Dec 04 2020

Hey there (Azure Team Alumni here BTW)

So I'm building an old pattern from Secret Store called "poor man's PKI". I'm trying to 1) create a self signed root CA with a non-exportable private key directly in Azure Key Vault itself. (Will be able to do from my own code, due to the undocumented feature). Once that is there, I can use it and Bouncy Castle's ISignatureFactory to sign leaf certificates. The targeted "leaf certificates are WinRM certificates for Azure IaaS. This will require creating private keys, signing a certificate via sign on the certificate object I created, combining into a P12 and storing in a secret object for the Azure IaaS plugin to pickup. This same process could actually be used on new machines to secure RDP as well.

Breakdown of Suggestions:

Support Root/Intermediate CAs:

1. Support 1st class self-signed CAs in Azure certificate objects (CA:True) 1a) Create a new operation type called "issue" which is a sign operation while placing the resulting certificate into Key Vault for an audit trail. (Root CA would deny sign, but allow Issue to its users) 1b) Allow selecting a CA:True certificate as the issuer field 1c) (Stretch) Use Azure Functions to be able to validate a CSR before issuance

Export Certificate to PFX Secret: 2) Support the creation of an exportable private key, out of band issuing of a certificate, and direct export of PFX to a Key Vault secret object. 2a) Generate an exportable key in KV (can do today) 2b) Create a certificate object from that key via out of band or issue from CA 2c) Operation to export certificate and key into a new secret object which holds a PFX containing both. (This is what IaaS expects to be able to pick up, https://docs.microsoft.com/en-us/azure/virtual-machines/windows/winrm)

After those are complete the IaaS team could simply issue certificates directly via Key Vault. 3) IaaS selects the Key Vault certificate of the Issuing CA 3a) During IaaS placement, the key is generated on the machine 3b) The IaaS placement agent creates a compatible RDP/WinRM CSR from the key generated 3c) The IaaS resource manager gets the CSR signed by a Key Vault CA and places the certificate on the IaaS VM

Using this method, someone creating a farm of IaaS VMs only creates a Root CA in Key Vault, downloads, and places it into the local trust store. Upon VM creation there would be TLS immediately to WinRM and RDP without further configuration.

---

@rickmark commented on Fri Dec 04 2020

Argh: Another idea, went to go and derive CertificateProperties to add the additional field, and while the class is not sealed, all the members are non-virtual. When creating serializers/deserializers making the functions virtual would have allowed me to quickly add the desired behavior... I'm stuck with "rolling my own" Key Vault client to get at these settings now...

---

@heaths commented on Fri Dec 04 2020

The models are not designed to be extensible. We actually read and write to UTF8 streams without reflection using System.Text.Json.

This sounds like a service feature to which @jlichwa and @RandalliLama will need to address. Right now, the basic_constraints property isn't defined in swagger (not even in a response-only model) and using Key Vault as a PKI (for what operations you defined it would need to do, like keep an audit trail) are features the service would first have to implement.

Since the client is open source, you might consider forking it and make any adjustments you need. Could save a lot of extra coding. Just a thought in the interim.

Author:	heaths
Assignees:	fengzhou-msft
Labels:	KeyVault, Service Attention
Milestone:	-

[sebansal]

@RandalliLama for triaging

[sebansal]

@heaths i created this PR, can you point me to where the description need to be updated https://github.com/Azure/azure-rest-api-specs/pull/10783

[heaths]

Related to what was commented, this isn't a pure documentation issue. I mean that the basic_constraint property is not defined in swagger (ergo, not documented). This needs to be a property model definition in certificates.json and referenced by a certificate model. That PR does not resolve this issue, nor does the description belong in the example data.

[djosemartine]

Hi there, any update on this? I am trying to migrate a project which uses the legacy Vault client Library to the new one but I am no able since basic constraints and CA properties cannot be set. Any suggestion?

[stewartadam]

@djosemartine I don't believe anything has changed upstream. I've ended up extracting the certificate creation from existing tooling and az rest to manually issue a POST to create the certificate. I can provide code samples if desired.

[tringuyen-yw]

In https://github.com/Azure/azure-cli/issues/18178 there is a code example using a REST request to set Basic Constraints CA=true. Not sure why but the REST API seems to have support for setting x509v3 Basic Constraints.

[silvestia]

Is there any update on this ?

[jlichwa]

Feature request will go through our prioritization request on our next planning by the end of this year.

[rbp28668]

We need to run a mini CA to support encryption in transit. Not having the ability to set basic constraints impacts our ability to do this and is impacting our ability to deliver to multiple customers. The key to this is being able to create the root cert with the basic constraints and for the private key to never have to leave the key vault. That then enables the use of HSM.

[jlichwa]

It is not supported option today (it is not under service SLA and can change at any time without notice). We don't have any updates on it at this time

[fuyong2022]

Any update on this? Thanks.

[LuBu0505]

Hi, Any update on this? Thanks.

[conblem]

Ping

[jlichwa]

@conblem we don't have an update

[oddy]

Hi is this still a thing or can we use Az or the python SDK for this now in 2024?

[MassimoC]

@jlichwa any update? thanks