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.
SSL & persistence configurations from qkview or UCS files
Is there any quick way to extract (into, for example, an Excel file) the following configuration details from qkview or UCS files? 1. list of SSL certificates, including: - SSL certificate expiration status / dates - which virtual servers or SSL profiles are using each SSL certificate 2. list of persistence configurations
What Certificates should be where? GSLB Trust Certificates vs Device Trusted Certificates
Hi All, My setup consists of two DC's with Two GTM's (Active/Standby) and Two LTM's (Active/Standby) in each DC. Within the GSLB Trusted Certificate Store, there are certs for each others devices, which I believe is the correct setup. (Each device has 8 certs, of its other devices)… However I am not sure about what should be in the "System - Certificate Management - Device Certificate Management - Device Trust Certificates store. (This is a bit of a mess, some devices have each others, some don't etc. Would like to have this cleaned up. For ease of description will refer to items as the following : - DC1GTMA - DC1 Active GTM DC1GTMS - DC1 Standby GTM DC1LTMA - DC1 Active LTM DC1LTMS - DC1 Standby LTM DC2GTMA - DC2 Active GTM DC2GTMS - DC2 Standby GTM DC2LTMA - DC2 Active LTM DC2LTMS - DC2 Standby LTM The four GTM's are in a device sync group "DNS - Settings - GSLB - General"...so when you make a change on one GTM, its replicated across all of them. Would this come under IQUERY and thus come under the GSLB Trusted Certificate store, or is this under the Device Trust Store? Hope the above makes sense. Thanks
Problem with C3D - Client Certificate Constrained Delegation
Hi all, We have been using C3D in a public facing web app several years now having no issues. Clients use their certificates from many different CAs to login into the app and when somebody has a certificate from a different CA we add that CA to a list of trusted and allowed CAs that users can use certificates to log in form. The internal CA that we use to forge client certificates and pass them to the node uses sha256RSA as sign algorithm and sha256 as hash signature algorithm. We had to add a new allowed CA that client will use certificates to connect from but uses sha512ECDSA as sign algorithm and sha512 as hash signature algorithm and when someone uses a client certificate of this CA to try to connect to our application TLS connection breaks with "Alert (Level: Fatal, Description: Handshake Failure)" ¿Has anyone enncountered a similar issue? Thank you.INFORM: Entrust CA will be untrusted in Chrome after Oct 31, 2024
If you manage certs from Entrust in your environment, this will impact your Google Chrome users, so intermediate certs will likely need to be bundled to handle this in your clientssl profiles OR if you control all the clients you can assure that explicit trust in the clients is enabled for Entrust CAs. Google details on the situation
Unable to login with Certificate Manager local user
I've created a local user account with the Certificate Manager role on All partitions - and have enabled tmsh access. However, when I attempt to login with this account - either GUI or SSH - I am receiving a login failed message. We don't have any password enforcement in place and access restrictions are tied to the RFC1918 address space, so that is not coming into play. We have remote auth (TACACS) enabled with fallback to local and other local accounts are able to login successfully. Thoughts? Version: 17.1.1.2 Username - cert-mgr Role - Certificate Manager Partition: All Terminal Access: tmsh Wed Sep 11 10:51:20 CDT 2024 cert-mgr 0-0 httpd(pam_audit): User=cert-mgr tty=(unknown) host=x.x.x.x failed to login after 1 attempts (start="Wed Sep 11 10:51:18 2024" end="Wed Sep 11 10:51:20 2024").: Wed Sep 11 11:00:20 CDT 2024 cert-mgr 0-0 httpd(pam_audit): User=cert-mgr tty=(unknown) host=x.x.x.x failed to login after 1 attempts (start="Wed Sep 11 11:00:18 2024" end="Wed Sep 11 11:00:20 2024").:
