Third-party Certificate Authorities cease issuing certificates with 'ServerAuth' and 'ClientAuth' EKU Extensions

Discover how this industry-driven change might affect component configurations and network connections within your Splunk platform environment.

Beginning in September 2025, several third-party certificate authorities (CAs) stopped issuing public Transport Layer Security (TLS) server certificates containing both "Client Auth" and "Server Auth" Extended Key Usage (EKU) extensions. Beginning in May of 2026, several of these CAs will no longer issue any public certificates with the "Client Auth" EKU at all. These changes affect the issuance of new certificates as well as renewed, re-issued, or duplicate certificates. The changes are in line with industry standards to improve overall security by separating certificate usages and maintain compliance with directives from browser vendors such as the Google Chrome Root Program.

App Key Value Store (KV Store), which handles a majority of configuration persistence on the Splunk platform, requires either a certificate that has both EKUs, or two certificates that have one of each EKU. Depending on the configuration of your Splunk platform deployment and whether you use public TLS certificates to secure the deployment, these changes could affect you. Read on to determine whether or not you must take action to prevent downtime in your deployment, and learn:

The changes that this release note outlines do not affect the following:

  • Public TLS certificates that third-party CAs generate for use only with Splunk Web. Those certificates only have the "Server Auth" EKU

  • Certificates that you generate, sign, and use, with certain exceptions, as outlined later in this topic

What is an EKU and why is it so important?

An Extended Key Usage (EKU) is an extension to a digital certificate that conforms to the X.509 standard. The EKU defines how the public key in that certificate can be used. It controls the purpose of the certificate by restricting what the certificate can do. Certificates can have more than one EKU.

A certificate with the TLS Web Server Authentication, or "Server Auth" EKU can be used to authenticate a server. Conversely, a certificate with a TLS Web Client Authentication, or "Client Auth" EKU can be used by a client to authenticate into a server. A certificate with a "Client Auth" EKU is required for mutually-authenticated TLS (mTLS), which KV Store uses for both itself and for connections to other Splunk components.

Third-party CAs have traditionally issued public certificates with both EKUs included. This practice was identified as a security risk, prompting a coordinated change with web browser vendors. Consequently, these CAs now require opting in to add the 'Client Auth' EKU to a certificate or refrain from issuing certificates with 'Client Auth' EKUs altogether. This began in September 2025, and by May 2026, many CAs will no longer issue public certificates with "Client Auth" EKUs.

As a Splunk platform administrator, what does this change mean for me?

If your Splunk platform deployment uses public TLS certificates for the following:

  • Securing of Splunk components, particularly for KV Store or other component-to-component connections

  • mTLS for any supported connection

this change could affect your deployment. Splunk has already encountered customer incidents where updated certificates without the "Client Auth" EKU caused problems with KV Store and mTLS-configured connections in the deployment. Follow the procedures described later in this topic to determine the steps you must take to ensure that these changes do not affect you.
Note: Existing valid certificates in your Splunk platform deployment remain valid until they expire or are invalidated prior to their expiration date. New, renewed, reissued, and duplicate certificates that you receive from a third-party CA and install in your environment can potentially cause problems with the environment. Each CA has a different policy on how they handle the issuance of certificates with the "Client Auth" EKU. Contact your CA or review their documentation for those specifics.

What do I need to do to ensure these changes do not affect my environment?

Your plan of action depends on the current state of the TLS certificates in your Splunk platform deployment.

If you use third-party certificates to secure your Splunk platform deployment, follow these steps to ensure the deployment continues to operate smoothly:

  1. Audit the certificates in your environment to ensure compliance:

    1. Verify that existing certificates, except those used solely for Splunk Web, include both "Server Auth" and "Client Auth" EKUs.

    2. Ensure that certificates used exclusively for Splunk Web have only the "Server Auth" EKU.

  2. Decide whether to continue using third-party CA certificates:

    1. If you choose to continue using public TLS certificates, or if business requirements necessitate it, contact your CA to obtain new certificates that meet deployment requirements.

    2. If you can generate your own certificates, follow the procedure at How to create and sign your own TLS certificates. Install the new certificates, replace the existing ones, configure the Splunk platform to use them, and verify that mTLS and services like KV Store function as you expect.

If, in the context of securing your Splunk platform deployment, you do any of the following:

  • Generate, sign, and use your own certificates on Splunk Enterprise

  • Use the certificates that Splunk Enterprise self-generates to secure connections between components

you do not need to do anything in most cases. There are some exceptions:

  • If you generate and sign certificates for use only with Splunk Web, those certificates must have only the "Server Auth" EKU. This is because nearly all browsers will soon no longer support using certificates with both "Server Auth" and "Client Auth" EKUs to access websites, including Splunk Web. See Configure Splunk Web to use TLS certificates.

I want or have to use public TLS certificates for my environment. What can I do?

Currently, most CAs will only issue certificates with the "Server Auth" EKU, and might or might not provide options to add the "Client Auth" EKU. Several CAs have announced that they will no longer provide certificates with the "Client Auth" EKU, and provide workarounds for this change.

Perform the following procedure to ensure that the certificates you receive from your third party CA meet the requirements for your Splunk platform deployment going forward.

  1. Contact your CA to determine what their stance is with regard to issuing public certificates with the "Client Auth" EKU.

  2. Obtain new certificates from the CA. These certificates will only have the "Server Auth" EKU by default. These certificates are acceptable for use in securing Splunk Web, but are not acceptable for other components such as KV store or use in mTLS configurations.

  3. Follow the instructions, where applicable, from the CA on how to generate certificates with the "Client Auth" EKU.

  4. If the CA does not provide instructions on how to generate "Client Auth" EKU certificates, they will provide an alternative to that process, including but not limited to transitioning to either a vendor-branded public key infrastructure (PKI), or PKI-as-a-service. The alternatives that are available depend specifically on the CA from which you get the certificates.

  5. After you obtain the new certificates, you might need to concatenate them to create a certificate chain that contains at least two certificates: one with each EKU. See How to prepare TLS certificates for use with the Splunk platform for further information.

What happens if I do nothing?

Existing valid certificates remain valid until they expire or become invalid.

The consequences of inaction will surface when you go to renew, reissue, or duplicate these certificates. This is because CAs no longer issue certificates with both EKUs as they did previously.

If a certificate does not have the proper EKUs embedded, Splunk components, and in particular KV Store, reject the certificate as invalid. This means that these components will not start, which immediately results in a period of downtime until you either install a certificate that meets the EKU requirements or reconfigure your Splunk platform deployment to not use certificates.