Open heaths opened 3 years ago
Just FYI: According to this it does seem to be respected on the request model:
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @RandalliLama, @schaabs, @jlichwa.
Author: | rickmark |
---|---|
Assignees: | heaths |
Labels: | `Client`, `KeyVault`, `Service Attention`, `customer-reported`, `feature-request` |
Milestone: | - |
Author: | heaths |
---|---|
Assignees: | fengzhou-msft |
Labels: | `KeyVault`, `Service Attention` |
Milestone: | - |
@RandalliLama for triaging
@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
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.
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?
@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.
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.
Is there any update on this ?
Feature request will go through our prioritization request on our next planning by the end of this year.
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.
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
Any update on this? Thanks.
Hi, Any update on this? Thanks.
Ping
@conblem we don't have an update
Hi is this still a thing or can we use Az or the python SDK for this now in 2024?
@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
@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 viasign
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 aCA:True
certificate as theissuer
field 1c) (Stretch) Use Azure Functions to be able to validate a CSR before issuanceExport 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.