The rules around certificates are changing faster than most teams realize. Industry shifts such as shorter lifetimes, post-quantum cryptography and  machine identities for AI agents and automated workloads are reshaping what “good” looks like. This guide walks through what you need to know, separated clearly by whether you are managing public or private certificates.  

The industry is moving, here’s what’s changing  

Before diving into best practices, three shifts are worth naming explicitly.  

EKU separation- The CA/B  Forum is removing the Client Authentication extended key usage (EKU) from all publicly trusted TLS certificates. If your organization currently uses a public TLS certificate for mutual TLS (mTLS) or client authentication, those use cases must migrate to private PKI. Standard HTTPS websites are completely unaffected, this change only matters if you’re running client auth on public certs.  

Shorter certificate lifetimes are coming to public certificates. CA/B Forum sets a clear roadmap: 200-day maximum validity from March 2026, 100 days in March 2027, and 47 days by March 2029. The practical implication is that manual certificate renewal is no longer a viable operating model. Automation is the mandate.  

Post-quantum cryptography (PQC) preparation window is now. NIST finalized three algorithms in 2024, ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). The more urgent concern is “harvest now, decrypt later”: adversaries are actively collecting encrypted traffic today with the intent to decrypt it once quantum hardware matures.   

  

Public certificates vs Private certificates:   

Customers frequently conflate these two worlds.   

Publicly trusted TLS certificates are certificates issued by public Certificate Authorities and anchored in trust stores shipped with browsers and operating systems, which means they must comply with CA/Browser Forum requirements and root store program policies. The upcoming EKU changes and shorter lifetimes apply exclusively to publicly trusted TLS certificates. Those are governed by the CA/Browser Forum and root store programs run by Apple, Google, Microsoft, and Mozilla.  

On the other hand, Private certificates operate entirely under your own policy. They are not subject to browser root program rules. They operate under an organization’s own PKI governance, providing flexibility to define EKUs, validity periods, and CA hierarchy appropriate for internal use cases such as client authentication, device identity, service mesh, and VPN, but also requiring the organization to establish and enforce equivalent safeguards (for example, issuance policy, EKU scoping, name/pathlength constraints, key protection, auditing, and automated rotation and revocation) to reduce the risk of overly permissive certificates or mis-issuance. Private PKI is increasingly the architecturally correct place for client authentication, device identity, internal service mesh, VPN, and code signing. Organizations that already operate their own private PKI do not need to replace existing trust models to adopt these best practices.  A Bring Your Own CA (BYOCA) approach allows enterprises to integrate their existing root or subordinate Certificate Authorities into modern cloud and automation workflows while preserving internal trust policies, governance controls, and compliance requirements.   

  

Best practices: Public certificates  

Automate renewal end-to-end. With validity dropping to 47 days by 2029, no team can sustainably manage public certificate renewals manually at scale. ACME-based tools should be the standard operating model. Every certificate should renew without human intervention. Keep an eye on Oracle blogs for future announcements on this.  

Act on EKU removal before May 2026. Audit your certificate inventory now for any public certificate carrying the clientAuth EKU. If you are using them for mTLS, device auth, or any client-side authentication, build a migration plan to private PKI.   

Set the right CAA DNS records. Certificate Authority Authorization records let you designate, at the DNS level, which CAs are allowed to issue certificates for your domain. This is a low-effort, high-value control that helps prevent compliant public CAs from issuing certificates for your domain unless authorized.  

Monitor Certificate Transparency logs. Every public certificate issued is logged to public CT logs. Subscribe to monitoring services that alert you when any new certificate is issued for your domains. This is your early warning system for mis-issuance and unauthorized certificates.  

Always deploy the full certificate chain. When installing a certificate, include the complete chain, leaf certificate along with all intermediate certificates, in order. Missing intermediates can cause browsers/clients to reject the connection silently, and the error is frequently misdiagnosed.

Enforce TLS 1.2 and 1.3 only. SSL 3.0, TLS 1.0, and TLS 1.1 are deprecated and insecure. Enforce TLS 1.2 and TLS 1.3 today, and treat TLS 1.3 as the target state for PQC-ready TLS  

Use SAN correctly; stop relying on Common Name. Modern TLS validation is SAN-driven. OWASP’s current guidance explicitly notes that modern browsers ignore the Common Name and rely on the Subject Alternative Name (SAN). So the best practice is to ensure every public certificate is issued with the exact DNS names clients will use, and to stop thinking of CN as the source of identity  

Prefer DNS-based validation and plan for frequent revalidation. With validation-data reuse windows shrinking, enterprises should assume domain control validation will happen more often, not less. That makes DNS-based validation the most practical enterprise pattern, because it is easier to automate repeatedly than email-based processes and works well with wildcard or multi-environment workflows. The broader point is that validation itself is becoming part of the runtime automation loop.  

Avoid broad wildcard sprawl. This is not a brand-new standard, but it becomes more important under short-lifetime automation. Wildcards are operationally convenient, but they expand blast radius and often hide ownership. The better enterprise pattern is service- or endpoint-specific certs wherever practical, with wildcards used only where there is a justified platform need.  

Best practices: Private certificates  

The recommended hierarchy  

A well-designed private PKI follows a three-tier model.   

  • Tier 1 — Root CA is the trust anchor for your entire hierarchy. These CAs should be under strict access controls. It is only used for signing subordinate CA certificates. The root CA key should live in a FIPS 140-2 or 140-3 certified hardware security module (HSM). OCI KMS supports RSA and ECDSA key algorithms. Recommended Validity: upto 10 years. Recommended key: ECDSA, since it provides the same level of security as RSA with much smaller keys, resulting in faster TLS handshakes and lower CPU usage. 
  • Tier 2 — Subordinate CAs do the day-to-day work of issuing certificates. You should have at least one, and most organizations benefit from two or more, separated by use case: one for internal services and mTLS, one for user authentication and code signing. Keeping them separate means a compromise of one issuing CA doesn’t expose all certificate types. Validity: 3–5 years. OCI KMS supports RSA and ECDSA key algorithms. Recommended key: ECDSA. The keys should live in HSMs with strict access controls.  
  • Tier 3 — Leaf / End-Entity Certificates are issued to servers, devices, users, and applications. These are the certificates that get renewed frequently and should be automated. OCI supports RSA and ECDSA key algorithms. Recommended Validity: 90 days Recommended key: ECDSA .  
    Note: OCI Certificates automatic renewal applies to certificates issued and managed by OCI Certificates. Imported or externally managed certs need their own automation path.  

Get started with creating  a CA hierarchy in OCI  

Short-lived certificates for high-scale environments: The 90-day recommendation for private leaf certificates is a floor, not a target. For high-scale, high-churn environments, such as microservices, the right validity range is a few hours to one week. In modern cloud and microservice architectures, where workloads are ephemeral and scale dynamically, certificates function primarily as machine identities rather than long-term credentials. The best practice is to issue short-lived certificates with validity ranging from a few hours to one week for high-scale systems such as microservices, containers, and service meshes. This approach significantly reduces reliance on revocation mechanisms like CRLs, because compromised credentials naturally expire quickly.  Keep an eye on Oracle blogs for future announcements on this.

Define and enforce certificate profiles. Every certificate use case — server TLS, client auth, code signing, email — should have a locked template that specifies permitted EKUs, key usage flags, SAN requirements. Issuing CAs should only be able to produce certificates that match a defined profile. This prevents a server certificate from being accidentally or maliciously used for code signing. OCI Certificate policy references can help you understand how you can control some of these use cases via Auth  

Publish a reachable CRL. Ensure your Revocation infrastructure is reachable. If not, a CA’s CRL distribution point provides no revocation coverage in practice. Test your revocation endpoints regularly and monitor their availability. Set your CRLs properly using object buckets in OCI  

Audit CA operations on a defined schedule. Apply least-privilege to everyone with CA operator access. Log all certificate issuance events with immutable audit trails. Review periodically for anomalous patterns — unexpected certificate types, unusual SAN values, issuance outside working hours.