PKI Today 2026: The Standards Aren't Converging. It's a Feature, Not a Bug
It's tempting to assume that once the National Institute of Standards and Technology (NIST) finalized its initial post-quantum standards in 2024 [1], the world inherited a shared rulebook (as we mostly had in the past). What the world actually has today is roughly a shared calendar and several competing rulebooks, and the gaps between them are precisely where multinational PKI runs into trouble. The Shared Calendar The shared calendar is real, it tightened this year. The United States moved last, but it moved hard. Executive Order 14412, signed June 22, 2026, converted what had been draft guidance into enforceable deadlines. Federal high-value and high-impact systems must complete key-establishment migration by the end of 2030 and digital-signature migration by the end of 2031. Contractors are pulled to a 2030 line through the acquisition rules [2]. The defense side keeps its own clock under CNSA 2.0, with a 2027 acquisition gate and ML-KEM-1024 and ML-DSA-87 as the only approved parameter sets against NIST's quantum-secure guidelines [3]. Europe's coordinated roadmap lands in the same window, with national plans due by end of 2026. High-risk systems must complete migration by 2030, and full transition by 2035. DORA and NIS2 are already making a cryptographic inventory and demonstrable crypto-agility binding obligations, rather than aspirations [4][5]. Canada's procurement clauses bite April 1, 2026 [6]. Australia's signals directorate is targeting end of 2030 for ceasing traditional asymmetric cryptography entirely [7]. Read down the list and the dates cluster around 2030 hard enough that you can almost plan against a single number. You can't, because the dates are where the agreement ends. The rulebooks diverge on two things that matter enormously the moment you operate across borders. Jurisdiction Key date(s) Hybrid stance Algorithm set US federal (EO 14412) Key est. 2030, sig 2031 Unspecified; follows NIST sequencing ML-KEM, ML-DSA, SLH-DSA US NSS (CNSA 2.0) 2027 acquisition gate, 2035 full Pure (no hybrid requirement) ML-KEM-1024, ML-DSA-87 only EU (roadmap + DORA/NIS2) Plans 2026, high-risk 2030, full 2035 Hybrid encouraged NIST set; floating EU-grown options Germany (BSI) Aligned ~2030 Hybrid mandated NIST + FrodoKEM + Classic McEliece France (ANSSI) Aligned ~2030 Hybrid required (KEM and signatures) NIST + conservative hedge Australia (ASD) Traditional gone by end-2030 Permitted, not mandated; pure end-state ML-KEM-1024, ML-DSA-87 (end state) South Korea (KpqC) Standardizing from Jan 2025 Not specified SMAUG-T, NTRU+, HAETAE, AIMer (homegrown) China (ICCS / SM) Separate track, ongoing Not specified SM suite + own PQC call Sources by row: US federal [2]; US NSS [3]; EU [4][5]; Germany [8]; France [9]; Australia [7]; South Korea [10]; China [11]. Japan sits closest to the NIST-plus-hybrid posture with a 2035 target [12], and Canada is NIST-aligned and procurement-driven [6]; both are in the prose rather than the table because neither is a divergence story. Divergence One: Hybrid or Pure PQC The first divergence is hybrid versus single PQC -only. Germany's BSI mandates hybrid key exchange and goes beyond NIST by recommending two conservative fall-backs alongside the lattice schemes: FrodoKEM, built on unstructured lattices Code-based Classic McEliece Both carried in TR-02102-1 since its 2020 edition and reaffirmed in the current v2026-01 [8]. France's ANSSI requires hybrid for both key exchange and signatures [9]. This isn't an outlier either. The EU-wide Agreed Cryptographic Mechanisms list, the ECCG document published through ENISA, now recommends FrodoKEM alongside ML-KEM [13]. FrodoKEM was standardized by ISO in 2026 after NIST declined to standardize it, so the conservative-hedge camp has a coordinated European bloc behind it even as NIST and CNSA 2.0 stay structured-lattice-only for now [14] (CNSA adds LMS/XMSS for firmware). Note: NIST did select a code-based backup, HQC, but it's not the same kind of hedge. HQC is still working through the standardization pipeline and is a long way from a usable FIPS algorithm, so it isn't yet an option BSI's or ANSSI's near-term guidance can point the way FrodoKEM already is. Australia takes the opposite posture: it pushes pure high-parameter post-quantum as the 2030 end state. It permits hybrid only as a transition mechanism under a specific control, ISM-1996, which requires that the post-quantum algorithm, the traditional algorithm, or both be ASD-approved [7]. These are all examples of sophisticated agencies, looking at the same algorithms, arriving at nearly opposite deployment doctrines. A system that satisfies ANSSI by mandating hybrid isn't automatically the system Australia wants you running by 2030. This is still a polarizing discussion within relevant IETF working groups, where you'll more often hear the term composite than hybrid, because IETF. Divergence Two: The Algorithm Set The second divergence is the algorithm set itself, and this is where fragmentation stops being a matter of configuration. South Korea ran its own competition and selected its own algorithms in January 2025 [10]: SMAUG-T and NTRU+ for key encapsulation HAETAE and AIMer for signatures China runs the SM family domestically and opened its own post-quantum call in early 2025, on a separate track from NIST by design [11]. Japan sits closer to the NIST-plus-hybrid posture with a 2035 target [12]. So in one region we have a NIST-aligned regime, a NIST-plus-conservative-hedge regime, a pure-PQC regime, a homegrown-algorithm regime, and a fully separate cryptographic universe, all at once. There is no single crypto policy that satisfies all of them. Neat. Divergence Three: The Protocol Layer That algorithm-set fragmentation has a second, quieter layer underneath it: not every national selection has a path into the protocols the rest of the world actually runs. CA/B Forum-governed webPKI and the TLS stacks that consume it depend on IETF-registered codepoints, PKIX algorithm OIDs, TLS registry entries, and JOSE identifiers, and right now that registration work tracks NIST's picks almost exclusively. ML-KEM has an active TLS working group draft moving toward IANA codepoints [15] FrodoKEM, despite losing the NIST round, still has a foothold through the BSI-and-ANSSI-adjacent authors pushing it into IETF IPsecMe and LAMPS working groups [16][17] Korea's KpqC algorithms have none of that: SMAUG-T, NTRU+, HAETAE, and AIMer exist as working OpenSSL integrations only through the research-grade Open Quantum Safe project, with no IANA registry entry or IETF draft to reference at this time [18] A KpqC-compliant Korean system and a CNSA-2.0-compliant American one aren't just running different policies. Outside a handful of purpose-built interop layers, they may not be able to negotiate a handshake with each other without proxy. This is the upstream cause of everything article four described. The reason our certificate portfolio fragments across CAs isn't just commercial, it's that the algorithms those certificates carry, and the deployment rules that govern them, are set by bodies that have not converged and show no sign of fully converging. The Qualified Website Authentication Certificate (QWAC) we juggle as an operational headache is downstream of a genuine policy disagreement about who gets to decide what a trustworthy certificate is. Which leaves the only question that actually matters once the inventory is built, the cadence is automated, and the regimes are mapped: out of all this, what do you actually deploy, and in what order? Yep, we're gonna cover that too. Mahalo! References [1] National Institute of Standards and Technology (NIST). FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) [2] Executive Order 14412, signed June 22, 2026 (Dates and provisions from the primary; key-establishment migration end-2030, digital-signature migration end-2031, contractor pull-forward via acquisition rules) [3] US National Security Agency (NSA). Announcing the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), 2022. ML-KEM-1024 and ML-DSA-87 as the only approved sets; 2027 acquisition gate, 2035 full. [4] EU NIS Cooperation Group. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, June 2025. [5] Regulation (EU) 2022/2554 (DORA) and Directive (EU) 2022/2555 (NIS2). Binding cryptographic-inventory and crypto-agility obligations. [6] Government of Canada. Standard Procurement Information Notice (SPIN), PQC procurement clauses effective April 1, 2026; Canadian Centre for Cyber Security (CCCS), ITSM.40.001. cyber.gc.ca [7] Australian Signals Directorate. Information Security Manual (ISM), control ISM-1996 [8] Federal Office for Information Security (BSI). TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, v2026-01 (23 January 2026), §2.4 (Quantum-Safe Asymmetric Mechanisms): FrodoKEM §2.4.1 (FrodoKEM-976, -1344), Classic McEliece §2.4.2 (mceliece460896/6688128/8192128 and f-variants), ML-KEM §2.4.3 (Cat 3/5 → ML-KEM-768, -1024). [9] Agence nationale de la sécurité des systèmes d'information (ANSSI). ANSSI vies on the Post-Quantum Cryptography transition (2023 follow up), Dec 21, 2023 [10] KpqC (Korean Post-Quantum Cryptography Competition). Final selections announced January 2025: SMAUG-T and NTRU+ (KEM), HAETAE and AIMer (signatures). [11] China: SM cryptographic suite (domestic) and national post-quantum standardization call opened early 2025. [12] CRYPTREC (Japan). NIST-plus-hybrid posture with a ~2035 target [13] European Cybersecurity Certification Group (ECCG), Sub-group on Cryptography. Agreed Cryptographic Mechanisms, Version 3 (working draft, April 2026; published through ENISA). §5.4 lists ML-KEM and FrodoKEM as Recommended key-establishment schemes (FrodoKEM-1344 / -976), adds hybrid (PQ/T) explicitly, and introduces an "Admissible" status replacing "Legacy" (greenfield systems must use Recommended, not Admissible). NOTE: first/working draft, still in consultation. [14] ISO/IEC 18033-2:2006/Amd 2:2026. FrodoKEM standardized as an approved mechanism (June 2026) [15] draft-ietf-tls-mlkem-08, "ML-KEM Post-Quantum Key Agreement for TLS 1.3." D. Connolly, SandboxAQ. IETF TLS Working Group. In WG Last Call as of 24 June 2026 (last call closed 8 July 2026). [16] draft-ietf-ipsecme-hybrid-kem-ikev2-frodo-00, "Post-quantum Hybrid Key Exchange in IKEv2 with FrodoKEM." G. Wang, L. Bruckert (BSI), V. Smyslov, M. Chen. IETF IPsecMe Working Group. Adopted 11 March 2026. [17] draft-smyslov-lamps-frodokem-certificates-01, "Internet X.509 Public Key Infrastructure: Algorithm Identifiers for FrodoKEM." IETF LAMPS Working Group, individual submission. [18] Integration and benchmarking of KpqC algorithms (HAETAE, AIMer, SMAUG-T, NTRU+) into OpenSSL via the Open Quantum Safe liboqs/oqs-provider framework; no corresponding IETF draft or IANA TLS registry entry identified as of this writing.PKI Today 2026: Congratulations, Your Cert Renewal Is Now a Recurring Calendar Invite
398 days to 47 reads like a number change. Means nothing to management right? It's a workflow change. The cert(s) we touch once a year becomes the cert we touch every six weeks, multiplied by the entire inventory just built. The schedule is fixed, it is public, and it's not a rumor. The CA/Browser Forum passed Ballot SC-081v3 in April 2025, and it steps the maximum lifetime of a publicly trusted TLS certificate down: from 398 days, 200 days as of March 15, 2026, 100 days as of March 15, 2027, and 47 days as of March 15, 2029 [1]. Each step roughly halves the one before it. Certificates already issued keep their original lifetime, so nothing breaks overnight; the squeeze arrives at renewal, which is where most of your inventory meets the new rules whether it's ready or not. The math is the part that reframes it from policy to operations. An organization running a thousand public certificates handles on the order of a thousand renewals a year today. At a 47-day lifetime, those same thousand certificates generate nearly eight thousand renewal events a year, because each one now turns over roughly eight times instead of once [2]. That is the eight-fold figure sitting behind the opening line, and it's why "we'll add headcount" isn't an answer. You don't staff your way out of an eight-fold increase in a recurring administrative operation that requires a modicum of due diligence. You automate it, or you start having outages. This isn't hypothetical. Missed renewals already take down major infrastructures more than we sometimes want to admit: Microsoft Teams, February 2020: an expired authentication certificate locked users out of Teams globally for roughly three hours after the company reported that users may be unable to access Microsoft Teams and later confirmed the outage was due to an expired certificate (TechCrunch) Ericsson SGSN-MME, December 2018: an expired software certificate in Ericsson's core network software shut down affected equipment, knocking out mobile data and voice for roughly 32 million O2 customers in the UK and tens of millions of SoftBank customers in Japan (Softpedia) Logitech certificate, January 2026: an expired code-signing certificate broke Logitech's macOS apps system-wide, a fresh reminder that renewal failures aren't a 2018-2020 relic (MacRumors) Three different failure modes, one common thread: none of these companies lacked the engineering talent to prevent an expiration date from arriving unnoticed. They lacked the automation, or monitoring, or inventory, or any combination of the three. The 2027 Cliff Here is the part the headlines seem to miss: the cliff is 2027, not 2029. The 200-day phase that arrived in 2026 still survives a semi-manual process, because renewing twice a year is annoying but livable. The 100-day phase in March 2027 is where it breaks for most organizations, because quarterly-plus renewal across a production inventory is past the point where people clicking buttons can keep pace. By the time 47 days lands in 2029, any team that is going to make it has already automated. If 2029 is the coup de grâce, then 2027 is the wound, and "it's just a flesh wound" is not a migration strategy. Plan for the 2027 date and the 2029 one mostly takes care of itself. Validity, meanwhile, is only the number everyone watches. The one that actually reshapes your tooling is domain control validation reuse, which steps down on its own track: 398 days, now 200, soon 100, and finally 10 days in the last phase [1]. At a 47-day certificate with a 10-day reuse window, you are re-proving control of each domain something like three dozen times a year. Email-based validation and a human dropping a file on a server are finished at that cadence; they were never meant to run weekly. Worse, validation is getting more rigorous at the same time as it gets more frequent: the Forum now requires corroborating domain validation from multiple network perspectives, and DNSSEC validation where present is effective alongside the first phase in March 2026 [3]. The operation you now run thirty-odd times a year is also harder to run each time. There is no shortcut hiding in the effort. The Escape Hatch There is, however, an escape hatch. In October 2025 the Forum added a new domain control validation method, section 3.2.2.4.22, "DNS TXT Record with Persistent Value," informally the DNS-PERSIST-01 method [4], with a matching ACME challenge moving through the IETF as dns-persist-01 [5]. The idea is a set-once and reap the benefits over time: we place a single persistent TXT record naming the CA and our account, and the CA reuses it across issuances instead of making us rewrite DNS on every renewal. Read the fine print, though, because it's easy to oversell. The persistent record doesn't exempt you from the 10-day reuse cap; the CA still re-checks the record at each issuance and still may only rely on it for those ten days. What it removes is the per-renewal DNS write, not the re-validation. For shops with strict DNS change-management, for multi-tenant and edge platforms, and for IoT fleets that can't coordinate real-time DNS updates, it can be the difference between feasible and ITIL change control revolt; it's a workflow simplification, not a loophole. Add it up and the conclusion isn't so subtle. At this cadence automation stops being a nice-to-have and becomes the only way to stay out of an asylum. But "just automate it" quietly assumes one thing that falls apart fast: that a single CA can issue everything you need. And that's what we discuss next. References [1] CA/Browser Forum. Ballot SC-081v3, "Introduce Schedule of Reducing Validity and Data Reuse Periods" (passed April 2025). Maximum TLS validity 398 to 200 (15 Mar 2026), 100 (15 Mar 2027), 47 (15 Mar 2029); DCV reuse 398 to 200, 100, then 10 days; Subject Identity Information reuse 825 to 398 days as of 15 Mar 2026. [2] DigiCert. "TLS Certificate Lifetimes Will Officially Reduce to 47 Days" (2025 [3] CA/Browser Forum. Ballot SC-067v3 (Multi-Perspective Issuance Corroboration) and Ballot SC-085v2 (Require Validation of DNSSEC when present for CAA and DCV lookups) [4] CA/Browser Forum. Ballot SC-088v3, "DNS TXT Record with Persistent Value DCV Method [5] IETF draft-ietf-acme-dns-persist, ACME challenge "dns-persist-01" for persistent DNS TXT record validation (working-group draft, rev -01, 2026).PKI Today 2026: Step One Is Always Inventory. You Haven't Done It.
Every PQC roadmap, every regulator, every agency opens with the same unglamorous instruction: inventory your cryptography first. There's a reason it's always step one, and it isn't bureaucratic throat-clearing. The reason is that all three of the pressures (horses) from the previous article, the cert validity compression, the post-quantum migration, and the FIPS sunset, share a single precondition. We can't shorten the renewal cycle on a certificate we don't know exists, we can't swap an algorithm we can't locate, and we can't prove a boundary is validated if we've never established where the boundary is. Discovery isn't the first task because someone enjoys paperwork. It's the first task because every other task lies undefined until it's done. The deadlines already have dates. Our cryptographic inventory does not yet exist. Start with what "cryptography" means here, because the word does more work than people expect. It's not your web TLS certificates alone: It's your TLS certificates AND The keys behind the code-signing pipeline The algorithms inside your VPN and SSH The cipher suites your load balancers negotiate, The crypto library static-linked across three dependencies deep into an application nobody's patched since 2019 The keys sitting in an HSM whose firmware you never audited (let's be honest, not many people have) The partner API's and Saas integrations you call, whose TLS and cert lifecycles you don't control but whose failure still breaks your pipeline anyway The machine-readable artifact for capturing all of that is the Cryptography Bill of Materials (CBOM), which extends a software Bill of Materials (SBOM) you may already produce [1] down into cryptographic specifics: which algorithm, which key length, which library, used where. The inventory itself is a federal requirement rather than a suggestion. NSM-10 and OMB M-23-02 direct agencies to maintain a prioritized inventory of cryptographic systems and to report on it, and NIST's transition guidance treats that inventory as the prerequisite for everything downstream [2][3]. The CBOM is the format that federal discovery work, including NIST's National Cybersecurity Center of Excellence (NCCoE) migration project, increasingly converges on [4], even where the binding mandate names the inventory rather than the file. Here is the trap, and it's quiet. Cryptographic inventories that are supposed to cover everything tend to collapse into TLS certificate inventories, because certs are the easiest thing to scan and count. Resist letting the scope collapse, but do let the sequencing reflect the urgency of the other deadlines: Certificates go to the front of the inventory & remediation queue, not because they matter more than code signing or VPN keys, but because they are where the first hard, externally imposed deadline lands. The 47-day impacted regime in the next piece has a date on it. Your code-signing migration, for now, does not. So you inventory everything and you triage certificates first, and those are two different statements that are dangerously easy to blur into one. The hard part of discovery is that it is never complete, and the entries that hurt you are the ones you didn't find. You will catch the certificates you provisioned on purpose. You will miss the self-signed cert an engineer stood up for a staging box in 2021, the key baked into a firmware image, the dependency that quietly pulls in its own TLS stack. No single method finds everything: Method Sees Misses Network scanning What answers on a port Anything not listening/exposed CT log mining What was publicly logged Internal/non-public certs, anything pre-CT-era Host agents What's installed on a managed endpoint Unmanaged hosts, shadow IT Source analysis What's compiled/linked in Runtime-only config, anything not in the repo you're scanning A realistic inventory process coordinates across all of them and still assumes it is incomplete, because the alternative is learning about the gap when a certificate you never knew about expires at two in the morning. Have I received that call? Yup. One discovery detail is worth singling out now, because it returns later in this article series with real consequences. When your inventory records that an appliance is "FIPS validated," that sentence isn't yet a fact, it's three possible facts. The validated boundary might be the software cryptographic module, the appliance as a whole, or an attached hardware security module, and on a platform like F5's BIG-IP those are genuinely different scopes with different validation status [5]. A CBOM entry that says "validated" without recording which boundary it means is an entry that will mislead you exactly when you can least afford it, during a migration whose whole premise is knowing what is actually certified. Record the boundary, not just the checkmark. None of this is glamorous, most of it is tedious, which is precisely why it gets deferred until a deadline drags it into the open. A finished inventory is the first time most teams see their real cert count. The second that number is on screen, the next problem introduces itself, because every one of those certs is about to need renewing far more often than it does today. Guess what topic we're teeing up for in the next article? References [1] CycloneDX (OWASP). Cryptography Bill of Materials (CBOM), an extension of the Software Bill of Materials that captures cryptographic assets (algorithms, key lengths, libraries, certificates) and their usage context. [2] National Security Memorandum 10 (NSM-10), May 2022, and Office of Management and Budget Memorandum M-23-02, "Migrating to Post-Quantum Cryptography," November 2022 [3] NIST IR 8547, Transition to Post-Quantum Cryptography Standards. [4] NIST National Cybersecurity Center of Excellence. SP 1800-38, Migration to Post-Quantum Cryptography [5] F5 BIG-IP FIPS 140-3 validationPKI Today 2026: Three Horses, Five Carts, Zero Slack
Everyone wants to tell you the post-quantum story as one horse, one cart, one tidy road to 2030. It isn't. There are three horses, they're all pulling at once, they're hitched to five different carts, and at least two of them are dragging the same cart in slightly different directions. That's why Public Key Infrastructure (PKI), from management to planning for future efforts feels heavier now even though nothing in your environment technically broke. The horses are our deadlines, and they don't coordinate. One is certificate validity collapsing from 398 days toward 47. One is Post-Quantum Cryptography (PQC) mandates, every major regulator setting its own pace around the year 2030. One is the FIPS-140-2 sunset, quietly invalidating cryptographic modules you're still running (I'm also going to lean in on this horse analogy way too much, you're welcome). Survivable, any one of them. But none of them checked the other two's calendar. Ballot: The 47-day Certificate Countdown The first horse is named Ballot, and it's the one already at a gallop. In April 2025 the CA/Browser Forum passed ballot SC-081v3, scheduling a reduction in maximum certificate lifetime from 398 days down to 47 by 2029 [1]. The schedule: 200 days as of March 15, 2026 (done) 100 days in 2027 47 days in 2029, with domain-validation reuse collapsing to 10 days That last step is the one that bites: a certificate you touched once a year becomes one you touch roughly eight times a year, multiplied by every public or regulated certificate in an inventory you haven't finished counting. Treat 2029 as the deadline and you've misread the schedule. The 2027 step to 100 days is where manual renewal breaks for most enterprises [2], and the market isn't waiting for the mandate either: Let's Encrypt has committed to a 45-day default by 2028, ahead of the industry timeline [3]. This is a now problem wearing a 2029 disguise. Reckoning: The Global Post-Quantum Cryptographic Timeline The second horse, called Reckoning, broke out running this year. US Executive Order 14412, signed June 22 2026, turned years of post-quantum draft guidance into enforceable federal deadlines [4]. High-value and high-impact systems must complete key-establishment migration to NIST-approved algorithms by the end of 2030, with digital-signature migration following by the end of 2031, and contractors are pulled to a 2030 line through the acquisition rules [4]. This isn't an American story alone. Every major regulatory bloc is running its own version of the same clock, non-exhaustively: EU: national roadmaps due end of 2026, high-risk systems migrated by 2030, full transition by 2035 [5] Australia: classical asymmetric cryptography retired entirely by end of 2030 [6] Canada: CCCS is running its own migration guidance on a parallel track, distinct from the NIST/CNSA baseline The mandates differ in mechanism and pace, but they converge on the same decade. Sunset: FIPS 140-2's Expiration Date The third horse is the quietest, which is exactly why it catches people. On September 21 2026, NIST's Cryptographic Module Validation Program (CMVP) moves FIPS 140-2 validations to its historical list, and a module on that list can no longer be procured to satisfy a federal cryptographic requirement [7]. Nothing about the module changes on that date. What changes is whether you are allowed to keep buying it. If your compliance story rests on a 140-2 certificate, that validation expires before either of the other two horses finishes its run. The replacement path runs through 140-3, and through providers that haven't finished validating their post-quantum primitives. We name this horse Sunset. The Pale Horse: CRQC's Unscheduled Arrival There is a fourth horse, and it's the reason the other three feel so urgent. Ballot's window collapse has the CA/Browser Forum cracking the whip; the Reckoning has regulators on different continents setting the pace; Sunset has a time window stamped on it by the CMVP. Somebody scheduled all three. Nobody scheduled the fourth. It rides last, and you already know the verse. And I looked, and behold a pale horse: and his name that sat on him was CRQC. Note: I'm pretty sure that's how the passage goes. The cryptographic relevant quantum computer (CRQC), it's the only thing on this page that never filed a transition timeline. You can't plan against its arrival date because it does not have one, which is exactly why the move is to start now instead of when it becomes obvious: by the time it is obvious, the broken thing is the math underneath everything you already shipped. Name the three and you have named the horses. The carts are the actual work efforts they tow behind them: Discovery: Finding the cryptography you can't currently see Automation: Issuance because manual renewal will be a death sentence Multi-CA: Running more than one certificate authority (CA) whether you wanted to or not PQC Deployment (including Hybrid): Deploying new quantum-resistant algorithms defined by your federal mandates PQC Cost: Surviving what those algorithms do to revocation and certificate size The trouble is that the horses don't line up one per cart. Ballot drags both discovery and automation. Reckoning is hitched to our PQC algorithm choices and our CA strategy and your deployment sequencing all at once. Sunset pulls on the same algorithm cart from the other side, because the modules you're forced onto are the ones still validating the new primitives. Pull hard on any one rein and you'll tighten three other traces you weren't watching. Note: A harness trace is what connects the horse to the cart. So this isn't a roadmap in the do-these-seven-things-in-order sense, because the work does not queue that cleanly. It's a map of which force is pulling which part of your estate, where they overlap, and what you can do about it, one dependency harness at a time. And every harness shares a single starting line. The horses do not agree on a deadline, and none of the work they demand is even possible until we know where our cryptography actually lives. Which is the part almost nobody has done. That's where this article series starts: not with algorithms or ballots, but with the unglamorous inventory every regulator quietly assumes you've already finished. From there we follow the path forward, one horse and one cart at a time. Analogy over. But we're just getting started with this article series. References [1] CA/Browser Forum. Ballot SC-081v3 (TLS certificate lifetime reduction), passed April 2025. Maximum validity 398 → 200 days (15 March 2026) → 100 days (2027) → 47 days (2029); DCV reuse window to 10 days. [2] Understanding the Risk Scale: 6-month SSL/TLS Validity Starts March 15, 2026. [3] Let's Encrypt. Decreasing Certificate Lifetimes to 45 Days. [4] Executive Order 14412, signed June 22, 2026. whitehouse.gov. Key-establishment migration end-2030, digital-signature migration end-2031; contractor pull-forward via acquisition rules. (FR Doc 2026-12909, Vol. 91 No. 121, 25 June 2026.) [5] EU NIS Cooperation Group. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, June 2025. National plans end-2026, high-risk systems 2030, full transition 2035. [6] Australian Signals Directorate. Information Security Manual (ISM): ceasing traditional asymmetric cryptography targeted for end of 2030. [7] NIST Cryptographic Module Validation Program (CMVP). FIPS 140-2 validations moved to the historical list effective September 21, 2026.Using Cryptonice to check for HTTPS misconfigurations in devsecops workflows
Co-Author: Katie Newbold, F5 Labs Intern, Summer 2020 A huge thanks to Katie Newbold, lead developer on the Cryptonice project, for her amazing work and patience as I constantly moved the goal posts for this project. ---F5 Labs recently published an article Introducing the Cryptonice HTTPS Scanner. Cryptonice is aimed at making it easy for everyone to scan for and diagnose problems with HTTPS configurations. It is provided as a is a command line tool and Python library that allows a user to examine the TLS protocols and ciphers, certificate information, web application headers and DNS records for one or more supplied domain names. You can read more about why Cryptonice was released over at F5 Labs but it basically boils down a few simple reasons. Primarily, many people fire-and-forget their HTTPS configurations which mean they become out of date, and therefore weak, over time. In addition, other protocols, such as DNS can be used to improve upon the strength of TLS but few sites make use of them. Finally, with an increasing shift to automation (i.e. devsecops) it’s important to integrate TLS testing into the application lifecycle. How do I use Cryptonice? Since the tool is available as an executable, a Python script, and a Python library, there are a number of ways and means in which you might use Cryptonice. For example: The executable may be useful for those that do not have Python 3 installed and who want to perform occasional ad-hoc scans against internal or external websites The Python script may be installed along side other Python tools which could allow an internal security team to perform regular and scriptable scanning of internal sites The Python library could be used within devops automation workflows to check for valid certificates, protocols and ciphers when new code is pushed into dev or production environments The aforementioned F5 Labs article provides a quick overview of how to use the command line executable and Python script. But this is DevCentral, after all, so let’s focus on how to use the Python library in your own code. Using Cryptonice in your own code Cryptonice can output results to the console but, since we’re coding, we’ll focus on the detailed JSON output that it produces. Since it collects all scan and test results into a Python dictionary, this variable can be read directly, or your code may wish to read in the completed JSON output. More on this later. First off we’ll need to install the Cryptonice library. With Python 3 installed, we simply use the pip command to download and install it, along with its dependencies. pip install cryptonice Installing Cryptonice using pip will also install the dependent libraries: cffi, cryptography , dnspython, http-client, ipaddress, nassl, pycurl, pycparser, six, sslyze, tls-parser, and urllib3. You may see a warning about the cryptography library installation if you have a version that is greater than 2.9, but cryptonice will still function. This warning is generated because the sslyze package currently requires the cryptography library version to be between 2.6 and 2.9. Creating a simple Cryptonice script An example script (sample_script.py) is included in the GitHub repository. In this example, the script reads in a fully formatted JSON file called sample_scan.json from the command line (see below) and outputs the results in to a JSON file whose filename is based on the site being scanned. The only Cryptonice module that needs to be imported in this script is scanner. The JSON input is converted to a dictionary object and sent directly to the scanner_driver function, where the output is written to a JSON file through the writeToJSONFile function. from cryptonice import scanner import argparse import json def main(): parser = argparse.ArgumentParser() parser.add_argument("input_file", help="JSON input file of scan commands") args = parser.parse_args() input_file = args.input_file with open(input_file) as f: input_data = json.load(f) output_data, hostname = scanner.scanner_driver(input_data) if output_data is None and hostname is None: print("Error with input - scan was not completed") if __name__ == "__main__": main() In our example, above, the scanner_driver function is being passed the necessary dictionary object which is created from the JSON file being supplied as a command line parameter. Alternatively, the dictionary object could be created dynamically in your own code. It must, however, contain the same key/value pairs as our sample input file, below: This is what the JSON input file must look like: { "id": string, "port": int, "scans": [string] "tls_params":[string], "http_body": boolean, "force_redirect": boolean, "print_out": boolean, "generate_json": boolean, "targets": [string] } If certain parameters (such as “scans”, “tls_parameters”, or “targets”) are excluded completely, the program will abort early and print an error message to the console. Mimicking command line input If you would like to mimic the command line input in your own code, you could write a function that accepts a domain name via command line parameter and runs a suite of scans as defined in your variable default_dict: from cryptonice.scanner import writeToJSONFile, scanner_driver import argparse default_dict = {'id': 'default', 'port': 443, 'scans': ['TLS', 'HTTP', 'HTTP2', 'DNS'], 'tls_params': ["certificate_info", "ssl_2_0_cipher_suites", "ssl_3_0_cipher_suites", "tls_1_0_cipher_suites", "tls_1_1_cipher_suites", "tls_1_2_cipher_suites", "tls_1_3_cipher_suites", "http_headers"], 'http_body': False, 'print_out': True, 'generate_json': True, 'force_redirect': True } def main(): parser = argparse.ArgumentParser(description="Supply commands to cryptonice") parser.add_argument("domain", nargs='+', help="Domain name to scan", type=str) args = parser.parse_args() domain_name = args.domain if not domain_name: parser.error('domain (like www.google.com or f5.com) is required') input_data = default_dict input_data.update({'targets': domain_name}) output_data, hostname = scanner_driver(input_data) if output_data is None and hostname is None: print("Error with input - scan was not completed") if __name__ == "__main__": main() Using the Cryptonice JSON output Full documentation for the Cryptonice JSON output will shortly be available on the Cryptonice ReadTheDocs pages and whilst many of the key/value pairs will be self explanatory, let’s take a look at some of the more useful ones. TLS protocols and ciphers The tls_scan block contains detailed information about the protocols, ciphers and certificates discovered as part of the handshake with the target site. This can be used to check for expired or expiring certificates, to ensure that old protocols (such as SSLv3) are not in use and to view recommendations. cipher_suite_supported shows the cipher suite preferred by the target webserver. This is typically the best (read most secure) one available to modern clients. Similarly, highest_tls_version_supported shows the latest available version of the TLS protocol for this site. In this example, cert_recommendations is blank but is a certificate were untrusted or expired this would be a quick place to check for any urgent action that should be taken. The dns section shows results for cryptographically relevant DNS records, for example Certificate Authority Authorization (CAA) and DKIM (found in the TXT records). In our example, below, we can see a dns_recommendations entry which suggested implementing DNS CAA since no such records can be found for this domain. { "scan_metadata":{ "job_id":"test.py", "hostname":"example.com", "port":443, "node_name":"Cocumba", "http_to_https":true, "status":"Successful", "start":"2020-07-13 14:31:09.719227", "end":"2020-07-13 14:31:16.939356" }, "http_headers":{ "Connection":{ }, "Headers":{ }, "Cookies":{ } }, "tls_scan":{ "hostname":"example.com", "ip_address":"104.127.16.98", "cipher_suite_supported":"TLS_AES_256_GCM_SHA384", "client_authorization_requirement":"DISABLED", "highest_tls_version_supported":"TLS_1_3", "cert_recommendations":{ }, "certificate_info":{ "leaf_certificate_has_must_staple_extension":false, "leaf_certificate_is_ev":false, "leaf_certificate_signed_certificate_timestamps_count":3, "leaf_certificate_subject_matches_hostname":true, "ocsp_response":{ "status":"SUCCESSFUL", "type":"Basic OCSP Response", "version":1, "responder_id":"17D9D6252267F931C24941D93036448C6CA91FEB", "certificate_status":"good", "hash_algorithm":"sha1", "issuer_name_hash":"21F3459A18CAA6C84BDA1E3962B127D8338A7C48", "issuer_key_hash":"37D9D6252767F931C24943D93036448C2CA94FEB", "serial_number":"BB72FE903FA2B374E1D06F9AC9BC69A2" }, "ocsp_response_is_trusted":true, "certificate_0":{ "common_name":"*.example.com", "serial_number":"147833492218452301349329569502825345612", "public_key_algorithm":"RSA", "public_key_size":2048, "valid_from":"2020-01-17 00:00:00", "valid_until":"2022-01-16 23:59:59", "days_left":552, "signature_algorithm":"sha256", "subject_alt_names":[ "www.example.com" ], "certificate_errors":{ "cert_trusted":true, "hostname_matches":true } } }, "ssl_2_0":{ "preferred_cipher_suite":null, "accepted_ssl_2_0_cipher_suites":[] }, "ssl_3_0":{ "preferred_cipher_suite":null, "accepted_ssl_3_0_cipher_suites":[] }, "tls_1_0":{ "preferred_cipher_suite":null, "accepted_tls_1_0_cipher_suites":[] }, "tls_1_1":{ "preferred_cipher_suite":null, "accepted_tls_1_1_cipher_suites":[] }, "tls_1_2":{ "preferred_cipher_suite":"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", "accepted_tls_1_2_cipher_suites":[ "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256", "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384", "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA" ] }, "tls_1_3":{ "preferred_cipher_suite":"TLS_AES_256_GCM_SHA384", "accepted_tls_1_3_cipher_suites":[ "TLS_CHACHA20_POLY1305_SHA256", "TLS_AES_256_GCM_SHA384", "TLS_AES_128_GCM_SHA256", "TLS_AES_128_CCM_SHA256", "TLS_AES_128_CCM_8_SHA256" ] }, "tests":{ "compression_supported":false, "accepts_early_data":false, "http_headers":{ "strict_transport_security_header":{ "preload":false, "include_subdomains":true, "max_age":15768000 } } }, "scan_information":{ }, "tls_recommendations":{ } }, "dns":{ "Connection":"example.com", "dns_recommendations":{ "Low - CAA":"Consider creating DNS CAA records to prevent accidental or malicious certificate issuance." }, "records":{ "A":[ "104.127.16.98" ], "CAA":[], "TXT":[], "MX":[] } }, "http2":{ "http2":false } } Advanced Cryptonice use - Calling specific modules There are 6 files in Cryptonice that are necessary for its functioning in other code. scanner.py and checkport.py live in the Cryptonice folder, and getdns.py, gethttp.py. gethttp2.py and gettls.py all live in the cryptonice/modules folder. A full scan is run out of the scanner_driver function in scanner.py, which generates a dictionary object based on the commands it receives via the input parameter dictionary. scanner_driver is modularized, allowing you to call as many or as few of the modules as needed for your purposes. However, if you would like to customize the use of the cryptonice library further, individual modules can be selected and run as well. You may choose to call the scanner_driver function and have access to all the modules in one location, or you could call on certain modules while excluding others. Here is an example of a function that calls the tls_scan function in modules/gettls.py to specifically make use of the TLS code and none of the other modules. from cryptonice.modules.gettls import tls_scan def tls_info(): ip_address = "172.217.12.196" host = "www.google.com" commands = ["certificate_info"] port = 443 tls_data = tls_scan(ip_address, host, commands, port) cert_0 = tls_data.get("certificate_info").get("certificate_0") # Print certificate information print(f'Common Name:\t\t\t {cert_0.get("common_name")}') print(f'Public Key Algorithm:\t\t {cert_0.get("public_key_algorithm")}') print(f'Public Key Size:\t\t {cert_0.get("public_key_size")}') if cert_0.get("public_key_algorithm") == "EllipticCurvePublicKey": print(f'Curve Algorithm:\t\t {cert_0.get("curve_algorithm")}') print(f'Signature Algorithm:\t\t {cert_0.get("signature_algorithm")}') if __name__ == "__main__": tls_info() Getting Started The modularity of Cryptonice makes it a versatile tool to be used within other projects. Whether you want to use it to test the strength of an internal website using the command line tool or integrate the modules into another project, Cryptonice provides a detailed and easy way to capture certificate information, HTTP headers, DNS restrictions, TLS configuration and more. We plan to add additional modules to query certificate transparency logs, test for protocols such as HTTP/3 and produce detailed output with guidance on how to improve your cryptographics posture on the web. This is version 1.0, and we encourage the submission of bugs and enhancements to our Github page to provide fixes and new features so that everyone may benefit from them. The Cryptonice code and binary releases are maintained on the F5 Labs Github pages. Full documentation is currently being added to our ReadTheDocs page and the Cryptonice library is available on PyPi.: F5 Labs overview: https://www.f5.com/labs/cryptonice Source and releases: https://github.com/F5-Labs/cryptonice PyPi library: https://pypi.org/project/cryptonice Documentation: https://cryptonice.readthedocs.io
F5 Labs 2019 TLS Telemetry Report Summary
Encryption standards are constantly evolving, so it is important to stay up to date with best practices. The 2019 F5 Labs TLS Telemetry Summary Report by David Warburton with additional contributions from Remi Cohen and Debbie Walkowski expands the scope of our research to bring you deeper insights into how encryption on the web is constantly evolving. We look into which ciphers and SSL/TLS versions are being used to secure the Internet’s top websites and, for the first time, examine the use of digital certificates on the web and look at supporting protocols (such as DNS) and application layer headers. On average, almost 86% of all page loads over the web are now encrypted with HTTPS. This is a win for consumer privacy and security, but it’s also posing a problem for those scanning web traffic. In our research we found that 71% of phishing sites in July 2019 were using secure HTTPS connections with valid digital certificates. This means we have to stop training users to “look for the HTTPS at the start of the address” since attackers are using deceptive URLs to emulate secure connections for their phishing and malware sites. Read our report for details and recommendations on how to bolster your HTTPS connections.Post of the Week: SSL on a Virtual Server
In this Lightboard Post of the Week, I answer a few questions about SSL/https on Virtual Servers. BIG-IP being a default deny, full proxy device, it's important to configure specific ports, like 443, to accept https traffic along with client and server side profiles and include your SSL certificates. We cover things like SAN certificates but I failed to mention that self-signed certificates are bad anywhere except for testing or on the server side of the connection. Thanks to DevCentral members, testimony, Only1masterblaster, Faruk AYDIN, MrPlastic, Tyler G, Prince, and dward for their Q/A engagement. Posted Questions on DevCentral: https on virtual server LINKING SSL CERTIFICATE TO A VIRTUAL SERVER SSL CERTIFICATE KEY Maximum number of client SSL profiles per virtual server? Need to support thousands of unique SSL certificates on a single VIP psHow to deploy more SSL sites with fewer SSL certificates
There is an increasing need to deploy SSL sites (SPDY, HTTP/2, and SSL Everywhere). Traditional SSL sites require deploying one SSL certificate per site. This gets very expensive ordering and maintaining many SSL certificates. Consolidating SSL resources by utilizing wildcard and Subject Alternative Names (SAN) certificates reduces the maintenance and cost of deploying SSL sites. SSL Review A quick review on how SSL works. You type a name into your web browser (i.e. www.mycompany.example), the web browser connects and verifies that the certificate that is presented is signed by a trusted party and that the name matches the requested name. Should any of these checks fail, you get a nasty-gram from your browser. In the past this required a single SSL certificate per IP address, but Server Name Indication (SNI) makes it possible to attach multiple SSL certificates to a single IP address as long as the client supports SNI. Traditional Cert A traditional certificate only contains a single name. store.mycompany.example Wildcard Certs A wildcard cert replaces a single name with a wildcard character. Browsers will treat the “*” character as any valid name. *.blog.mycompany.example Subject Alternative Names SAN cert are similar to a traditional SSL cert with the added bonus that you can provide a list of “alternative” names that are valid. For example a SAN cert could be limited to only the following names www.hr.mycompany.example benefits.hr.mycompany.example jobs.hr.mycompany.example What type of cert to use These examples highlight my recommendations for what type of certificate to use. Sites that transact sensitive date (i.e. SSN or CCN) should have their own certificate. Sites that have a low level of security and a high number of names would benefit from a wildcard certificate. A middle ground would be a SAN certificate. When using SAN certs it is best to group together by organization or security classification. How to consolidate services The above should help in reducing the number of certificates that you have. If you want to further reduce the number of IP addresses that you’re using for your sites please read my companion article on Routing HTTP by request headers. There's also another DevCentral article about SSL Profiles that you can learn more about SSL.
Dispelling the New SSL Myth
Claiming SSL is not computationally expensive is like saying gas is not expensive when you don’t have to drive to work every day. My car is eight years old this year. It has less than 30,000 miles on it. Yes, you heard that right, less than 30,000 miles. I don’t drive my car very often because, well, my commute is a short trip down two flights of stairs. I don’t need to go very far when I do drive it’s only ten miles or so round trip to the grocery store. So from my perspective, gas isn’t really very expensive. I may use a tank of gas a month, which works out to … well, it’s really not even worth mentioning the cost. But for someone who commutes every day – especially someone who commutes a long-distance every day – gas is expensive. It’s a significant expense every month for them and they would certainly dispute my assertion that the cost of gas isn’t a big deal. My youngest daughter, for example, would say gas is very expensive – but she’s got a smaller pool of cash from which to buy gas so relatively speaking, we’re both right. The same is true for anyone claiming that SSL is not computationally expensive. The way in which SSL is used – the ciphers, the certificate key lengths, the scale – has a profound impact on whether or not “computationally expensive” is an accurate statement or not. And as usual, it’s not just about speed – it’s also about the costs associated with achieving that performance. It’s about efficiency, and leveraging resources in a way that enables scalability. It’s not the cost of gas alone that’s problematic, it’s the cost of driving, which also has to take into consideration factors such as insurance, maintenance, tires, parking fees and other driving-related expenses. MYTH: SSL is NOT COMPUTATIONALLY EXPENSIVE TODAY SSL is still computationally expensive. Improvements in processor speeds in some circumstances have made that expense less impactful. Circumstances are changing. Commoditized x86 hardware can in fact handle SSL a lot better today than it ever could before –when you’re using 1024-bit keys and “easy” ciphers like RC4. Under such parameters it is true that commodity hardware may perform efficiently and scale up better than ever when supporting SSL. Unfortunately for proponents of SSL-on-the-server, 1024-bit keys are no longer the preferred option and security professionals are likely well-aware that “easy” ciphers are also “easy” pickings for miscreants. In January 2011, NIST recommendations regarding the deployment of SSL went into effect. While NIST is not a standards body can require compliance or else, they can and do force government and military compliance and have shown their influence with commercial certificate authorities. All commercial certificate authorities now issue only 2048-bit keys. This increase has a huge impact on the capacity of a server to process SSL and renders completely inaccurate the statement that SSL is not computationally expensive anymore. A typical server that could support 1500 TPS using 1024-bit keys will only support 1/5 of that (around 300 TPS) when supporting modern best practices, i.e. 2048-bit keys. Also of note is that NIST recommends ephemeral Diffie-Hellman - not RSA - for key exchange, and per TLS 1.0 specification, AES or 3DES-EDE-CBC, not RC4. These are much less “easy” ciphers than RC4 but unfortunately they are also more computationally intense, which also has an impact on overall performance. Key length and ciphers becomes important to the performance and capacity of SSL not just during the handshaking process, but in bulk-encryption rates. It is one thing to say a standard server deployed to support SSL can handle X handshakes (connections) and quite another to simultaneously perform bulk-encryption on subsequent data responses. The size and number of those responses have a huge impact on the consumption rate of resources when performing SSL-related functions on the overall server’s capacity. Larger data sets require more cryptographic attention that can drag down the rate of encryption – that means slower response times for users and higher resource consumption on servers, which decreases resources available for handshaking and server processing and cascades throughout the entire system to result in a reduction of capacity and poor performance. Tweaked configurations, poorly crafted performance tests, and a failure to consider basic mathematical relationships may seem to indicate SSL is “not” computationally expensive yet this contradicts most experience with deploying SSL on the server. Consider this question and answer in the SSL FAQ for the Apache web server: Why does my webserver have a higher load, now that it serves SSL encrypted traffic? SSL uses strong cryptographic encryption, which necessitates a lot of number crunching. When you request a webpage via HTTPS, everything (even the images) is encrypted before it is transferred. So increased HTTPS traffic leads to load increases. This is not myth, this is a well-understood fact – SSL requires higher computational load which translates into higher consumption of resources. That consumption of resources increases with load. Having more resources does not change the consumption of SSL, it simply means that from a mathematical point of view the consumption rates relative to the total appear to be different. The “amount” of resources consumed by SSL (which is really the amount of resources consumed by cryptographic operations) is proportional to the total system resources available. The additional consumption of resources from SSL is highly dependent on the type and size of data being encrypted, the load on the server from both processing SSL and application requests, and on the volume of requests. Interestingly enough, the same improvements in capacity and performance of SSL associated with “modern” processors and architecture is also applicable to intermediate SSL-managing devices. Both their specialized hardware (if applicable) and general purpose CPUs significantly increase the capacity and performance of SSL/TLS encrypted traffic on such solutions, making their economy of scale much greater than that of server-side deployed SSL solutions. THE SSL-SERVER DEPLOYED DISECONOMY of SCALE Certainly if you have only one or even two servers supporting an application for which you want to enable SSL the costs are going to be significantly different than for an organization that may have ten or more servers comprising such a farm. It is not just the computational costs that make SSL deployed on servers problematic, it is also the associated impact on infrastructure and the cost of management. Reports that fail to factor in the associated performance and financial costs of maintaining valid certificates on each and every server – and the management / creation of SSL certificates for ephemeral virtual machines – are misleading. Such solutions assume a static environment and a deep pocket or perhaps less than ethical business practices. Such tactics attempt to reduce the capital expense associated with external SSL intermediaries by increasing the operational expense of purchasing and managing large numbers of SSL certificates – including having a ready store that can be used for virtual machine instances. As the number of services for which you want to provide SSL secured communication increase and the scale of those services increases, the more costly it becomes to manage the required environment. Like IP address management in an increasingly dynamic environment, there is a diseconomy of scale that becomes evident as you attempt to scale the systems and processes involved. DISECONOMY of SCALE #1: CERTIFICATE MANAGEMENT Obviously the more servers you have, the more certificates you need to deploy. The costs associated with management of those certificates – especially in dynamic environments – continues to rise and the possibility of missing an expiring certificate increase with the number of servers on which certificates are deployed. The promise of virtualization and cloud computing is to address the diseconomy of scale; the ability to provision and ready-to-function server complete with the appropriate web or application stack serving up an application for purposes of scale assumes that everything is ready. Unless you’re failing to properly provision SSL certificates you cannot achieve this with a server-deployed SSL strategy. Each virtual image upon which a certificate is deployed must be pre-configured with the appropriate certificate and keys and you can’t launch the same one twice. This has the result of negating the benefits of a dynamically provisioned, scalable application environment and unnecessarily increases storage requirements because images aren’t small. Failure to recognize and address the management and resulting impact on other areas of infrastructure (such as storage and scalability processes) means ignoring completely the actual real-world costs of a server-deployed SSL strategy. It is always interesting to note the inability of web servers to support SSL for multiple hosts on the same server, i.e. virtual hosts. Why can't I use SSL with name-based/non-IP-based virtual hosts? The reason is very technical, and a somewhat "chicken and egg" problem. The SSL protocol layer stays below the HTTP protocol layer and encapsulates HTTP. When an SSL connection (HTTPS) is established Apache/mod_ssl has to negotiate the SSL protocol parameters with the client. For this, mod_ssl has to consult the configuration of the virtual server (for instance it has to look for the cipher suite, the server certificate, etc.). But in order to go to the correct virtual server Apache has to know the Host HTTP header field. To do this, the HTTP request header has to be read. This cannot be done before the SSL handshake is finished, but the information is needed in order to complete the SSL handshake phase. Bingo! Because an intermediary terminates the SSL session and then determines where to route the requests, a variety of architectures can be more easily supported without the hassle of configuring each and every web server – which must be bound to IP address to support SSL in a virtual host environment. This isn’t just a problem for hosting/cloud computing providers, this is a common issue faced by organizations supporting different “hosts” across the domain for tracking, for routing, for architectural control. For example, api.example.com and www.example.com often end up on the same web server, but use different “hosts” for a variety of reasons. Each requires its own certificate and SSL configuration – and they must be bound to IP address – making scalability, particularly auto-scalability, more challenging and more prone to the introduction of human error. The OpEx savings in a single year from SSL certificate costs alone could easily provide an ROI justification for the CapEx of deploying an SSL device before even considering the costs associated with managing such an environment. CapEx is a onetime expense while OpEx is recurring and expensive. DISECONOMY of SCALE #2: CERTIFICATE/KEY SECURITY The simplistic nature of the argument also fails to take into account the sensitive nature of keys and certificates and regulatory compliance issues that may require hardware-based storage and management of those keys regardless of where they are deployed (FIPS 140-2 level 2 and above). While there are secure and compliant HSM (Hardware Security Modules) that can be deployed on each server, this requires serious attention and an increase of management and skills to deploy. The alternative is to fail to meet compliance (not acceptable for some) or simply deploy the keys and certificates on commoditized hardware (increases the risk of theft which could lead to far more impactful breaches). For some IT organizations to meet business requirements they will have to rely on some form of hardware-based solution for certificate and key management such as an HSM or FIPS 140-2 compliant hardware. The choices are deploy on every server (note this may become very problematic when trying to support virtual machines) or deploy on a single intermediary that can support all servers at the same time, and scale without requiring additional hardware/software support. DISECONOMY of SCALE #3: LOSS of VISIBILITY / SECURITY / AGILITY SSL “all the way to the server” has a profound impact on the rest of the infrastructure, too, and the scalability of services. Encrypted traffic cannot be evaluated or scanned or routed based on content by any upstream device. IDS and IPS and even so-called “deep packet inspection” devices upstream of the server cannot perform their tasks upon the traffic because it is encrypted. The solution is to deploy the certificates from every machine on the devices such that they can decrypt and re-encrypt the traffic. Obviously this introduces unacceptable amounts of latency into the exchange of data, but the alternative is to not scan or inspect the traffic, leaving the organization open to potential compromise. It is also important to note that encrypted “bad” traffic, e.g. malicious code, malware, phishing links, etc… does not change the nature of that traffic. It’s still bad, it’s also now “hidden” to every piece of security infrastructure that was designed and deployed to detect and stop it. A server-deployed SSL strategy eliminates visibility and control and the ability to rapidly address both technical and business-related concerns. Security is particularly negatively impacted. Emerging threats such as a new worm or virus for which AV scans have not yet but updated can be immediately addressed by an intelligent intermediary – whether as a long-term solution or stop-gap measure. Vulnerabilities in security protocols themselves, such as the TLS man-in-the-middle attack, can be immediately addressed by an intelligent, flexible intermediary long before the actual solutions providing the service can be patched and upgraded. A purely technical approach to architectural decisions regarding the deployment of SSL or any other technology is simply unacceptable in an IT organization that is actively trying to support and align itself with the business. Architectural decisions of this nature can have a profound impact on the ability of IT to subsequently design, deploy and manage business-related applications and solutions and should not be made in a technical or business vacuum, without a full understanding of the ramifications. The Anatomy of an SSL Handshake [Network Computing] Get Ready for the Impact of 2048-bit RSA Keys [Network Computing] SSL handshake latency and HTTPS optimizations [semicomplete.com] Black Hat: PKI Hack Demonstrates Flaws in Digital Certificate Technology [DarkReading] SSL/TLS Strong Encryption: FAQ [apache.org] The Open Performance Testing Initiative The Order of (Network) Operations Congratulations! You do no nothing faster than anyone else! Data Center Feng Shui: SSL WILS: SSL TPS versus HTTP TPS over SSL F5 Friday: The 2048-bit Keys to the Kingdom TLS Man-in-the-Middle Attack Disclosed Yesterday Solved Today with Network-Side Scripting
