Export Certificate as PKCS12/PFX Does Not Provide Passphrase Encoding.

According to PCKS #12 we should have a password to protect the private key that is exported with the cert. Currently the key vault gives you a warning during export/download that no password is used, however it doesn't provide the capability to provide a passphrase.

Strangely enough the API Manager and other Azure Resources require imported certificates to have a passphrase. This makes the two services fairly incompatible.

It would be good if Certificates exported from KeyVaults have the option to protect the private key with a passphrase as per PKCS #12

Hi,

Currently KeyVault only supports adding new secrets using ARM templates.

Certificates are common part of any service today, just like secrets, and I would like to be able to create them in my vault using my ARM templates.

Due to this limitation, currently my provisioning scripts are split to 3 parts(!):
1. ARM Template for preparation (create the KV)
2. Powershell to create the certificates inside the KV
3. ARM Template for the remaining provisioning, that in some parts rely on getting the certificate private part (by accessing the "secret" entity on the KV)

This doesn't make sense.

At the very minimum, add this support for self signed certificates, or for integrated CAs.
I can understand why for non-integrated CAs this might be more difficult to build a good UX.

Right now keyvault doesn't allow storing a certificate WITHOUT the private key in the keyvault. This is useful for a number of use-cases, eg:

• storing an internal CA public cert in the same place other internal certs are stored


• Store the public cert for trusted clients, where the private key is only on the client

The "workaround" right now is to store unsupported cert forms either in a storage account, or as secrets. Storage accounts aren't ideal b/c they are conceptually separate and are not audited in the same way; and don't support the same ability to browse or search certs. Secrets aren't ideal b/c secrets are generally more sensitive, and should have more restricted access, whereas everything stored in a keyvault "cert" is less sensitive.

Centos is not supported by vm extension Microsoft.Azure.KeyVault.KeyVaultForLinux:
https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/key-vault-linux?branch=pr-en-us-91477

Operating system
The Key Vault VM extension supports these Linux distributions:

Ubuntu-1604
Ubuntu-1804
Debian-9
Suse-15

============
Centos / Redhat is a VERY popular choice for linux servers in azure. Could we please add support for this extension to be used on centos vm's in azure?

For the record, I'm getting this error when trying to install Microsoft.Azure.KeyVault.KeyVaultForLinux-1.0.921.6 on a centos web host:

```````````````````
cli.azure.cli.core.util : Deployment failed. Correlation ID: 671c3bed-2e64-40fc-a4ed-01d13d5fd3d6. VM has reported a failure when processing extension 'KeyVaultForLinux'. Error message: "Failed to get status file [Errno 2] No such file or directory: '/var/lib/waagent/Microsoft.Azure.KeyVault.KeyVaultForLinux-1.0.921.6/status/0.status'"

More information on troubleshooting is available at https://aka.ms/vmextensionlinuxtroubleshoot
Deployment failed. Correlation ID: 671c3bed-2e64-40fc-a4ed-01d13d5fd3d6. VM has reported a failure when processing extension 'KeyVaultForLinux'. Error message: "Failed to get status file [Errno 2] No such file or directory: '/var/lib/waagent/Microsoft.Azure.KeyVault.KeyVaultForLinux-1.0.921.6/status/0.status'"

More information on troubleshooting is available at https://aka.ms/vmextensionlinuxtroubleshoot
```````````````````

Thank you for the consideration.

Extend the functionality of Key Vault Certificates to all for using as an Enterprise CA with functionality similar to Active Directory Certificate Services.

New service should integrate with the virtual network.
Should support the use of modern crypto and hashing.
Should support ECDSA Keys
Should support root CA key being in an HSM.
Should auto configure an OcSP end point.
Should warn against use of legacy crypto.
Should allow for cross-subscription connecting (need to connect my dev\test key vault to my enterprise keyvault CA.
Should integrate with KeyVault Policies to allow for RBAC.

Post Setup: Allow export of GPO for trusting the enterprise root.

I would like the ability to create a new certificate version in advance while continuing to use the current version for some time. In my scenario, I have a server application that issues digital signatures that IoT devices in the field need to verify, and the devices need the application’s public-key-containing certificate to perform this operation.

Currently, when I renew the server application’s certificate, I must distribute it to all devices at that point in a “big bang” fashion. (To be precise, the devices detect that the certificate thumbprint sent with the signatures has changed, and they get the new certificate over an HTTPS/REST call.) If I could create a “future” or “scheduled” version of the certificate (in advance), I could distribute it to the devices “gradually” (while continuing to use the current/previous version), and when I did carry out the switch, the devices would already have both the previous and the new version. This would smooth things out and eliminate the “big bang” changeover.

(To the best of my knowledge, there’s currently no way to achieve this – the moment I create a new certificate version, it automatically becomes the “new current” version – I’d love to be wrong; I could obviously create my own manual process with, say, two certificates to emulate this behavior, but it would be nice if the Key Vault supported it out of the box.)