In my day-to-day work, I sometimes come across requests that sound quite straightforward at first:

“We need an SSL/TLS certificate for server-to-server communication, and it needs to support both Server and Client Authentication.”

A few years ago, this may not have raised too many questions. Today, however, the answer isn’t quite as straightforward.

This is due to changes across the public certificate industry regarding mutual TLS (mTLS). Unlike the SSL/TLS certificates we commonly use for websites, where the client verifies the server’s identity, mTLS requires both sides of the connection to verify each other.

As publicly trusted SSL/TLS certificates shift toward server authentication, organisations that also rely on them for Client Authentication will need to look at other ways to establish that trust.

So, what exactly is changing, and what does this mean for organisations using mTLS today?

Why Is This Becoming an Important Conversation?

Most of us are familiar with what happens when we visit a secure website. The website presents its SSL/TLS certificate, our browser verifies it, and a secure connection is established.

With mTLS, there’s one additional step: the server also needs to verify the client connecting to it.

I like to think of it as entering a secured office building. With normal SSL/TLS, you check that you’ve arrived at the right building. With mTLS, the security guard also checks your staff pass before letting you in.

This type of two-way authentication is commonly used for APIs, application-to-application communication and server-to-server connections, where organisations need to be sure of exactly which system is connecting.

The issue is that some organisations have traditionally relied on publicly trusted SSL/TLS certificates that support both Server Authentication and Client Authentication.

That is now changing.

What Is Changing with Public TLS Certificates?

A digital certificate can contain something called an Extended Key Usage, or EKU. In simple terms, this tells a system what the certificate is allowed to be used for.

Two common EKUs are:

• Server Authentication – used to verify the identity of a server.
• Client Authentication – used to verify the identity of a client, application, device or system connecting to that server.

Historically, publicly trusted SSL/TLS certificates included both.

The industry is now moving towards separating these two purposes more clearly. Under the Chrome Root Program requirements, publicly trusted SSL/TLS certificates whose roots are included in Chrome’s Root Store, must contain only the Server Authentication EKU. This effectively ends the use of publicly trusted SSL/TLS certificates for Client Authentication in the Chrome-trusted ecosystem.

Certificate Authorities are already making the change based on their own timelines. For example, Sectigo no longer includes Client Authentication by default and will permanently remove it from newly issued publicly trusted SSL/TLS certificates from 10 February 2027. DigiCert will do the same from 1 March 2027.

If your certificates are only being used to secure websites over HTTPS, this generally won’t require much change.

The bigger impact is for organisations using publicly trusted SSL/TLS certificates for mTLS, API authentication, server-to-server communication or other Client Authentication use cases.

Where Does Private CA Come In?

This naturally brings up the next question: If we can’t rely on a publicly trusted SSL/TLS certificate for Client Authentication, what should we use instead?

For many mTLS environments, the answer is a Private Certificate Authority, or Private CA.

One simple way to look at the difference is to ask:

Who actually needs to trust this certificate?

If I’m running a public website, I want browsers and devices around the world to trust my server certificate. That’s where a publicly trusted CA makes sense.

But if one application is communicating with another application, I don’t necessarily need the entire internet to trust the client certificate. I only need the systems involved in that connection to trust it.

This is where a Private CA comes in.

A Private CA allows an organisation to establish a controlled trust environment, where certificates can be issued specifically to authorised applications, systems or devices. Only the systems that are configured to trust that Private CA will recognise those certificates.

For organisations looking for a local Private CA option, Netrust is an IMDA-accredited Certificate Authority in Singapore and has been providing digital certificate and PKI services for many years, supporting both government agencies and private-sector organisations.

Netrust offers Private CA and Managed PKI services, allowing organisations to implement a private trust environment without having to build and maintain the entire CA infrastructure themselves.

For an mTLS setup, for example, a Netrust-issued private certificate can be used for Client Authentication, while a publicly trusted SSL/TLS certificate can continue to be used for Server Authentication where public trust is required.

Public and Private Certificates Can Work Together

Moving Client Authentication to a Private CA doesn’t mean organisations have to stop using publicly trusted publicly trusted SSL/TLS certificates altogether.

In many cases, both can work together.

For example, imagine an organisation has an Internet-facing API that is accessed by authorised business partners.

The API server could continue using a publicly trusted SSL/TLS certificate for Server Authentication. This allows the connecting application to verify that it is communicating with the correct server.

On the other side, the authorised application could use a Netrust Private CA certificate for Client Authentication. The API can then be configured to trust certificates issued under that private trust environment.

Put simply:

Publicly Trusted SSL/TLS Certificate > Proves the server’s identity

Netrust Private CA Certificate > Proves the client’s identity

Both certificates are still working together to provide the two-way authentication required for mTLS. The difference is that each certificate now has a clearer purpose.

Of course, not every environment will require this exact setup. If both applications are completely internal, for example, an organisation may decide to use its Private CA for both sides of the connection.

It really comes back to the same question: Who needs to trust each certificate?

What Should Organisations Do Now?

For organisations already using mTLS, one important thing is not to assume that every SSL/TLS certificate is only being used for HTTPS.

A certificate that was installed several years ago may also be supporting an API, application or server-to-server connection in the background.

A few checks can help:

• Review where your certificates are being used. Identify any certificates supporting mTLS, APIs, server-to-server connections or Client Authentication.
• Check the EKUs. If a certificate contains both Server Authentication and Client Authentication, understand why both are currently needed.
• Look at who actually needs to trust the certificate. Public trust may be necessary for an internet-facing server, but it may not be necessary for an internal application or client.
• Don’t wait until the next renewal. A renewed or reissued publicly trusted certificate may no longer support Client Authentication in the same way as the existing certificate.
• Separate the roles where it makes sense. Using the right certificate for the right purpose can make the overall setup easier to understand and manage.

Existing public certificates that already contain Client Authentication can generally continue to operate until they expire or are revoked.

The main thing is to understand where they are being used and plan what will replace them before that becomes an issue.

Conclusion

mTLS isn’t going away. With more APIs, cloud services and applications communicating with each other, being able to verify both sides of a connection is becoming even more important.

What is changing is how that trust is established.

Publicly trusted SSL/TLS certificates will still play an important role in protecting Internet-facing services. For Client Authentication, Private CA certificates can provide the controlled trust that organisations need.
 
If your organisation uses mTLS today, now is a good time to review where Client Authentication is used and ensure the right certificate is used for the right purpose.
 
Netrust also offers mTLS certificates to help organisations meet their mutual authentication requirements.
 
Find out more about Netrust’s mTLS certificate solutions here: https://www.netrust.net/products/pki/mtls-certificates/
 
Unsure whether your existing certificates are affected? Speak with Netrust to review your requirements and explore the right Public CA and Private CA approach for your environment.
 
Get in touch with our team: https://www.netrust.net/contact-us/

 

 

Follow us on LinkedIn for the latest happenings/updates.