Cloudera Docs

Handling public CA EKU policy changes

Public CAs (such as DigiCert and Let's Encrypt) are phasing out multi-purpose TLS certificates. In the past, a single certificate could have both server authentication and client authentication EKUs (Extended Key Usages). Moving forward, Public CAs will only issue dedicated serverAuth certificates.

Cloudera Base on premises utilizes mutual TLS (mTLS) for internal communication. The current architecture requires each node to have a single certificate that supports both EKUs simultaneously. Because Cloudera does not yet support using two separate single-purpose certificates, Public CAs' stoppage of issuing dual-purpose certificates will break cluster security and communication.

You will be impacted only if you are currently using a Public CA’s issued certificates to secure your cluster.

For more information, see Cloudera Customer Advisory 2026-953.

Migration options

Please select one of the following options.
Transition to an Internal Private PKI (AutoTLS Use Case 3 with internal CA-signed certificates)
To ensure uninterrupted cluster operations, your organization should proactively transition away from a Public CA and establish an Internal Private PKI to secure your Cloudera Base on premises cluster.
  • Internal service-to-service authentication (mTLS) should be managed by internal CAs rather than Public CAs. Transitioning to a Private PKI aligns your cluster with these architectural best practices for internal node communication.
  • This is similar to Auto-TLS Use Case 3; the only difference is that host certificates are signed by an internal CA rather than a Public CA.
Execute the following steps to migrate to an Internal Private PKI:
  1. Establish an Internal Private PKI within your organization.
  2. Create an internal CA.
  3. Generate host certificates signed by internal CA.
  4. Follow AutoTLS Use Case 3 document for guidance and execute rest of the steps.
Migrate to Cloudera Manager Managed Private Root CA (AutoTLS Use Case 3 to Use Case 1)

Utilize the Cloudera Manager Managed Private Root CA. If setting up and maintaining an in-house enterprise PKI is not an option for your organization, you can transition your cluster to use Cloudera's built-in tools. Reconfigure your Auto-TLS setup to use the Cloudera Manager Managed Private Root CA (Use Case 1). In this configuration, Cloudera Manager acts as the internal Certificate Authority, automatically generating, signing, and distributing fully functional multi-purpose EKU certificates to all cluster nodes without relying on external public infrastructure.

Execute the following steps to migrate from AutoTLS Use Case 3 to Use Case 1:
  1. Execute the following example API call:
    curl -i -v -k -uadmin:admin -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
"location" : "/opt/cloudera/AutoTLS",
"customCA" : false,
"interpretAsFilenames" : true,
"configureAllServices" : "true",
"sshPort" : 22,
"userName" : "root",
"password" : "cloudera"
}' 'https://<<CM_FQDN>>:7183/api/v41/cm/commands/generateCmca'
  2. Restart the Cloudera Manager server and agents on all the hosts.
  3. Restart the Cloudera Management Service.
  4. Finally, restart any clusters that are stale.