What is changing – and when

In our previous article, Client Authentication in TLS/SSL Certificates will no longer be supported by 2027, we explained the changes introduced by the Google Chrome Root Program and what they mean for SwissSign public TLS certificates.

In short, publicly trusted TLS certificates are moving to a single purpose: server authentication. New intermediate CA certificates disclosed in the CCADB since 15 June 2026 may only contain the id-kp-serverAuth Extended Key Usage (EKU). From 15 March 2027, newly issued public TLS subscriber certificates must also contain id-kp-serverAuth only and can no longer contain id-kp-clientAuth.

SwissSign is updating its public TLS certificate profiles accordingly. New profiles containing only server authentication have been available since the late September 2026, and the existing profiles containing both serverAuth and clientAuth are expected to be replaced by the end of January 2027.

HTTPS server authentication is not affected; the following article focuses on mutual authentication use cases impacted by the change and their migration to a private PKI.

Why server and client authentication are being separated

Public certificate issuance validates one thing: control of a domain name and, for OV and EV certificates, the identity of the organisation behind it. It never validates whether a machine or a person is authorised to reach your VPN, your API gateway or your internal services. A certificate that carries both purposes is also twice as valuable to an attacker who obtains the private key: the same key can impersonate your server and sign in as a client. Using separate certificates for server and client authentication limits the scope of a compromised credential and supports stronger risk management throughout the certificate lifecycle.

Which systems are affected?

The change primarily affects environments where publicly trusted TLS certificates are used for client authentication. Typical examples include:

• VPN gateways and remote access: user authentication in IPsec/IKE VPNs, SSL VPNs and remote access.

• Enterprise Wi Fi and network access control (802.1X): user and device authentication with EAP-TLS to access corporate networks.

• API gateways and B2B integrations: authentication of applications and API consumers with mTLS.

• Server-to-server communication: mutual authentication between servers, applications and systems using mTLS.

• Device, IoT and machine-to-machine authentication: machine authentication used to identify and authenticate devices, equipment and automated systems.

Not affected: If your SwissSign TLS certificates are used solely for HTTPS server authentication, such as securing public websites or web applications, this change does not affect you. Existing and future server TLS certificates will continue to work as before.

Existing certificates keep working – but not for long

Certificates issued before the cut-off keep their clientAuth EKU and remain valid until they expire. That provides some transition time, but public TLS certificate lifetimes are also becoming shorter – 200 days since March 2026, and 47 days by 2029. Every renewal after the switch replaces a dual-purpose certificate with a serverAuth-only certificate. The failure mode is uncomfortable: a handshake that has worked for years may simply stop working after a routine renewal, and the outage shows up in production rather than in a change ticket.

Private PKI as an alternative for mutual authentication

A public certificate is like a passport: it is issued by an authority that is broadly trusted. A private certificate is like a company badge: it is issued within a defined environment and trusted by the systems that belong to it. For mutual authentication between systems, this private trust model is often the better fit. The organization controls which systems receive certificates, how long they are valid, and when they are revoked.

Use case 1: mTLS in Kubernetes

Kubernetes environments can run large numbers of microservices that communicate with each other. With mTLS, certificates identify these services and allow them to authenticate each other: each service presents a certificate, and the receiving service verifies it against a trusted CA. As the number of services grows, so does the number of certificates that need to be issued, renewed and replaced. A private PKI provides the private trust infrastructure for these certificates, while Certificate Lifecycle Management (CLM) automates their management at scale. Within Kubernetes, tools such as cert-manager can request and renew certificates for individual workloads and integrate with an external certificate issuer. This allows Kubernetes certificate automation to be integrated into the organization's broader certificate management approach.

Use case 2: B2B authentication

In B2B integrations, organizations may use mTLS to authenticate external partners accessing their APIs or services. The server presents its certificate to the partner, while the partner presents a client certificate that identifies it to the organization. With a private PKI, the organization can issue these client certificates directly to authorized partners and configure its APIs or gateways to trust the private CA. This gives the organization control over which partners can authenticate and allows their certificates to be managed according to its own security policies.

Implementing mutual authentication with SwissSign Private PKI

With SwissSign Private PKI, organisations get a dedicated private CA combined with certificate lifecycle management, governance and reporting. Public and private certificates can be managed centrally throughout their lifecycle.

• Faster migration: Preconfigured templates, policies and governance reduce the effort required to establish and operate a private PKI..

• Automated certificate lifecycle management: Certificate issuance, renewal and distribution can be automated across the entire infrastructure.

• Centralized certificate operations: Public and private certificates, including issuance and revocation, can be managed from a single platform.

• Stronger control: Consistent certificate policies, governance and reporting provide clear requirements for client authentication.

• Predictable costs. CHF 2'025.- per year and CHF 31.80/certificate/year.

A private hierarchy also provides a controlled environment in which to prepare for future cryptographic changes, including the introduction of post-quantum algorithms. Different requirements apply when authenticating people. Depending on the use case, sponsor-validated S/MIME certificates from the Organization Validation (OV) level may be an alternative within a managed PKI.

Three steps to take now

1. Take inventory: Search your certificate estate for the clientAuth EKU and identify every system that presents a certificate as a client. Renewal dates alone do not indicate which systems use clientAuth.
2. Decide per use case: Identify the appropriate replacement for each client-authentication scenario, such as a private PKI for machines, services and devices, or S/MIME certificates where user authentication is required.
3. Automate: With shorter lifetimes, manual replacement no longer scales. Certificate lifecycle management automates discovery, renewal and distribution, and solves both challenges at once.

Frequently asked questions