Best Practices for Certificate Provisioning¶
Domain Registration¶
Register All Domains Before Requesting Certificates¶
The platform requires every CN and SAN in a certificate request to match a registered domain. Missing domain registrations are the most common cause of rejected requests.
Register apex domains (for example, example.com) rather than individual subdomains wherever possible — this covers all subdomains without requiring repeated registration as your service landscape grows.
Keep Domain Registrations Accurate¶
Remove domains from the registry when they are no longer in use. Stale domain registrations create unnecessary coverage that makes it harder to detect unexpected certificate issuance.
Provider Selection¶
Use Local PKI for Internal Certificates¶
For certificates on internal services that are not publicly accessible, the Built-In Local PKI provider is appropriate. It is always available, operates without external API dependencies, and keeps all cryptographic operations within the Back Control Plane.
Ensure your root and intermediate certificates use strong algorithms (ec-384 or rsa-4096) and have validity periods that allow you to rotate intermediates before they expire.
Use External CAs for Publicly Trusted Certificates¶
For certificates that must be trusted by browsers and operating systems — web servers, client-facing APIs, email — use an external CA that chains to a publicly trusted root (DigiCert, GlobalSign, or a public ACME provider such as Let's Encrypt).
Publicly trusted certificates cannot be issued by Local PKI because the Local PKI root is not in public browser trust stores.
Test External CA Integrations Before Relying on Them¶
After configuring a DigiCert, GlobalSign, or ACME provider, request a test certificate and verify the full certificate chain before putting the integration into production use. External CA API credentials can expire or be revoked — catching this early avoids production outages.
Key and Algorithm Choices¶
Prefer ECDSA for New Certificates¶
ECDSA certificates (ec-256, ec-384) are smaller, faster to process, and offer equivalent security to larger RSA keys. ec-384 is recommended as the default for new certificates where client compatibility is not a constraint.
Use RSA only where you have a specific requirement for it — for example, compatibility with legacy clients or hardware that does not support ECDSA.
Do Not Use SHA-1¶
SHA-1 is not available as a digest option on the platform, but ensure any imported or discovered certificates do not use it. Flag SHA-1 certificates using the policy engine.
Validity Periods¶
Align Validity to Browser Limits for Public Certificates¶
Publicly trusted certificates issued after September 2020 must not exceed 398 days. If you are using an external public CA, the CA will enforce this; set your validity requests to 365 days or fewer to avoid confusion.
For internal certificates signed by Local PKI, you may use longer validity periods, but shorter validity (90–365 days) reduces the risk window if a certificate is compromised.
Use Policy to Enforce Maximum Validity¶
Configure a policy with enforce_max_validity to cap validity periods for certificates covering domains in your policy scope. This prevents long-lived certificates from being issued accidentally.
Policy Configuration¶
Apply Policies to All Provisioning Pathways¶
Policies apply to both the automated request pathway and the CSR upload pathway. Define policies for your registered domains to enforce consistent subject field values, algorithm requirements, and validity limits across all certificate requests regardless of the pathway used.
Use Hard-Fail for Critical Controls¶
Use fail: hard on policy rules that represent non-negotiable controls — for example, prohibiting SHA-1, enforcing a maximum validity of 398 days, or requiring a specific organisation name. Hard-fail rules block the request entirely.
Use fail: soft for advisory rules where you want visibility without blocking — for example, flagging certificates with unusually long validity, or warning when the OU field is empty.
Review Policy Alerts Regularly¶
Hard-fail and soft-fail policy violations create CertificateAlert entries visible in CLM → Certificates → Alerts. Review these alerts regularly to identify patterns — repeated hard-fails may indicate a workflow or tooling issue that needs to be addressed upstream.
CSR Upload¶
Validate CSRs Externally Before Uploading¶
Check that the CN and SANs in a CSR match the domains you intend to certify before uploading. The platform will reject CSRs with domains that are not registered, but validating the CSR locally first avoids unnecessary round trips.
Ensure CSR Subject Fields Match Policy¶
If you have policies with enforce_values rules, the CSR must already contain the required subject field values. Unlike the automated pathway, the platform cannot modify a CSR's subject fields. A CSR that does not satisfy enforced field values will produce a policy violation.
Security Hygiene¶
Revoke Compromised Certificates Immediately¶
If you believe a private key has been compromised, revoke the certificate immediately using the revocation reason keyCompromise. Issue a replacement certificate from a freshly generated key pair.
Limit PFX Downloads¶
The PFX download exports both the certificate and the private key in a password-protected bundle. Limit use of PFX export to situations where the key must be imported into a system that cannot retrieve the certificate another way. The password shown at download time is not stored by the platform — keep it securely.
Use Short Validity for High-Risk Certificates¶
For certificates covering high-value services or sensitive internal systems, use short validity periods (30–90 days) and automate renewal. Shorter lifetimes limit the exposure window if a certificate is compromised and not immediately revoked.
Summary¶
| Practice | Recommendation |
|---|---|
| Domains | Register apex domains; remove stale entries |
| Internal certificates | Use Local PKI |
| Public certificates | Use a trusted external CA |
| Algorithm | Prefer ec-384; use RSA only for compatibility |
| Validity | ≤ 398 days for public; 90–365 days for internal |
| Policy | Hard-fail for critical controls; soft-fail for advisory |
| Compromised keys | Revoke immediately; re-issue from new key pair |
| PFX export | Use only when necessary; store password securely |