Certificate Validity Policies: 90 Days Is the New Standard
As of 2026, the trend toward shorter SSL/TLS certificate lifetimes has moved from proposal to policy. Following Google's push for 90-day validity in 2025, the CA/Browser Forum has officially reduced the maximum validity for publicly trusted TLS certificates from 398 days to 90 days. This change aims to mitigate long-term risks from compromised or misconfigured certificates while forcing organizations to adopt automated certificate management.
For web administrators, manual renewal is no longer viable. The ACME protocol (Automated Certificate Management Environment) has become essential, with clients like Certbot and win-acme integrating seamlessly with free certificate services for unattended deployment and renewal. We strongly recommend auditing your current certificate inventory and evaluating rotation strategies for internal CAs and private certificates immediately.
Browser Vendor Compliance Requirements
Major browsers continue to tighten trust requirements. Chrome's Root Program Policy mandated that all publicly trusted CAs complete compatibility testing for 90-day certificates by March 2026. Mozilla Firefox has reinforced mandatory Certificate Transparency (CT) logging, flagging any certificate not submitted to at least two CT logs as untrusted. Safari, in iOS 20 and macOS 15, now enforces stricter certificate validation by default, with zero tolerance for self-signed or expired certificates.
These changes mean that websites still using long-lived certificates or relying on manual deployment face browser blocking risks. Migrating to automation-friendly DV certificates or OV certificates is strongly advised.
TLS Protocol Evolution: TLS 1.3 Dominates as 1.2 Fades
By Q2 2026, TLS 1.3 adoption among the top million websites has surpassed 85%. TLS 1.3 not only significantly speeds up handshakes but also removes obsolete and insecure cipher suites like RSA key exchange and CBC mode. Cloud providers such as Microsoft Azure, AWS, and Cloudflare have disabled TLS 1.0 and 1.1 by default, and heavily regulated sectors like finance and healthcare are beginning to mandate TLS 1.3 exclusively.
For enterprise users, deploying TLS 1.3 requires attention to middleware compatibility. Legacy Java, .NET Framework, or embedded devices may lack native support. We recommend enabling TLS 1.3 on server-side software (e.g., Nginx, Apache) while keeping TLS 1.2 as a transitional fallback, but absolutely disabling TLS 1.0 and 1.1. Configuration guides are available on our installation help page.
Post-Quantum Cryptography: From Experiment to Pilot
Post-quantum cryptography (PQC) reached a critical turning point in 2026. The first NIST PQC standards (CRYSTALS-Kyber, CRYSTALS-Dilithium, etc.), published in 2024, are now entering real-world testing. Google Chrome began supporting hybrid post-quantum key exchange (X25519Kyber768) in early 2026, and Cloudflare and Amazon have initiated pilot deployments on their edge networks.
While the threat of quantum computers breaking current RSA/ECC encryption is not yet imminent, the "harvest now, decrypt later" risk has prompted financial and government agencies to act first. The CA/B Forum is expected to release draft PQC certificate formats by 2027. Website administrators do not need to replace certificates immediately, but should monitor CA vendors' PQC pilot programs and ensure server software (such as OpenSSL 3.x) supports PQC algorithms. We will continue tracking this topic on our industry news page.
Enterprise HTTPS Deployment: Zero Trust and Automation
Enterprise HTTPS deployment is evolving from "encrypt everything" to a zero-trust architecture. Certificate Lifecycle Management (CLM) tools have become essential for centrally monitoring expiration, revocation, and compliance status across thousands of certificates. Hybrid deployment models combining internal PKI with external CAs are also increasingly common to meet mTLS (mutual TLS) requirements in microservices and containerized environments.
Practical recommendations: 1) Obtain publicly trusted certificates for all internal domains or deploy a private CA, avoiding self-signed certificates; 2) Enable HSTS preloading to prevent SSL stripping attacks; 3) Regularly scan Certificate Transparency logs to detect unauthorized certificate issuance. For small and medium sites, free ACME-based automation remains the most cost-effective choice. Visit our FAQ for more common questions.