TechPrufer
Get started
Cloudflare
Cloudflare logoCloudflare · Feature trail

Certificate Authority Chain Management

24 posts · Sep 2011 – Sep 2026

What this trail covers

Cloudflare is becoming a public Certificate Authority (CA), aiming to provide free, automated certificates with wide compatibility. This involves acquiring an established root from GlobalSign for immediate reach and developing a new root for future compatibility, including post-quantum certificates. The CA will be ACME-first, support Merkle Tree Certificates (MTCs) for post-quantum security, and emphasize transparency, resilience, and fail-small principles in its operations. Cloudflare will act as a CA and a Mirroring Cosigner for other CAs, and will support MTC issuance for classical and post-quantum certificates. The issuance process involves batching certificates into an append-only Merkle tree, where the CA signs the root of the tree. Clients verify certificates using a compact inclusion proof against a signed tree head. The CA operates issuance and mirroring software stacks, and will fork Boulder for ACME support. Mirroring cosigners durably store a copy of the CA's issuance log and verify its consistency. Chrome's Quantum-resistant Root Program draft policy mandates at least two cosignatures: one from a Chrome-recognized Mirroring Cosigner operated by a distinct organization, and one from the issuing MTC CA itself.

All Cloudflare trails
  1. Building a certificate authority for the whole InternetCloudflare announces its intent to become a public Certificate Authority (CA). This involves applying for inclusion in major root programs, acquiring GlobalSign's established root for broad compatibility, and developing a new root for future standards like post-quantum cryptography. The CA will be ACME-first, support Merkle Tree Certificates (MTCs) for post-quantum security, and focus on resilience through transparency, reproducible builds, and fail-small principles. Cloudflare will use its own CA for its internal operations as 'Customer Zero'.
  2. Building a post-quantum certificate authority with Merkle Tree CertificatesThis post details the architecture and implementation of Merkle Tree Certificates (MTCs) for post-quantum cryptography in the context of Cloudflare becoming a Certificate Authority (CA). It explains the scaling challenges of post-quantum signatures in the current Certificate Transparency (CT) ecosystem and how MTCs address this by batching certificates into a Merkle tree, allowing for compact inclusion proofs and efficient verification. The post outlines the roles of CAs and Mirroring Cosigners in the MTC ecosystem, the standalone and landmark-relative forms of MTCs, and the issuance workflow using ACME. It also discusses Cloudflare's plans to fork Boulder for ACME support and its commitment to providing standard MTC issuance at no cost.
  3. Automatic Key Exchange: faster, post-quantum secure origin handshakes for 45 billion daily connections (and counting)Introduces Automatic Key Exchange, an extension of Automatic SSL/TLS, which probes origins to determine supported key agreement algorithms for TLS 1.3 handshakes. This eliminates unnecessary HelloRetryRequests by leading with the optimal algorithm, including post-quantum hybrids like X25519MLKEM768, thereby reducing connection handshake latency and enabling automatic post-quantum origin connections without manual configuration.
  4. Certificate Transparency Monitoring is now generally availableThis post details the technical solution for reducing noise in Certificate Transparency (CT) monitoring alerts. The core problem was distinguishing between routine Cloudflare-issued certificates and potentially malicious ones. The solution involves identifying a consistent, reproducible, and early identifier: the SHA-256 hash of the SubjectPublicKeyInfo (SPKI). The certificate ordering service now records this `spki_sha256` at key generation. The CT alerting service recomputes this hash from log entries and checks it against the ordering service's database. A match suppresses the alert, while a non-match triggers an alert. This resolves the issue of separate systems lacking a common identifier and the timing problem of `stripped_fingerprint` arriving too late. The post also describes improvements to alert emails and future plans for integration with Cloudflare Notifications.
  5. Post-quantum authentication to origins is now supportedThis post introduces post-quantum (PQ) authentication support for Cloudflare's Authenticated Origin Pulls (AOP) and Custom Origin Trust Store (COTS) products, utilizing ML-DSA signatures. It details the engineering implementation for securing the Cloudflare-to-origin connection, including configuration steps for generating ML-DSA certificates and uploading them to COTS and AOP. The post also discusses the importance of avoiding downgrade attacks and outlines future plans for WebPKI support.
  7. Why we cannot wait for better post-quantum signature algorithmsThis post details the ongoing migration to post-quantum cryptography, specifically focusing on signature algorithms. While ML-KEM encryption is largely deployed, the migration to post-quantum signatures like ML-DSA is still in progress, with a target of 2029. The post analyzes various emerging post-quantum signature schemes (FN-DSA, HAWK, SQIsign, etc.) and compares their performance and size characteristics against classical algorithms and the standardized ML-DSA. It highlights the trade-offs between 'specialist' algorithms (e.g., SQIsign for small signatures) and 'generalists' (e.g., ML-DSA), and discusses the challenges of implementing these new algorithms securely and efficiently, particularly in the context of TLS handshakes and offline use cases. The urgency of migrating to available post-quantum signatures like ML-DSA is emphasized due to the anticipated arrival of advanced quantum computers.
  8. Cloudflare One is the first SASE offering modern post-quantum encryption across the full platformThis post details the integration of post-quantum (PQ) hybrid ML-KEM encryption into Cloudflare IPsec and the Cloudflare One Appliance, completing the SASE platform's quantum-safe capabilities. It explains the necessity of PQ encryption due to NIST deadlines and the historical difficulty of crypto upgrades, highlighting the 'harvest now, decrypt later' threat. The post contrasts the IPsec journey with TLS, discussing RFC 8784's limitations (PSK, QKD) and RFC 9370's interoperability challenges, emphasizing Cloudflare's implementation of hybrid ML-KEM for key establishment in IPsec to provide forward secrecy and crypto agility.
  9. Keeping the Internet fast and secure- introducing Merkle Tree CertificatesThis post introduces Merkle Tree Certificates (MTCs) as a proposal to redesign the WebPKI for post-quantum cryptography. MTCs aim to reduce the number of signatures and public keys in TLS handshakes by disseminating certificate information out-of-band and making certificate transparency a first-class feature. The proposal is being experimentally deployed with Chrome Security to test its performance and security implications.
  10. State of the post-quantum Internet in 2025This post provides an update on the state of post-quantum (PQ) encryption adoption and the quantum threat. It highlights that the majority of human-initiated traffic with Cloudflare is now using PQ encryption, mitigating harvest-now/decrypt-later attacks. The post details progress on NIST standards, quantum hardware advancements (silicon-based, trapped-ion, topological qubits), and significant software optimizations by Craig Gidney that have reduced the estimated qubit count needed to break RSA-2048, effectively moving Q-day closer. It also discusses a scare from Chen's algorithm, which was later found to be buggy, and reiterates the industry's reliance on lattice-based cryptography.
  11. Securing today for the quantum future: WARP client now supports post-quantum cryptography (PQC)This post details the upgrade of the WARP client (consumer 1.1.1.1 and Cloudflare One Agent) to support post-quantum key agreement using MASQUE tunnels. It explains the value proposition of protecting against harvest-now-decrypt-later attacks, the technical implementation involving MASQUE tunnels and Cloudflare's global network, and the challenges of deploying PQC to end-user devices across multiple operating systems. It also outlines the strategies used for a robust rollout: temporary PQC downgrades, gradual rollout, and MDM overrides.
  12. You don’t need quantum hardware for post-quantum securityThis post provides guidance on preparing for Q-day by deploying post-quantum cryptography (PQC) on existing hardware. It explains that PQC is the solution for protecting against quantum adversaries and that quantum technologies like Quantum Key Distribution (QKD) and Quantum Random Number Generation (QRNG) are neither necessary nor sufficient for this purpose. The post emphasizes that PQC runs on conventional computers and can be more performant than classical cryptography, negating the need for new hardware in most cases.
  13. Addressing the unauthorized issuance of multiple TLS certificates for 1.1.1.1This post details an incident where Fina CA issued unauthorized TLS certificates for Cloudflare's 1.1.1.1 public DNS resolver. It explains the security model of DNS over TLS (DoT) and DNS over HTTPS (DoH), emphasizing the reliance on CA-issued certificates for authentication. The post highlights the role of Certificate Transparency (CT) logs in detecting such misissuance and discusses the requirements for an attacker to impersonate the 1.1.1.1 service, concluding that the unauthorized issuance, while an error by Fina CA, did not lead to a successful attack due to the need for the attacker to possess the private key and for clients to trust the Fina CA. The incident underscores the importance of CAs verifying domain control and the value of CT logs.
  14. A next-generation Certificate Transparency log built on Cloudflare WorkersThis post introduces the static CT API, a new design for Certificate Transparency logs that organizes data into cacheable tiles. It details the operational challenges of existing CT logs (integrity and availability) and how the static CT API addresses them through efficient serving from object storage and CDN caching. The post announces the open-sourcing of a Rust implementation of this new design, deployed on Cloudflare Workers, and the deployment of test logs using this infrastructure.
  15. How Cloudflare is helping domain owners with the upcoming Entrust CA distrust by Chrome and MozillaThis post announces the integration of SSL.com as a selectable Certificate Authority (CA) within Cloudflare's Advanced Certificate Manager and SSL for SaaS products. This integration allows customers to automatically manage SSL certificates issued by SSL.com, mitigating the impact of Chrome and Mozilla's upcoming distrust of Entrust certificates. The post details how to select SSL.com via the UI and API, including options for certificate validity periods and DNS-based validation (DCV Delegation) for automated renewals.
  16. Avoiding downtime: modern alternatives to outdated certificate pinning practicesThis post details the obsolescence of certificate pinning due to more frequent CA and intermediate certificate rotations, shorter certificate lifetimes, and increased use of certificate transparency. It explains how these modern practices mitigate the security risks that certificate pinning was designed to address, rendering it unnecessary and prone to causing outages. The post highlights Cloudflare's Universal SSL pipeline and its move towards ACME-compliant CAs with shorter validity periods.
  17. How we ensure Cloudflare customers aren't affected by Let's Encrypt's certificate chain changeThis post details Cloudflare's proactive strategy to manage the expiration of Let's Encrypt's cross-signed certificate chain. To ensure continued compatibility with legacy devices (e.g., Android < 7.1.1), Cloudflare will migrate Universal SSL and SSL for SaaS certificates to alternative CAs that support ISRG Root X1. This involves modifying the certificate pipeline to issue certificates from different CAs for renewals starting June 2024, one lifecycle before the cross-sign expires. The post also elaborates on Cloudflare's robust TLS certificate pipeline, emphasizing its ability to handle Domain Control Validation (DCV) with external DNS providers, bypass WAF blocks for CA verification requests, manage CAA records to ensure certificate issuance even when preferred CAs are blocked, and maintain CA redundancy with multiple active CAs to prevent outages during maintenance periods. The adoption of 90-day certificate validity periods and the addition of ECDSA support from Google Trust Services are also highlighted as security enhancements.
  18. Upcoming Let’s Encrypt certificate chain change and impact for Cloudflare customersThis post details Cloudflare's proactive change to exclusively use Let's Encrypt's ISRG Root X1 chain for new certificates starting May 15, 2024, in preparation for the expiration of the IdenTrust cross-signed chain on September 30, 2024. It quantifies the impact on legacy devices (2.96% of Android requests) and outlines mitigation strategies for customers, including updating client trust stores or switching to Google Trust Services for Enterprise plans. The post also provides historical context on TLS adoption and the importance of agile PKI ecosystems.
  19. Out now! Auto-renew TLS certificates with DCV DelegationIntroduced DCV Delegation, a new feature that allows customers with external DNS providers to delegate the Domain Control Validation (DCV) process to Cloudflare. This enables automatic renewal of TLS certificates, including wildcard certificates, by placing a single CNAME record at their DNS provider that points to Cloudflare's dcv.cloudflare.com domain. This feature addresses the increased management overhead caused by shorter certificate lifetimes and stricter DCV requirements, particularly for wildcard certificates.
  20. Introducing: Backup CertificatesIntroduced the concept and implementation of 'backup certificates' to enhance resilience against key compromises, mass revocations, and other unforeseen events that necessitate certificate re-issuance. Backup certificates are issued from a different Certificate Authority (CA) and wrapped with a different private key than the primary certificate. This strategy aims to ensure immediate deployability and mitigate impact during large-scale re-issuance events, reducing reliance on external CA systems and manual customer intervention for Domain Control Validation (DCV). The initial rollout targets Universal Certificate orders for Free, Pro, and Biz accounts using Cloudflare as an Authoritative DNS provider, with plans to expand to Enterprise customers and other certificate types.
  21. Making protocols post-quantumThis post details the challenges and trade-offs in migrating cryptographic protocols, specifically TLS, to post-quantum cryptography. It analyzes the characteristics (transmission size, speed) of various NIST Post-Quantum standardization candidates for Key Encapsulation Mechanisms (KEMs) and signature schemes. It highlights the need to choose between 'fast' and 'small' algorithms and explores the potential of using KEMs for authentication to achieve a faster or smaller protocol, while acknowledging the need for continued signature verification for certificate chains.
  22. Staging TLS Certificates: Make every deployment a safe deploymentIntroduced a staging environment for custom uploaded TLS certificates for Enterprise customers. This feature allows users to test new certificates against a pair of staging IPs before pushing them to production, mitigating risks associated with certificate pinning and ensuring successful TLS termination. The staging environment replicates the production environment but is only accessible via specific staging IPs. Users can upload certificates, make curl requests to verify coverage and correctness, and then push to production or disable if issues arise. Future plans include staging certificate renewals and TLS configuration changes.
  23. Heartbleed RevisitedThis post revisits the Heartbleed vulnerability and details Cloudflare's subsequent advancements in TLS/SSL security. Key contributions include the development and promotion of Keyless SSL, Geo Key Manager, Keyless Everywhere, and Delegated Credentials for enhanced private key protection. It also highlights improvements in certificate revocation mechanisms, specifically the adoption and support of OCSP Must-staple, to address the shortcomings exposed by the Heartbleed event.
  24. Introducing: Advanced Certificate ManagerIntroduced Advanced Certificate Manager (ACM) as an upgrade to Dedicated Certificates. ACM allows customers to set certificate validity periods as short as 14 days, control cipher suites used for TLS connections, and generate Certificate Signing Requests (CSRs) for custom CA certificates. ACM supports issuing up to 100 edge certificates per zone, including wildcard certificates, and offers choices for validation method (HTTP, TXT, Email) and certificate authority (Let's Encrypt, Digicert). Dedicated Certificate customers will be migrated to ACM with zero downtime. The API for certificate issuance has been updated.
  25. Automated Origin CA for KubernetesThis post introduces `origin-ca-issuer`, a new Kubernetes controller that integrates with Cloudflare's Origin CA. It allows cert-manager to automate the creation and renewal of TLS certificates for domains hosted on Kubernetes clusters. The post details the creation of an `OriginIssuer` resource and a `Certificate` resource, demonstrating how to configure domain names, validity durations, and renewal periods. It also shows how to leverage this integration with Kubernetes Ingress resources. The technical implementation of the `origin-ca-issuer` is described, highlighting the use of two reconciliation controllers: one for managing `OriginIssuer` resources and another for processing `CertificateRequest` resources.
  26. Going Keyless EverywhereThis post details the technical implementation of 'Keyless Everywhere,' a multi-year project to enhance security against memory disclosure vulnerabilities by separating private keys from internet-facing web servers. It describes the repurposing of the gokeyless project into 'gokeyless-internal' for Cloudflare's edge infrastructure, including the implementation of lazy loading for millions of keys and the use of the 'tableflip' package for graceful upgrades. The initial test bed was an experimental Go-based TLS 1.3 server, followed by integration into Spectrum.
  27. Delegated Credentials for TLSIntroduced support for Delegated Credentials for TLS, a new protocol that allows servers to terminate TLS connections using short-lived, delegated credentials. This protocol was developed in collaboration with industry partners and aims to improve performance and reliability by reducing latency compared to traditional Keyless SSL. The implementation is integrated with Cloudflare's Keyless SSL and Geo Key Manager, and has been implemented in Firefox Nightly. This feature also enables experimentation with new authentication algorithms and facilitates the transition to post-quantum cryptography.
  28. Introducing Certificate Transparency MonitoringThis post introduces Certificate Transparency Monitoring, a new feature that allows customers to receive email alerts when a certificate is issued for their domains by crawling public Certificate Transparency logs. It explains the importance of certificate security, the role of Certificate Authorities (CAs), and how Certificate Transparency (CT) works by requiring certificates to be submitted to public logs. The feature leverages Cloudflare's existing CT infrastructure, including the Nimbus log and Merkle Town, to process certificate data and alert users. It details the process of enabling the feature in the dashboard and provides guidance on what to do when a certificate alert is received.
  29. Securing Certificate Issuance using Multipath Domain Control ValidationThis post introduces a new, free tool for Certificate Authorities (CAs) to further secure certificate issuance by addressing vulnerabilities in Domain Control Validation (DCV) methods. It details how BGP hijacking attacks (Sub-Prefix and Equally-Specific-Prefix) can be used to trick CAs into issuing certificates for domains not owned by the requestor. The post also touches upon DNS spoofing as another attack vector. The new tool aims to mitigate these risks by providing a more robust DCV mechanism.
  30. Tracing Soon-to-Expire Federal .gov Certificates with CT MonitorsThis post details the use of Cloudflare's Certificate Transparency (CT) monitor, Merkle Town, to identify federal .gov websites with soon-to-expire TLS certificates during a government shutdown. It describes the process of extracting certificates from CT logs, storing them in HBase, and using MapReduce to filter for .gov domains expiring within two months. A second pass involved contacting domains to verify if expired certificates were still being served. The post also highlights unexpected misconfigurations found, such as SSL_ERROR_RX_RECORD_TOO_LONG and incomplete certificate chains, and advocates for automated certificate renewal solutions like Cloudflare's Universal SSL.
  31. A tour through Merkle Town, Cloudflare's Certificate Transparency dashboardCloudflare has launched Merkle Town, a publicly accessible dashboard for monitoring the health and performance of Certificate Transparency (CT) logs. The tool fetches Signed Tree Heads (STHs) and trusted roots, crawls new entries, and submits valid certificates to logs. It provides statistics on certificate breakdown by type (validation level, public key algorithm, signature algorithm, entry type, expired vs. current), root certificate authorities, global issuance and expiration rates, legacy algorithms, and log utilization by large certificate authorities. The dashboard also details monitoring methodology, including uptime and response time calculations based on endpoint success rates and average response times over a 90-day rolling window. The post highlights observations such as RSA representing 93% of certificates but only 91% of unexpired certificates, indicating increased adoption of elliptic curve cryptography. It also notes that Let's Encrypt accounts for approximately 75-80% of global certificate issuance.
  32. Introducing Certificate Transparency and NimbusCloudflare is announcing support for Certificate Transparency (CT) by introducing Nimbus, a free and open CT log, and Merkle Town, a dashboard for exploring the CT ecosystem. The post explains CT's role in improving web security and accountability by making all issued certificates public. It details how CT works, the roles of log operators, auditors, and monitors, and how browsers require SCTs (Signed Certificate Timestamps) from vetted logs for CT qualification. Cloudflare's Nimbus log and Merkle Town auditor are presented as contributions to this ecosystem.
  33. Deprecating TLS 1.0 and 1.1 on api.cloudflare.comThis post announces the deprecation of TLS 1.0 and 1.1 on api.cloudflare.com and the Cloudflare dashboard, mandating TLS 1.2 or higher for API calls and dashboard access. It outlines the timeline for these changes, including warning messages in API responses, a 24-hour brownout period, and permanent disabling of older TLS versions. The post also details upcoming controls and analytics features, such as the 'Minimum TLS Version' setting and TLS version usage analytics, to help customers manage their own TLS configurations.
  34. CAA of the Wild: Supporting a New StandardThis post announces the removal of the beta flag for Certification Authority Authorization (CAA) record support, making it available to all Cloudflare users. It details the purpose of CAA records in preventing certificate mis-issuance, explains the RFC6844 specification for CAA properties (`issue`, `issuewild`, `iodef`), and highlights a critical processing algorithm flaw related to CNAME records and the traversal of the DNS tree. Cloudflare also details its implementation, including automatic augmentation of CAA records for Universal SSL customers.
  35. How we built Origin CA: Web CryptoThis post details the technical implementation of Cloudflare's Origin CA, focusing on the use of the W3C Web Crypto API for client-side private key generation and the PKI.js library for constructing Certificate Signing Requests (CSRs). It highlights the security and usability benefits of keeping private keys on the client's machine and addresses browser compatibility challenges by implementing a shim for the Web Crypto API.
  36. Introducing CloudFlare Origin CAIntroduced Cloudflare Origin CA, a private Certificate Authority designed to issue streamlined certificates for inter-server communication between Cloudflare's edge and customer origin servers. Key benefits include simplified issuance and renewal (replacing DCV with API key authentication), wildcard certificate support for multiple hostnames, faster revocation (microseconds via in-memory lookup), and optimized certificate sizes (reduced handshake by up to 70%) by removing extraneous components like intermediate CAs and SCTs. Certificates are available in multiple formats (PEM, DER, PKCS#7) and supported by extensive installation instructions.
  37. Introducing CFSSL 1.2This post announces CFSSL 1.2, introducing a TLS endpoint scanner for evaluating server security configurations, a transport package for Go developers to simplify encrypted connections with automated certificate management and renewal, and enhanced revocation support with PostgreSQL integration for CRL and OCSP. It also highlights the motivation for service-to-service encryption and the use of standards-compliant PKI technologies.
  38. Universal SSL: Encryption all the way to the origin, for freeIntroduced a new Origin CA service to provide free, limited-function certificates for customer origin servers. This enables full encryption from Cloudflare to the origin, complementing Universal SSL. The service uses CFSSL for certificate issuance and validation, and requires customers to submit a CSR and domain name for beta participation.
  39. CloudFlare and SHA-1 CertificatesThis post details Cloudflare's proactive response to upcoming browser policy changes regarding SHA-1 certificates. It explains the technical implications of SHA-1 deprecation by Chrome and Firefox, the compatibility challenges with older operating systems like Windows XP SP2, and Cloudflare's strategy to address these by reissuing SHA-1 certificates expiring before 2016 for paid customers and using SHA-2 by default for free customers. It also outlines future plans to offer SNI certificates with SHA-2 as primary for paid customers, with SHA-1 as a fallback.
  40. One More Thing: Keyless SSL and CloudFlare's Growing NetworkIntroduced Keyless SSL as a strategy to expand Cloudflare's global network by allowing services to be offered without storing private SSL keys in all edge nodes. This addresses the limitation of network size shrinking when SSL is enabled for rival services and enables expansion into facilities with less stringent security requirements for sensitive data. It also allows for honoring geopolitical concerns regarding key storage locations.
  41. Keyless SSL: The Nitty Gritty Technical DetailsThis post details the technical implementation and security implications of Cloudflare's Keyless SSL, explaining the intricacies of TLS handshakes (RSA and Ephemeral Diffie-Hellman). It elaborates on the dual goals of TLS (confidentiality and authentication), the components of a TLS handshake (session key, client/server random, pre-master secret, cipher suite), and the specific steps involved in both RSA and DH handshakes. The post also introduces the concept of forward secrecy and the benefits of ECDSA keys. It highlights how Keyless SSL allows customers to retain their private SSL keys on-premises while leveraging Cloudflare's network for SSL termination, thereby enhancing security and control.
  42. Announcing Keyless SSL™: All the Benefits of CloudFlare Without Having to Turn Over Your Private SSL KeysIntroduced Keyless SSL, a novel system that allows Cloudflare to terminate SSL connections without ever possessing the customer's private SSL keys. This is achieved by running a local agent on customer infrastructure that communicates with Cloudflare's edge network. The agent handles the private key operations during the SSL handshake, while Cloudflare's network manages the rest of the SSL termination process. This enables cloud-based scalability and performance benefits while maintaining on-premise security for private keys.
  43. Introducing CFSSL - CloudFlare's PKI toolkitThis post introduces CFSSL, Cloudflare's open-source PKI toolkit written in Go. CFSSL is designed to simplify the creation of TLS/SSL certificate bundles, a common pain point for website operators. It addresses challenges related to browser compatibility and root certificate trust by intelligently selecting the optimal certificate chain for maximum compatibility, security, and performance. The toolkit can be used as a command-line tool or a web service with a JSON API. CFSSL is used internally by Cloudflare for its SSL services, including bundling certificates and managing its internal Certificate Authority infrastructure.
  44. The Hidden Costs of HeartbleedThis post quantifies the significant technical and financial costs associated with SSL certificate revocation, specifically detailing the bandwidth and infrastructure burden imposed by Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP). It highlights the growth of Globalsign's CRL to 4.7MB, generating approximately 40Gbps of net new traffic, and estimates monthly bandwidth costs for a CA to be upwards of $950,000 USD. It also touches upon the denial-of-service risk to CA infrastructures during mass revocations and Cloudflare's role in powering Globalsign's infrastructure to handle such loads.
  45. Certificate Revocation and HeartbleedThis post details the immediate response to the Heartbleed vulnerability by revoking a compromised certificate for cloudflarechallenge.com. It discusses the varying browser behaviors (Internet Explorer, Safari, Firefox, Chrome) when encountering revoked certificates and emphasizes the importance of online revocation checking and CRLSets. It also notes the significant increase in certificate revocations following the Heartbleed announcement and encourages vulnerable websites to revoke and rekey their certificates.
  46. What We Just Did to Make SSL Even FasterThis post details an improvement to Cloudflare's SSL certificate bundling process. Previously, custom SSL certificates included more data than necessary, leading to performance issues. The company developed a system to intelligently select the shortest and most ubiquitous certificate chains by building a directory of intermediate certificates and ranking possible chains based on length, root ubiquity, security, and validity period. This automated process optimizes server bundles for size, speed, and browser support. The directory of intermediate certificates will be published on GitHub, and the SSL bundler will be released as a free service.
  47. Globalsign, CloudFlare & Hacking SSLThis post details Cloudflare's partnership with GlobalSign for SSL certificate issuance and the implications of a potential security incident at GlobalSign. It explains the role of Certificate Authorities (CAs) in establishing website identity and the chain of trust. The post describes the risks associated with compromised CAs, such as impersonation attacks, and how browser vendors rebuild trust by revoking trust in compromised root certificates. Cloudflare's ability to automatically reissue and deploy new certificates across its network in response to such incidents is emphasized as a key feature.