CertSecure Manager 3.3 Is Here, and It Lands Right When You Need It Most 

If you’ve been anywhere near the certificate management conversation in the past year, you already know that the ground is shifting. Public TLS certificate lifetimes, the cornerstone of how the web has worked for over a decade, are being aggressively shortened. The era of “renew it once a year and forget about it” is officially over. 

CertSecure Manager v3.3 is our release for this new reality. It’s a deliberate set of changes designed to help your team survive, and ideally thrive, in a world where certificates expire every few weeks instead of every 13 months. Let’s walk through what’s changed, what it means for your operations, and why we built each piece the way we did. 

CertSecure Manager v3.3 is built for one industry reality: TLS certificate lifetimes are dropping from 398 days to 47 days over the next three years, and manual certificate management cannot survive that pace. The release ships 18 new features and enhancements aimed at the higher renewal cadence. 

The headline additions are a Certificate Risk Profile that scores every cert in your inventory, full trust chain visualization, bulk revocation and bulk ownership transfer, zero-touch renewal across all web server agents, native Google Public CA and ServiceNow integrations, expanded Azure Key Vault support including Government tenants, AWS and IIS CCS discovery, and an Ansible ACME automation path. If you operate TLS certificates at any meaningful scale, this release is built for the world you’re heading into. 

The 47-day shift

On April 11, 2025, the CA/Browser Forum, the industry body that sets the rules every major browser and CA follows, passed Ballot SC-081v3, a proposal originally put forward by Apple and endorsed by Sectigo, Google Chrome, and Mozilla. The ballot passed 29 to 0 with five abstentions. All four major browser vendors (Apple, Google, Microsoft, and Mozilla) voted in favor, alongside 25 certificate authorities, including DigiCert, Sectigo, GlobalSign, GoDaddy, and Amazon. Five CAs abstained, noting concerns about operational readiness.

The ballot phases TLS certificate lifetimes down from today’s 398-day maximum to just 47 days by 2029. The schedule looks like this: 

• March 15, 2026: Maximum TLS certificate lifetime drops to 200 days, with Domain Control Validation reuse dropping to 200 days as well. 
• March 15, 2027: Maximum lifetime drops to 100 days, with DCV reuse dropping to 100 days. 
• March 15, 2029: Maximum lifetime drops to 47 days, and the DCV reuse period drops to just 10 days.

We’re already past the first milestone. The 200-day cap is in effect right now. 

Why 47 specifically? It works out to one 31-day month, plus half of a 30-day month, plus one day of wiggle room. Enough to support a sensible monthly renewal cadence without being so tight that operators have no margin.

What this actually means for your team 

The math is the part that wakes people up at night. An organization managing 1,000 certificates will be looking at roughly 7,766 renewal operations per year under the 47-day model. That’s about 21 every single day, an eightfold increase over today’s renewal frequency. 

Spreadsheets, calendar reminders, “Bob handles that.” None of it scales. The CA/Browser Forum hasn’t been subtle about this: the inconvenience is deliberate, because the industry consensus is that automation is no longer optional for the security of the internet. 47-day certificates are how that message stops being optional. 

There are three real reasons behind the shortening. 

• Limiting blast radius: If a private key is compromised, a 398-day cert gives the attacker over a year of usable misuse. A 47-day cert gives them weeks at most. 
• Working around broken revocation: The ballot includes a long argument that the certificate revocation system using CRLs and OCSP is unreliable, with browsers often ignoring these features. Short lifetimes are a more honest mechanism than revocation that doesn’t actually revoke. 
• Crypto agility for the quantum era: Shorter lifetimes make “capture now, decrypt later” tactics harder for adversaries, and they speed transitions to new cryptographic algorithms when needed. NIST finalized its first post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) in 2024, and public CAs are already piloting issuance. Migration off RSA and ECDSA is no longer distant. A fleet of certs that already renews every six weeks adapts faster than one that renews every thirteen months. 

CertSecure Manager 3.3 was built with all three of these realities in front of us. Here’s how that shows up in the release.

See risk before it sees you

If you’re going to renew certificates eight times more often, you need a dashboard that actually tells you which certificates are problems before they become incidents. Three changes in 3.3 work together to give you that. 

Certificate Risk Profile 

 Every certificate in your inventory is now automatically scored against a Risk Profile, with the score surfaced as a column in your inventory listings and as a filter in Certificate Search. The scoring looks at three signals that historically have been the source of most pain in certificate management:

• Key length: Flagging weak RSA keys, deprecated ECDSA curves, and anything below current industry baselines. 
• Signature algorithm: Surfacing SHA1 holdouts, weak hashes, and anything that won’t survive the next deprecation wave. 
• Validity period: Important now more than ever, as the industry walks down the 398 to 200 to 100 to 47-day ladder. 

Certificates are bucketed into four levels: Secure, Low Risk, High Risk, and Severe. Filtering, sorting, and reporting on these levels means you can ask the question “show me every Severe cert in production” and get an answer in seconds rather than after a discovery script and an Excel pivot. It also gives you the ammunition you need when an auditor asks how you’re managing cryptographic risk. 

Certificate Trust Chain Visualization 

When a TLS handshake fails, the cause is often something boring involving the chain. A missing intermediate, a chain in the wrong order, a stale root. CertSecure now visualizes the full trust chain for every managed certificate, directly from the certificate details view.

Root and intermediate certs are accessible inline, with each chain element clickable so you can drill into metadata without leaving the screen. For third-party certificates, the system supports building and downloading the full chain, so you stop chasing intermediates across CA portals when you need to deploy somewhere new.

CA pinging and system metrics

Two often overlooked features round out the visibility story. A new CA pinging capability on the CA Management page lets you monitor whether each connected CA is actually reachable and healthy. This is useful both for diagnosing failed enrollments and for proactively spotting CA outages before users do.

And the new Metrics tab in Settings gives you real-time CPU, disk, and RAM monitoring for every CertSecure component: Automation Agents, CA Connectors, and Manager nodes alike. You can add or remove machines from the view to focus on what matters to your environment. When automation is the backbone of your renewal strategy, knowing the backbone is healthy is non-negotiable. 

Survive the renewal cadence with bulk operations

Two long-requested features land in 3.3, and together they will probably be the single biggest day one productivity win for most teams. 

Bulk Revocation 

You can now revoke many certificates at once in a single operation. The use cases are obvious if you’ve ever lived through them. 

• Key compromise events: If an HSM or key store is breached, you need to revoke fast and comprehensively, not one cert at a time. 
• CA distrust events: If a CA gets pulled from a root store (it happens, ask anyone who lived through DigiNotar, Symantec, or any of several more recent examples), you need to clear the affected certs immediately. 
• Routine cleanup: Stale test certs, retired services, old environments. Bulk revoke them and move on. 

Bulk Ownership Transfer 

Certificate ownership records drift constantly. People leave, teams reorganize, and applications get reassigned. In 3.3, you can transfer ownership in bulk across many certificates at once. This is the kind of feature that sounds small until you’ve spent two days clicking through individual cert records to update the owner email after a reorg. 

Both of these features were already useful in a 398-day world. In a 47-day world, they’re table stakes. 

Automation that covers the platforms most tools forget 

Automation only works if it works everywhere, and historically, automation tools have been very strong for the easy targets and very weak for the awkward ones. CertSecure 3.3 closes some of the most requested gaps. 

Renewal automation for Citrix NetScaler, JBoss EAP, and Wildfly 

End-to-end certificate renewal automation now extends to Citrix NetScaler, JBoss EAP, and Wildfly. Crucially, the automation handles chain certificate retrieval as part of the renewal flow, so the agent grabs the right intermediates and pushes them into the correct keystore or configuration without users having to download chain bundles separately and stitch them in by hand. That last detail matters more than it sounds: chain misconfiguration is one of the most common causes of failed deployments. 

Zero-touch renewal across all web server agents

All CertSecure web server renewal agents now support zero-touch renewal. That means a certificate renewal can flow from CA enrollment through delivery, installation, and service reload with no human in the loop. That is the only sustainable model when you’re renewing every six or seven weeks.

Ansible Desired State Management with the ACME module

For environments that prefer infrastructure as code, 3.3 introduces a new automation path using the Ansible ACME module. You declare the desired state of your certificates in your Ansible configuration, and the system handles obtaining and renewing TLS certificates from any ACME-compatible CA, keeping the actual deployed state aligned with the declared one. It’s the right pattern for teams already running Ansible at scale. 

Meet certificates wherever they live 

CertSecure 3.3 expands the universe of CAs, vaults, and systems you can manage natively.

Google Public CA integration 

Google Public CA is now a first-class integrated CA. Full lifecycle management (issuance, renewal, revocation, inventory) works against Google Public CA just like it does against your other CAs. For organizations using GCP services or wanting an additional public CA option, this removes a meaningful integration gap. 

ServiceNow app, now in the store 

The CertSecure Certificate Management app for ServiceNow is now available in the official ServiceNow store. This is a much bigger deal than it sounds: most enterprise certificate workflows are already gated through ITSM ticket flows. The integration lets users request, enroll, generate, and download certificates from inside their existing ServiceNow workflow rather than learning a new portal. Less friction, faster fulfillment, fewer tickets that sit waiting because someone didn’t know which tool to open.

Azure Key Vault: Government tenants and one-click upload 

Azure Key Vault support has been extended in two important directions. 

• Government tenants are now supported, with full Role-Based Access Control (RBAC) for cert uploads. This is critical for regulated and public sector customers operating in Azure Government. 
• One-click upload lets you push certificates into Azure Key Vault either at the moment of enrollment or for any already enrolled certificate. What used to be a multi-step manual handoff is now a button. 

DigiCert: custom validity periods

DigiCert customers can now specify a custom validity period at enrollment. A small change, frequently requested, and particularly relevant as the industry walks lifetimes down in phases. “Fit my renewal to my deployment window” is becoming a more nuanced decision.  

Discovery without the manual hunt 

You can’t manage what you can’t find. CertSecure 3.3 makes two notable expansions. 

• AWS Cloud Discovery is now enabled. Certificates living in AWS, including ACM, IAM, and load balancers, can be brought into CertSecure inventory automatically rather than tracked separately. 
• IIS CCS Store Discovery is now supported. For Windows heavy environments using the IIS Centralized Certificate Store, certificates in CCS shares can now be inventoried natively. 

Once certificates are in inventory, third party certificates now appear in their own visible container under Inventory → CertSecure, filterable via the Cert Type filter. You can run the same operations on them that you would on internally managed certs: download, view chain, deliver via email, switch containers. This closes one of the recurring gaps in cert management. Specifically, the “we have some certs from outside CAs, and we sort of track them in a different spreadsheet” problem. 

Reporting also picks up a new Template filter on Inventory and Expiration reports, so you can slice your inventory by certificate template. This is useful for environments with many templates serving different purposes, where “all my web server template certs expiring in 30 days” is the question you actually want to ask. 

And if you’ve ever spent ten minutes hunting through documentation pages for one specific section, the UI documentation now has a search built in. 

Smoother enrollment moments 

A couple of smaller but genuinely useful changes. 

PFX download with private key upload for CSR enrollment. When you enroll via CSR, you can now upload your private key during the enrollment flow and have CertSecure generate a downloadable PFX file. For destinations that need PFX (and there are still many), this saves a separate openssl step on your laptop. 

DigiCert certificate delivery via email has been fixed for a known edge case, and a handful of additional enrollment path bugs have been cleared out. The “ignore template” behavior has been corrected as well. 

What’s next 

A quick note on where we’re heading, because the work doesn’t stop with this release.

Continued automation depth is the biggest theme. As 100-day certificates become the standard in March 2027, we’ll be adding more deployment targets and more sophisticated orchestration patterns. If there’s a platform in your stack we don’t yet automate, tell us. That feedback shapes the roadmap. 

Post-quantum cryptography readiness is the second. The risk profile, zero-touch renewal, and orchestration foundation in 3.3 are what make a future PQC migration tractable. When you can renew an entire fleet automatically, swapping algorithms becomes a configuration change rather than a multi-quarter project. Explicit PQC capabilities are work in flight, and we’ll share more in upcoming releases as the public CA ecosystem standardizes its PQC issuance practices. 

Discovery expansion is the third. AWS Cloud Discovery and IIS CCS join the discovery roster in 3.3, but there are more cloud and on-prem certificate stores to cover. We’re working through them. 

How to upgrade 

CertSecure Manager v3.3 is available now. If you’re already on a recent release, the upgrade path is straightforward. Your Encryption Consulting account team can walk you through environment-specific considerations and any sequencing for HA deployments. 

If you’re not yet on CertSecure Manager, the timing is genuinely worth thinking about. The shift from 200-day to 100-day certificates lands in March 2027, less than a year out. Organizations that wait until 47-day certificates are actually mandated in 2029 to start automating will be doing it under fire. Organizations that build a working automation foundation now, through the 200-day and 100-day phases, will arrive at 2029 with infrastructure that already works. 

If any of the features above sound like they solve a problem you’ve been living with, reach out to the Encryption Consulting team for a walkthrough of your environment. 

And, as always, thank you to every customer who filed a ticket, asked the hard question, or insisted the existing workaround wasn’t acceptable. Most of what’s in 3.3 traces back to you.