Build Key Vault certificate issuance policies with issuer, key properties, X.509 subject, SANs, and lifetime actions.
Build Key Vault certificate issuance policies with issuer, key properties, X.509 subject, SANs, and lifetime actions.
Required Fields
certificateNamevaultNameissuerParameters.namekeyProperties.keyTypekeyProperties.keySizex509CertificateProperties.subjectx509CertificateProperties.validityInMonthsOutput will appear here...Build a Key Vault certificate issuance policy defining the issuer, RSA key strength, X.509 subject/SANs, and lifetimeActions that trigger AutoRenew or EmailContacts based on either a lifetimePercentage of validity elapsed or an absolute daysBeforeExpiry countdown. keyProperties.exportable: false means the private key is generated inside Key Vault's HSM/software backing and can never be extracted in plaintext, not even by the vault owner, which is the right default for most certificates but is a one-way decision, a certificate issued as non-exportable can't later be exported if a workload outside Key Vault's supported integration surface unexpectedly needs the raw private key file.
The builder validates that certificateName, vaultName, issuerParameters.name, keyProperties.keyType, keyProperties.keySize, x509CertificateProperties.subject, and x509CertificateProperties.validityInMonths all resolve before accepting the JSON as a valid certificate policy, the fields Key Vault needs to know what kind of key and certificate to issue and from which issuer; it can't verify the named issuer is actually configured in your vault or that the requested SANs would pass domain validation with a real CA.
exportable: false is the right default for anything living entirely within Azure's Key-Vault-integrated services, but it's a one-way door, think through whether any current or future consumer might need the raw private key file before committing to non-exportable.
Always pair an AutoRenew trigger with a separate EmailContacts-based notification trigger, auto-renewal can fail silently at the issuer level, and without a human-facing backup notification, that failure isn't discovered until the certificate has already expired.
keySize 4096 versus 2048 is a real, if usually small, performance tradeoff for every TLS handshake using the certificate, don't default to 4096 everywhere without a specific compliance or long-lifetime reason, 2048-bit RSA remains broadly accepted for most workloads.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.