Two new CA connectors: bring GlobalSign and EJBCA into Sectigo Certificate Manager

Sectigo Certificate Manager (SCM) now connects to two more certificate authorities: GlobalSign and EJBCA. The new Sectigo CA Connectors bring the certificates you already rely on into one inventory, one policy set, and one automation model, alongside the rest of your certificate estate.

More CAs means uptime is built in

Certificate authorities (CAs) rarely make headlines, which is exactly why so many organizations treat their CA as a fixed point in their infrastructure rather than a dependency that can fail. The recent eMudhra situation shows how quickly that assumption can be tested. On October 17, 2026, a researcher reported an issue affecting eight of eMudhra’s intermediate authorities, and Chrome blocked the six used for TLS that same evening. Within days, Chrome announced it would distrust eMudhra’s ECC G3 root from October 27, and on October 22, eMudhra announced that its board had decided to withdraw from the global SSL/TLS certificate business. eMudhra estimates about 30,000 certificates need migration, which means thousands of certificate owners are now facing an unplanned replacement project on someone else’s timeline.  

The lesson isn’t about any single provider. It’s that browser root programs can act within hours, and when they do, every certificate chaining to an affected hierarchy is suddenly a liability, regardless of how carefully its owner managed it. Organizations that rely on a single CA have no fallback in that moment: they must find, vet, and onboard a new provider while also locating every affected certificate and replacing it before outages begin. As certificate lifespans shrink toward 47 days, the window between “this is a problem” and “this is an outage” only gets shorter, and manual, single-vendor processes simply can’t absorb that kind of shock.

A multi-CA strategy turns a crisis into a routine switch. By maintaining relationships with more than one trusted CA, keeping a backup CA pre-authorized (including in your DNS CAA records, so it can issue for your domains immediately), and managing certificates through a CA-agnostic lifecycle management platform, organizations can redirect issuance and renewals without rebuilding their processes from scratch. Combined with full certificate visibility and automated renewal, CA redundancy means that when the next distrust event happens, and in a public trust ecosystem with dozens of CAs it eventually will, your response is a configuration change rather than a fire drill.  

That’s why Sectigo now offers even more CA connectors, so you can use Sectigo Certificate Manager to manage every certificate.

GlobalSign: every public certificate, run from one place

The Sectigo CA Connector for GlobalSign brings your GlobalSign certificates into SCM. Your team can find, issue, renew, and revoke them in the same workflows as every other public certificate you manage.

With GlobalSign in SCM, you can:

• Run one CLM across public CAs: GlobalSign, Sectigo, and other public certificates sit in one inventory, with clear ownership and policy controls.
• Automate for shorter lifespans: Consistent workflows replace CA-specific renewal processes, built for growing certificate volumes.
• Stay flexible across CAs: Keep existing CA relationships, with the option to shift selected issuance when your needs change.

That flexibility matters most when something goes wrong. If a CA change event forces you to move, you can shift issuance to another public CA without disrupting operations or rebuilding your workflows. If you'd rather move on your own timeline, you can transition selected issuance at your own pace while keeping visibility across both environments. 

EJBCA: keep your private PKI, drop the second CLM tool

Many teams manage EJBCA in one tool and public TLS/SSL certificates in another. That's two consoles, two policy sets, two renewal processes, and two contracts to justify. The reports never quite line up.

The Sectigo CA Connector for EJBCA brings your EJBCA-issued private certificates into SCM. Your EJBCA hierarchy stays exactly as it is. What changes is how you see, automate, and govern those certificates:

• One CLM for public and private: EJBCA and public TLS certificates in one inventory, under one policy set, with clear ownership, status, and reporting.
• Renewals that run on policy: Enroll through the protocols you already use and renew on policy, not on reminders.
• Governance with proof: Consistent policy and full audit trails across your whole estate.

For PKI teams, that opens up practical wins. Certificates for servers, devices, and DevOps pipelines can be issued and renewed automatically. You get a current view of EJBCA certificates and key types, so algorithm changes, including the move to post-quantum cryptography, start from facts. And you can modernize without migrating: automate EJBCA today, with the option to move workloads to additional CAs when you're ready.

Why a second CA is insurance, not overhead

Adding another CA to your certificate estate can sound like more work: another relationship, another set of certificates, another thing to track. In practice, it works like insurance. You hope you never need it, but when you do, it's the difference between a planned switch and a scramble.

CAs operate under strict, constantly evolving industry requirements, and those requirements are enforced. When a CA is distrusted, or has to revoke certificates at short notice, its customers can face replacing large numbers of certificates on a deadline they didn't choose. Teams with a second CA already connected, inventoried, and automated simply redirect issuance. Teams with one CA start from scratch, under pressure.

That insurance is worth more every year, because PKI is changing faster than ever:

• Shorter lifespans: As public TLS validity heads to 47 days by 2029, certificates renew roughly eight times a year. A disruption at one CA now affects renewals within days, not months.
• More machine identities: Servers, devices, workloads, and AI agents all depend on certificates, so a single point of failure touches more of the business than ever.
• The post-quantum transition: CAs will adopt new algorithms and standards on different timelines. With more than one CA, you can move at the pace your plan needs instead of waiting on a single roadmap.
• Frequent rule changes: CA/Browser Forum and root program updates land regularly. Redundancy keeps your options open as requirements shift.

The main reason teams avoid a multi-CA strategy is the extra management, and that's exactly what the new connectors remove. With every CA in SCM, a second CA doesn't mean a second console.

For public certificates, keep GlobalSign and add Sectigo as a second public CA. You avoid single-CA dependency and can move issuance between CAs without retooling.

For private certificates, pair EJBCA with Sectigo Private CA, which runs natively in SCM. Sectigo hosts and operates it, so you add resilience without adding infrastructure to maintain.

Both CAs run side by side under one inventory, one policy framework, and one automation workflow. The insurance is in place from day one, and you decide when, and how much, to shift. 

One platform for every certificate you trust

The GlobalSign and EJBCA connectors extend what SCM was built to do:

• CA agnostic by design: Manage certificates from Sectigo, GlobalSign, EJBCA, other public CAs, and private CAs in one platform.
• A unified certificate lifecycle: Apply consistent automation, policy, and governance across public and private environments.
• Ready for CA change: Add, replace, or transition between CAs without rebuilding operational processes.
• Simplicity at scale: Handle shorter lifespans, evolving standards, and the post-quantum transition from one place.

Bring every CA into one lifecycle

The Sectigo CA Connectors for GlobalSign and EJBCA are available now. To see how they fit your environment, talk to a Sectigo expert at [email protected] or explore all SCM integrations at sectigo.com/enterprise-solutions/certificate-manager/integrations.