Skip to main content
Industry changes affecting client certificate authenticationPublicly trusted Certificate Authorities (CAs) are narrowing the scope of standard TLS certificates, and client authentication is being deprecated or removed from typical public CA issuance. If you need durable mutual TLS (mTLS) for client certificate authentication, you should plan for private PKI for client certificates.For background on the broader ecosystem changes, see Let’s Encrypt’s announcement.

​
Standard TLS Authentication v. Mutual TLS Authentication

The standard TLS authentication process works as follows:
  1. The client sends a request to the server.
  2. The server presents its SSL certificate to the client.
  3. The client validates the server’s SSL certificate with the certificate authority that issued the server’s certificate. If the certificate is valid, the client generates a random encryption key, encrypts it with the server’s public key, and then sends it to the server.
  4. The server decrypts the encryption key using its private key. The server and client now share a secret encryption key and can communicate securely.
Mutual TLS authentication includes additional steps:
  1. The server will request the client’s certificate.
  2. The client sends its certificate to the server.
  3. The server validates the client’s certificate with the certificate authority that issued it. If the certificate is valid, the server can trust that the client is who it claims to be.

​
Generating a Client Certificate

Client certificate authentication is more secure than using an API key or basic authentication because it verifies the identity of both parties involved in the communication and provides a secure method of communication. However, setting up and managing client certificate authentication is also more complex because certificates must be generated, distributed, and validated for each client. A client certificate is typically a digital certificate used to authenticate requests to a remote server. For example, if you are working with a third-party API, their server can ensure that only trusted clients can access their API by requiring client certificates. The client in this example would be your application sending the API request. We recommend that you verify accepted Certificate Authorities with your third-party API provider and then generate a client certificate using these steps:
  1. Generate a private key. This must be securely stored and should never be exposed or transmitted. It’s used to generate the Certificate Signing Request (CSR) and to decrypt incoming messages.
  2. Use the private key to generate a Certificate Signing Request (CSR). The CSR includes details like your organization’s name, domain name, locality, and country.
  3. Submit this CSR to a trusted Certificate Authority (CA). The CA verifies the information in the CSR to ensure that it’s accurate. After verification, the CA will issue a client certificate, which is then sent back to you.
  4. Configure your application or client to use both the private key and the client certificate when making requests to the third-party service.
📘 Certificates are only valid for a certain time (like one or two years), after which they need to be renewed. Repeat the process above to get a new certificate when the old one expires.
For durable mutual TLS client certificate authentication, we recommend using a private PKI (Public Key Infrastructure) solution. Private PKI provides several advantages over public CAs for client certificates:
  • Control over issuance: You control certificate issuance policies, validation requirements, and certificate lifetimes
  • Rotation and short lifetimes: Enable automated certificate rotation with shorter validity periods for improved security
  • Revocation: Manage certificate revocation lists (CRLs) or use Online Certificate Status Protocol (OCSP) for your infrastructure
  • Distributing trust: You control which root and intermediate certificates are trusted by your clients and servers
Private PKI can be deployed in several ways:
  • Internal CA: Run your own certificate authority infrastructure
  • Hosted PKI: Use a hosted PKI service that manages the CA infrastructure for you
  • Managed private CA: Use a cloud provider’s managed private certificate authority service

​
Example solutions

  • Smallstep step-ca: An open-source private CA with ACME support for automation, suitable for both internal and hosted deployments
  • AWS Private Certificate Authority: A managed private CA service that integrates with AWS services and supports automated certificate lifecycle management

​
Trust model considerations

Unlike public TLS certificates that work everywhere by default, mTLS with private PKI requires you to control which root and intermediate certificates are trusted by your clients and servers. You must distribute your CA’s root certificate (or intermediate certificates) to all parties that need to validate client certificates. This gives you full control over your trust model but requires explicit trust distribution.

​
Commercial Certificate Authorities (CAs)

Some commercial CAs may have historically issued client certificates for use in client certificate authentication. However, availability and policies vary by provider and are changing as the industry shifts away from public CA-issued client certificates.
Verify current availability: Before relying on a commercial CA for client certificates, verify that the CA still offers client-auth certificates for your specific use case and trust model. Expect this to become harder with public trust stores over time, and plan accordingly for long-term mTLS deployments.
The following CAs have historically offered client certificate services, but availability and policies may have changed:
  1. DigiCert: one of the most popular providers of SSL/TLS certificates and can also issue client certificates.
  2. GlobalSign: offers PersonalSign certificates that can be used for client authentication.
  3. Sectigo (formerly Comodo): provides several client certificates, including the Sectigo Personal Authentication Certificate.
  4. Entrust Datacard: offers various certificate services, including client certificates.
  5. GoDaddy: known primarily for its domain registration services but also offers SSL certificates, including client certificates.
Note: For transitional or short-term use cases, a commercial public CA might still be acceptable, but private PKI is the recommended path for production mTLS deployments.