Change Log

This page summarizes upcoming and recent changes that affect GeoCerts customers — including DigiCert, Sectigo, combined DigiCert/Sectigo, and GeoCerts product or documentation updates.

Upcoming changes

March 1, 2027

Removing the Client Authentication EKU from public TLS certificates

Important: Google Chrome updated their root program requirements and extended the timeline for this change. DigiCert (including GeoTrust and other DigiCert public TLS brands) will stop allowing the Client Authentication extended key usage (EKU) on public TLS certificates on ~March 1, 2027 (originally planned for May 1, 2026).

How DigiCert / GeoTrust works today

By default, newly issued DigiCert public TLS certificates include the Server Authentication EKU only.
To include both Server Authentication and Client Authentication EKUs, you must opt in at order time (and again at reissue time): on the order request form, choose Additional Options → Extended key usage (EKU) → Server Authentication and Client Authentication.
That dual-EKU override option goes away on ~March 1, 2027. After that date, DigiCert will issue public TLS certificates with the Server Authentication EKU only—no Client Authentication EKU opt-in.
Existing certificates issued with the Client Authentication EKU before that date remain trusted until they expire. Reissues, duplicates, and renewals after the cutoff will not include Client Authentication EKU.

Sectigo / PositiveSSL

Sectigo and PositiveSSL have already removed the dual EKU (Client Authentication + Server Authentication) from newly issued public TLS certificates. New Sectigo/PositiveSSL TLS certificates are issued with the Server Authentication EKU only.

What you need to do

Securing a website only: You don’t need to do anything.
DigiCert/GeoTrust for mTLS or client authentication: Plan a transition before ~March 1, 2027, when the dual-EKU override disappears. A primary alternative is DigiCert X9 PKI for TLS (see DigiCert X9 PKI for TLS below). Private PKI remains an option for internal-only needs.
Sectigo/PositiveSSL for client authentication: Dual-EKU public TLS certificates are no longer issued. Switch to a DigiCert/GeoTrust TLS product while the dual-EKU opt-in is still available (see above), or move to DigiCert X9 PKI for TLS for ongoing mTLS and client-auth needs (see DigiCert X9 PKI for TLS).

Why this change

This aligns with Google Chrome’s root program requirements to improve security and interoperability across public CAs.

For DigiCert details, options, and product links, see:
CertCentral Change Log – March 1, 2027.

September 15, 2026

CRL partitioning for public TLS certificates

On September 15, 2026, public DigiCert TLS certificates will use Certificate Revocation List Distribution Point (CRLDP) URLs that point to smaller, partitioned CRLs. Each partitioned CRL holds a subset of revocations for the issuing intermediate CA (about 9.5 MB each). Together, the partitions still cover all revoked certificates.

What you need to do

No action is required for typical HTTPS use. Browsers, operating systems, and other software usually handle revocation checking automatically.

For full details, see:
CertCentral Change Log – September 15, 2026.

Recent changes

July 11, 2026

Sandbox ACME Directory URLs

GeoCerts’ CertCommand management portal now supports Sandbox ACME Directory URLs for testing ACME automation without production charges or orders.

What’s new

When creating an ACME Directory URL, select Create sandbox ACME URL to connect to the GeoCerts ACME sandbox environment.
Sandbox URLs use the same EAB credential model as production URLs but issue short-lived test certificates (3-day validity, DV Flex products only).

Why this helps

New ACME users can validate EAB authentication, domain control validation (especially DNS credentials), and deployment on a web server—or their own deploy process for load balancers—before moving to a production ACME Directory URL.

Documentation

July 1, 2026

DigiCert ACME Client for CertCommand automation

GeoCerts recommends the DigiCert ACME Client (DAC) for ACME automation with CertCommand ACME Directory URLs. Use it to request, install, and renew DigiCert and GeoTrust certificates against the Directory URLs you create in CertCommand.

Why we recommend it

Built for DigiCert’s ACME backend and External Account Binding (EAB)
One CLI (dc-acme) for Linux and Windows
Runs as a managed service so renewals don’t depend on ad-hoc cron or Task Scheduler jobs when automation is enabled

Get started

Install the DigiCert ACME Client — install steps, verification, and next steps
Linux: curl "https://automation-service.digicert.com/dc-acme/linux/install.sh" | sudo bash
Windows (PowerShell as Administrator):
iex ((New-Object System.Net.WebClient).DownloadString('https://automation-service.digicert.com/dc-acme/windows/install.ps1')); Install-DigicertAcmeClient

Already using Certbot or Win-ACME? See Alternative ACME Clients.

June 15, 2026

DigiCert X9 PKI for TLS now available

GeoCerts now offers DigiCert X9 PKI for TLS—a DigiCert certificate product for host-to-host TLS use cases (such as mutual TLS / mTLS and API authentication) that need both Server Authentication and Client Authentication EKUs.

Unlike browser-trusted public TLS certificates, X9 PKI for TLS is governed by ASC X9 certificate policy and uses a common root of trust outside browser root programs. It is the DigiCert-recommended path when public TLS dual-EKU options go away (~March 1, 2027). See Removing the Client Authentication EKU.

Who it’s for

Organizations that use TLS certificates for mTLS, server-to-server authentication, or other non-browser client authentication
Multi-organization environments that need a shared, interoperable trust root (not only internal private PKI)

How to order

Learn more and order on GeoCerts: DigiCert X9 PKI for TLS. Questions about profiles, validation, or deployment? Contact GeoCerts support — we’re happy to help.

June 1, 2026

All public TLS certificates must be logged to CT logs

Starting June 1, 2026, DigiCert logs all public TLS certificates—including canaries and test certificates—to at least one Certificate Transparency (CT) log. This applies across DigiCert public TLS products and brands (including DigiCert, GeoTrust, Thawte, and RapidSSL).

This change mainly closes DigiCert’s former CT-logging opt-out for accounts that had turned logging off. It aligns with Google Chrome Root Program Policy, which requires CAs to log all public TLS certificates by mid-June 2026.

What you need to do

Most GeoCerts customers: No action is required. GeoCerts does not expose a CT-logging opt-out in the usual order path, and DigiCert logs public TLS certificates by default.
Certificates that must stay out of public CT logs need a private PKI path—not public trust.

For DigiCert’s full details, see:
CertCentral Change Log – June 1, 2026.

MPIC corroboration expanded (three, then four remote locations)

Multi-Perspective Issuance Corroboration (MPIC) helps stop attackers from tricking a certificate authority into issuing a certificate for a domain they don’t control—for example by manipulating internet routing (such as BGP hijacking). Under CA/Browser Forum rules, public CAs must now check domain control validation (DCV) and CAA results from multiple independent network locations, not just one vantage point. If those perspectives don’t agree, issuance stops.

DigiCert’s explanation: Multi-Perspective Issuance Corroboration for Digital Certificates.

DigiCert expanded the number of remote perspectives it uses to match the CA/Browser Forum phase schedule:

February 24, 2026: Corroboration from at least three remote network locations across at least two Regional Internet Registry regions.
June 1–14, 2026: Corroboration from at least four remote network locations across at least two regions.

What you need to do

MPIC applies to all common DCV methods DigiCert uses—including HTTP file/ACME HTTP-01 and DNS-based methods (DNS TXT, DNS CNAME, ACME DNS-01)—plus CAA checks.

If you use IP allowlists, geo-blocking, or other network filters on the systems DigiCert must reach for validation (web servers for HTTP DCV, or authoritative DNS for DNS DCV), allow DigiCert’s DCV/MPIC perspectives so checks from multiple locations can succeed.
If those endpoints are already reachable from the public internet without regional or IP restrictions, you likely need no changes—just expect DigiCert to corroborate the same DCV/CAA result from more remote locations than before.

For full details, see:
CertCentral Change Log – June 1, 2026 and
February 24, 2026.

May 15, 2026

G2/G3 ICA and cross-signed root revocations

On May 15, 2026, DigiCert revoked specific G2/G3 intermediate CA (ICA) certificates and certain G5 cross-signed roots as part of moving multipurpose G2/G3 roots to dedicated TLS hierarchies.

What’s important

End-entity certificates issued from revoked ICAs were not revoked, but they must be replaced—if the ICA in the trust chain is revoked, those end-entity certificates are no longer trusted.
Certificates that relied on an alternative trust path through a revoked cross-signed root can fail chain building after the revocation date.

What you need to do

Replace affected certificates so they chain to the current DigiCert intermediates/roots. Prefer DigiCert’s official lists of revoked ICAs and cross-signed roots when identifying impact.

For full details and replacement guidance, see:
CertCentral Change Log – May 15, 2026.

March 10, 2026

New dedicated IPv4 and IPv6 addresses

On March 10, 2026, DigiCert added dedicated IPv4 addresses and assigned new dedicated IPv6 addresses for specific services (including CertCentral-related platforms).

What you need to do

If you do not use IP allowlists: No action is required.
If you do: Update allowlists for DigiCert’s published certificate-status / service IP addresses so outbound traffic continues to work.

For the address lists and affected platforms, see DigiCert’s knowledge base and:
CertCentral Change Log – March 10, 2026.

March 3, 2026

DNSSEC validation for domain control and CAA checks

On March 3, 2026, DigiCert began validating DNSSEC when it is present during domain control validation and DNS CAA checks. This affects products that require domain validation and CAA checks before issuance (such as public TLS).

What you need to do

DNSSEC is not required. If you do not use DNSSEC, nothing changes. If you do, ensure DNSSEC is correctly configured—misconfigured DNSSEC can cause DCV or CAA failures.

For full details, see:
CertCentral Change Log – March 3, 2026.

February 24, 2026

199-day maximum validity for public TLS certificates

On February 24, 2026, DigiCert stopped accepting public TLS certificate requests with validity greater than 199 days (DigiCert’s implementation of the CA/Browser Forum’s 200-day cap). Certificates issued on or after that date cannot exceed that maximum.

This is the first step in CA/Browser Forum Ballot SC081’s industry schedule toward shorter public TLS lifetimes. Sectigo/PositiveSSL follow the Forum’s later phase dates.

Maximum certificate validity	DigiCert expected date*	Sectigo expected date
200 days	February 24, 2026	March 15, 2026
100 days	Before March 15, 2027	March 15, 2027
47 days	Before March 15, 2029	March 15, 2029

*DigiCert ordinarily implements CA/Browser Forum hard dates at least two weeks early. Exact dates can still change.

These dates can change as CA/Browser Forum requirements and CA implementation plans are updated.

For DigiCert details, see:
CertCentral Change Log – Moving to 199-day validity.

Domain validation reuse shortened to 199 days

Domain validation reuse applies to OV and EV certificates: after DigiCert validates that you control a domain, that validation can be reused for later OV/EV orders for the same domain—without repeating DCV—until the reuse period expires. Then you must revalidate before DigiCert will issue another OV/EV certificate for that domain.

This does not apply to DV certificates. DV has no domain validation reuse. DigiCert must revalidate every domain on a DV order each time a certificate is issued or reissued.

On February 24, 2026, DigiCert shortened the OV/EV domain validation reuse period to 199 days, including for existing domain validations (previously up to 397 days). That is DigiCert’s implementation of the CA/Browser Forum’s 200-day domain validation reuse cap.

Maximum domain validation reuse period	DigiCert expected date*	Sectigo expected date
200 days	February 24, 2026	March 15, 2026
100 days	Before March 15, 2027	March 15, 2027
10 days	Before March 15, 2029	March 15, 2029

*DigiCert ordinarily implements CA/Browser Forum hard dates at least two weeks early. Exact dates can still change.

These dates can change as CA/Browser Forum requirements and CA implementation plans are updated.

What you need to do

If you order OV or EV certificates, expect more frequent domain revalidation. Watch domain validation expiration dates and revalidate before they expire so renewals and new OV/EV orders are not delayed. DV customers see no change to reuse rules—DCV remains required on every issue and reissue.

For full details, see:
CertCentral Change Log – Shortening the domain validation reuse period to 199 days.

OV organization validation reuse shortened to 397 days

Organization validation reuse applies to OV certificates: after DigiCert validates your organization, that organization validation can be reused for later OV orders—without repeating organization validation—until the reuse period expires. Then DigiCert must revalidate the organization before issuing another OV certificate for it.

This does not apply to DV certificates. DV has no organization validation (and no organization validation reuse).

On February 24, 2026, DigiCert shortened the OV organization validation reuse period from 825 days to 397 days, including for existing OV organization validations. That is DigiCert’s implementation of the CA/Browser Forum’s 398-day OV organization validation reuse cap.

Maximum OV organization validation reuse period	DigiCert expected date*	Sectigo expected date
398 days	February 24, 2026	March 15, 2026

*DigiCert ordinarily implements CA/Browser Forum hard dates at least two weeks early. Exact dates can still change.

These dates can change as CA/Browser Forum requirements and CA implementation plans are updated.

What you need to do

If you order OV certificates, plan organization revalidation on the shorter ~397-day cycle so renewals and new OV orders are not delayed.

For full details, see:
CertCentral Change Log – Shortening the organization validation reuse period for public OV TLS certificates to 397 days.

459-day maximum validity for public code signing certificates

Code signing certificates are used to digitally sign software, scripts, and other executables so users and platforms can verify the publisher and that the code has not been tampered with. This change is about how long a newly issued public code signing certificate may remain valid—not TLS/SSL website certificates.

On February 24, 2026, DigiCert stopped accepting public code signing certificate requests with validity greater than 459 days. Certificates issued on or after that date cannot exceed that maximum. That is DigiCert’s implementation of CA/Browser Forum Ballot CSC-31’s 460-day cap (down from 39 months).

Maximum code signing certificate validity	DigiCert expected date*	Sectigo expected date
460 days	February 24, 2026	February 23, 2026

*DigiCert ordinarily implements CA/Browser Forum hard dates early (CSC-31’s industry date is March 1, 2026). Exact dates can still change.

These dates can change as CA/Browser Forum requirements and CA implementation plans are updated.

What you need to do

If you buy DigiCert or Sectigo code signing certificates, plan for shorter individual certificate lifetimes. Multi-year product terms may still be sold, but each issued certificate is capped near 460 days—so expect reissuance during a multi-year term.

For DigiCert details, see:
CertCentral Change Log – Moving to 459-day validity for public code signing certificates.

2025

DigiCert KeyLocker for code signing

GeoCerts began offering DigiCert KeyLocker as a code signing private-key provisioning option. KeyLocker is DigiCert’s cloud HSM service: it generates and stores code signing private keys in FIPS 140-2 Level 3–compliant cloud hardware so you do not need a shipped USB token or your own on-premises HSM.

Sign from anywhere, avoid lost/stolen tokens, and integrate signing into CI/CD workflows. When ordering DigiCert code signing through GeoCerts, choose KeyLocker as the provisioning method where available.

Learn more

DigiCert KeyLocker
Contact GeoCerts support for ordering help

Common Mark Certificates (CMC)

GeoCerts began offering DigiCert Common Mark Certificates (CMC) alongside Verified Mark Certificates (VMC). Mark certificates support BIMI so your brand logo can appear next to authenticated email in supported inboxes.

CMC is for organizations that need BIMI logo display without a registered trademark—proof of prior public use of the logo is required instead. VMC remains the path for registered trademarks (and can enable additional inbox trust indicators such as Gmail’s blue checkmark). DMARC enforcement (p=quarantine or p=reject) is required for both.

Learn more

VMC & CMC Mark Certificates

ACME Directory URLs in CertCommand

GeoCerts launched ACME Directory URLs in CertCommand so customers can automate DigiCert and GeoTrust TLS certificate issuance and renewal with ACME clients.

Create a Directory URL profile (product, brand, validity settings), then use the generated ACME Directory URL and External Account Binding (EAB) credentials with the DigiCert ACME Client or another ACME client.

Documentation