New2025 wrap-up: Voyage AI, AMP launch, & customer wins. Plus, 2026 predictions. Read blog >
NewBuild better RAG. Voyage 4 models & Reranking API are now on Atlas. Read blog >
NewIntroducing Automated Embedding: One-click vector search, no external models. Read blog >
TECHNICAL ADVISORY

TA-2026-001: Public Certificate Authority Policy Changes Affecting mTLS

Classification: Important
Applies to: Self-Managed MongoDB Deployments Using Public Certificate Authorities
Date: January 22, 2026
Action Required By: April 2026

Overview

Starting in April 2026, major public Certificate Authorities (CAs) will stop issuing TLS certificates that support client authentication. This change may require action if you use self-managed MongoDB with certificates from public CAs.

Does This Affect You?

This advisory applies only if you meet all of these conditions:

  1. You run self-managed MongoDB (not Atlas)
  2. You obtain server TLS certificates from a public Certificate Authority

You are NOT affected if any one of the following is true:

  1. You use MongoDB Atlas
  2. You use a private/internal Certificate Authority to issue all server TLS certificates
  3. You disable mTLS in server nodes through the tlsWithholdClientCertificate server parameter (enabled by default).

If you are not affected, no action is required.

What's Happening

Public CAs are ending support for TLS client authentication certificates. This industry-wide change is designed to separate public and private PKI use cases. Once this policy change takes effect, newly issued certificates will no longer include the "TLS Web Client Authentication" Extended Key Usage (EKU) extension which is also referred to as the "clientAuth" EKU. If you currently use certificates from public CAs for intracluster mutual TLS (mTLS), you will need to either migrate to a private certificate infrastructure or disable mTLS in your MongoDB configuration.

Timeline

Several major public certificate authorities have begun phasing out support for issuing certificates that include the clientAuth EKU. This is being implemented in stages across the industry.

Phase 1 Began October 2025: Most public CAs have stopped including the Client Authentication EKU by default. Certificates that include the clientAuth EKU may still be requested, with some restrictions.

Phase 2 Starting April 2026: Complete shutdown of clientAuth support in public CA certificates. No clientAuth certificates will be issued (no exceptions).

Note: AWS Certificate Manager has already stopped clientAuth in public CA certificates as of June 2025.

Important Note: Existing certificates issued before these dates will remain valid until their natural expiration. The policy changes apply only to new certificate issuances, renewals, and reissuances after each CA's cutoff date.

Immediate Risk: Certificate Renewals

If you renew server certificates from a public CA today using your existing certificate signing requests (CSRs), the new certificates may not include clientAuth support even if your previous certificates did. By default, a MongoDB server node requires the clientAuth EKU to be present in its cluster certificate -- that is, the certificate it presents when making outbound connections -- in order to successfully establish mTLS connections with other server nodes. With this change, your cluster will experience connection failures when renewed certificates are applied.

Required Actions

  1. Determine if you are affected - You may be affected if you deploy a self-managed MongoDB cluster and your server TLS certificates are issued by a public certificate authority. Please refer to the “How to determine if you are affected” section of the technical guidance below for more detailed instructions.

  2. Review your current certificate and authentication setup - If you are affected, identify which certificates in your deployment include the clientAuth EKU, and determine whether mTLS or X509 intracluster authentication is in use.

  3. Evaluate your mitigation options - We provide two mitigation options in the technical guidance depending on your mTLS or X.509 authentication requirements.

  4. Test certificate renewals - Before applying renewed certificates to production, verify they contain the expected capabilities

  5. Update monitoring - Ensure you have alerting in place for TLS handshake failures

  6. Communicate with stakeholders - If moving to private PKI, coordinate with application teams about trust store updates

Important Technical Note

This change cannot be addressed by modifications to MongoDB server behavior. The EKU RFC specifies that "if the extension is present, then the certificate MUST only be used for one of the purposes indicated." MongoDB's TLS implementation follows this specification to adhere to security best practices.

Additional Resources

Need Help?

Contact MongoDB Support or your Technical Account Manager to discuss your specific deployment configuration and migration options.

MongoDB Technical Implementation Guide on Public CA Policy Changes Impacting Client Authentication Certificates

What is changing, and why it matters

Public certificate authorities (CAs) are in the process of stopping issuance of server certificates that include a clientAuth extended key usage (EKU). This means that public server certificates used for client authentication in a mutual TLS (mTLS) exchange will, upon renewal, no longer include the matching key usage attribute required for that purpose, and so will be rejected by the peer server.

Historically, public CAs like Let’sEncrypt issued server certificates that included both EKUs:

  • serverAuth - indicates the certificate can be used to validate the server/ingress side of the TLS handshake.
  • clientAuth - indicates the certificate can be used to validate the client/egress side of the TLS handshake.

Public CAs are removing clientAuth to tighten security around usage rules, and to ensure that the server certificates they issue are only valid for server authentication alone.

What this means for your MongoDB deployment

This only affects you if you have a self-managed MongoDB deployment. There’s no action needed if you use Atlas. This also does not affect you if you already use a private CA to issue your server and client certificates.

In a MongoDB cluster, each node (e.g. a mongod or mongos process) must act as both a server and a client.

When TLS is enabled in the cluster, mutual TLS is strictly enforced by the server by default. This means that incoming client connections must present a valid X.509 certificate with a clientAuth EKU in order to successfully establish the secure connection. If all nodes in the cluster are configured to use a single public certificate containing both EKUs, then they can establish mTLS connections among themselves.

However, without the clientAuth EKU, each node will reject incoming connections from other nodes, and cause TLS handshake errors to appear in the connecting node. This, in turn, causes replica set members to fail to send heartbeats, primaries to fail to replicate to secondaries, and shards to become unreachable, thus severely impacting your cluster’s availability.

Without mTLS within the cluster, cluster membership authentication using X.509 does not work across nodes. The server needs validated SSL peer information from the client certificate to identify the user and verify cluster membership.

How to determine if you are affected

Server Configuration File

Follow the steps below to determine whether you are affected.

Step 1: Confirm that MongoDB is using mTLS internally

On each node, inspect the MongoDB configuration file (usually mongod.conf) and look for the net.tls.mode setting. If the value is disabled or allowTLS, then connections between servers do not use TLS, and you are not affected.

In the same file, look for the setParameter.tlsWithholdClientCertificate setting. If present and the value is true, then this node is not sending a client certificate during the TLS handshake, therefore mutual TLS is not being used for intracluster connections. You are not affected. Otherwise, proceed to step 2.

Step 2: Identify the certificates used for intracluster TLS

On each node, inspect the MongoDB configuration file (usually mongod.conf) and look for the value of the net.tls.clusterFile setting, or if absent, the value of the net.tls.certificateKeyFile setting¹. This value is the path to the certificate used by this node when it acts as the client.

Assuming your MongoDB server is hosted on Linux, inspect this certificate’s issuer by running this command (replace <path_to_cert> with the path obtained above):

openssl x509 -noout -issuer -in <path_to_cert>

If the output shows an issuer that is a well-known public CA (for example, DigiCert, Let’sEncrypt, etc), then you will be affected when this certificate renews and no longer includes the clientAuth EKU. On the other hand, if this issuer is an internal or private CA (e.g. company-owned PKI or self-signed certificate), then you are not affected.

Cloud or Ops Manager UI

If you manage your cluster through the Ops Manager or Cloud Manager user interface, then follow the steps below to determine whether you are affected.

Step 1: Confirm that MongoDB is using mTLS internally

On each Ops Manager Project, go to Security→ Settings and look for the MongoDB Deployment Transport Layer Security (TLS) row. This is a project-wide setting.

OM URL: {OM_HOST}/v2/{PROJECT_ID}#/deployment/security/settings

Image 1

If it's disabled, like in the previous screenshot, you are not affected. If enabled, click “Edit” and you will see the detailed information, as in the following screenshot:

Image 2

Look at the value of the tlsMode. If the value is disabled or allowTLS, then connections between servers do not use TLS, and you are not affected.

Also, copy the values of “TLS Certificate Authority File Path” and “TLS Cluster Certificate Authority File Path”, you will need them for Step 2.

Note: "Client Certificate Mode" maps to net.tls.allowConnectionsWithoutCertificates. "Optional" = true, "Required" = false.

Next, go into each deployment of the project and click Modify on the right of the screen

Image 3

Now, expand the Advanced Configuration Options and look for the tlsWithholdClientCertificate parameter.

Image 4

If present and the value is true, then this node is not sending a client certificate during the TLS handshake, therefore mutual TLS is not being used for intracluster connections. You are not affected. Otherwise, proceed to step 2.

Step 2: Identify the certificates used for intracluster TLS

On each node, assuming your MongoDB server is hosted on Linux, inspect this certificate’s issuer by running this command (replace <path_to_cert> with the paths obtained from Step 1):

openssl x509 -noout -issuer -in <path_to_cert>

If the output shows an issuer that is a well-known public CA (for example, DigiCert, Let’sEncrypt, etc), then you will be affected when this certificate renews and no longer includes the clientAuth EKU. On the other hand, if this issuer is an internal or private CA (e.g. company-owned PKI or self-signed certificate), then you are not affected.

Mitigation Options

Depending on your situation, you have a few options to mitigate this problem.

Option A: use server certificates issued by a private CA

This option is for users that require mTLS and MONGODB-X509 authentication for node-to-node communication.

If you choose this option, then you will need all of the following:

  • to configure each cluster member node to have two certificate-private key pairs: one certificate for presenting to incoming connections as a server (the “server cert”), and one for authenticating to peer nodes (the “cluster cert”).
    • if you have publicly-issued certificates for your server nodes, you can reuse them provided they are only used for incoming connections.
  • a single private CA issuer to issue both external client certificates, and the cluster certificates (i.e. the certs used for intracluster authentication). This is required for MONGODB-X509 authentication to work for both user and intra-cluster authentication. (see Trade-offs)
  • ensure that the tlsWithholdClientCertificate server parameter is set to false, or left unset.
  • to configure how MongoDB authorizes clients for cluster membership.

Options for private PKI include:

Server configuration

The MongoDB server can act as both the server and client in a TLS handshake. In order for this option to work, the server will need two distinct certificate-key pairs, one for each role. MongoDB lets you configure which certificates are used for which roles via the certificateKeyFile and clusterFile configuration options.

The certificate presented when the node acts as a TLS server is configured via the net.tls.certificateKeyFile setting in the configuration file. This certificate may be issued by either a private or public CA, and must include the serverAuth EKU. To enable peer nodes to connect and validate this certificate successfully, all nodes in the cluster must configure their net.tls.CAFile (or --tlsCAFile) setting with the issuing CA’s certificate. External clients must have the issuing CA’s certificate in their trust stores when using private CAs. Public CAs are typically trusted by default in most client environments..

The certificate presented when the node acts as a client making outbound TLS connections to other cluster members is configured via the net.tls.clusterFile setting in the configuration file (or --tlsClusterFile command line option). This certificate must be issued by a private CA trusted by all members of the cluster and must include the clientAuth EKU. Public certificate authorities generally do not issue certificates with the clientAuth EKU and therefore cannot be used to issue clusterFile certificates. All cluster member nodes must configure their net.tls.clusterCAFile (or --tlsClusterCAFile) setting with the private CA’s certificate, in order to validate inbound connections from peer nodes presenting their clusterFile certificates.

In order for inbound connections that present clusterFile to be authorized with cluster member privileges, they must first be authenticated by the server by satisfying the configured cluster membership criteria. Once the MongoDB server has validated the peer certificate, it checks that the peer certificate’s Distinguished Name (DN) attributes, or MongoDB cluster membership extension value (OID 1.3.6.1.4.1.34601.2.1.2), matches the attributes configured in net.tls.clusterAuthX509.attributes or the extension value configured in net.tls.clusterAuthX509.extensionValue, respectively. In the absence of either configuration options, the server defaults to matching the client’s DN attributes O, OU, DC, with those of the server certificate’s DN attributes.

Given the certificate requirements described above, here’s an example of how you can configure your cluster node’s TLS and security settings (certificate file paths are for demonstration purposes only; adjust them to match your environment):

net:
  tls:
    mode: requireTLS

    # Certificate presented when this node acts as TLS server
    # (e.g. when accepting connections from drivers, mongosh, or peer nodes)
    # may either have a public or private CA issuer
    certificateKeyFile: /etc/ssl/mongodb/server.pem

    # CA certificate used to validate the server cert above
    CAFile: /etc/ssl/certs/public-ca-bundle.pem

    # Certificate presented when this node acts as TLS client
    # for intra-cluster communication
    clusterFile: /etc/ssl/mongodb/cluster.pem

    # CA certificate used to validate peer cluster certificates
    # (private CA trusted by all cluster members)
    clusterCAFile: /etc/ssl/mongodb/cluster-ca.pem

    # Attributes that must be present in a client certificate
    # in order to be authorized as a cluster member.
    clusterAuthX509:
      attributes: CN=node1,O=mongodb,OU=test

    # Always strictly enforce mTLS
    allowConnectionsWithoutCertificates: false

security:
  # Enable authentication and authorization
  authorization: enabled

  # Use MONGODB-X509 intra-cluster authentication
  clusterAuthMode: x509

setParameter:
    # Do not withhold client certificate when establishing outbound TLS
    tlsWithholdClientCertificate: false

Trade-offs

✓ Maintains full mutual authentication security
✓ Greater control over certificate lifecycle and policies
✓ Meets strict security and compliance requirements
✓ Required for X.509 authentication configurations
✗ Requires operational expertise to manage private CA infrastructure
✗ More complex certificate renewal and distribution processes
✗ Ongoing maintenance and monitoring requirements

When using mTLS or MONGODB-X509 authentication, all inbound TLS connections must be validated against the same trust anchor, because MongoDB uses a single CA file (i.e. clusterCAFile) to validate all incoming TLS connections. This means that certificates used for client/user authentication and for cluster member authentication must be issued by the same CA (or trust chain). As a result, if you have existing users that have certificates issued by a different CA than the one that clusterCAFile is configured with, then those users will no longer be able to connect and establish mTLS sessions with the cluster, unless their certificates are renewed with the correct issuer. When choosing this option, care must be taken to ensure that certificates issued by this CA for external clients cannot be used to authenticate to MongoDB as a cluster member.

Option B: configure servers to neither present nor require client certificates

If you only require TLS for transport security, and don’t need mutual TLS or X.509 authentication between server nodes, then you may choose to disable strict enforcement of mTLS in the server nodes and prevent them from sending their client certificates upon a peer node’s request. For this to work, you must do both of the following:

  • Set the net.tls.allowConnectionsWithoutCertificates configuration option (or --tlsAllowConnectionsWithoutCertificates command-line option) to true.
  • Set the setParameter.tlsWithholdClientCertificate configuration option to true (or pass --setParameter tlsWithholdClientCertificate=true in the command line options).

Server configuration

With this option, external clients or applications that establish mTLS with the server, or authenticate using MONGODB-X509, may continue to do so without disruption, as long as their client certificates are not also affected by this policy change.

In this setting, intra-cluster authentication must use SCRAM-SHA-256, which is configured using keyfiles (a file containing the shared symmetric key). Each machine that hosts a replica set member must have a copy of the keyfile. If you are not already using keyfiles for internal authentication, then refer to the instructions for how to deploy a replica set with keyfile access control in the MongoDB manual.

Here’s an example of how you can configure your server nodes per the above requirements (certificate file paths are for demonstration purposes only; adjust them to match your environment):

net:
  tls:
    mode: requireTLS

    # Certificate presented when this node acts as TLS server
    # (e.g. when accepting connections from drivers, mongosh, or peer nodes)
    # may either have a public or private CA issuer
    certificateKeyFile: /etc/ssl/mongodb/server.pem

    # CA certificate used to validate the server cert above
    CAFile: /etc/ssl/certs/public-ca-bundle.pem

    # Don't strictly enforce mTLS
    allowConnectionsWithoutCertificates: true

security:
  # Enable authentication and authorization
  authorization: enabled

  # Use keyFile for intra-cluster authentication
  clusterAuthMode: keyFile
  keyFile: /etc/mongodb/keyfile

setParameter:
    # Withhold client certificate when establishing outbound TLS
    tlsWithholdClientCertificate: true

Trade-offs

✓ Minimal operational changes - continue using your existing public CA infrastructure
✓ No changes required to client applications or trust stores
✓ Simplest migration path
✓ Encrypted channel still established between server and client
✗ Server would no longer strictly require the client to provide a client certificate during TLS handshake. However, if the client provides a certificate, the server would still validate it.
✗ Relies on application-level authentication (keyFile) instead of certificate-based authentication for intra-cluster authentication
✗ May not meet compliance requirements in highly regulated environments
✗ Not suitable if you require mTLS or X.509 authentication across nodes


¹ certificateKeyFile must be present for the server to start successfully when TLS is enabled.