ASF advisory: https://news.apache.org/foundation/entry/the-public-ca-clientauth-eku-sunset-what-apache-software-deployers-need-to-know
What's changing Driven by Chrome's Root Program Policy (and aligned via CA/Browser Forum Ballot SC-081), public CAs are removing the clientAuth Extended Key Usage from publicly-issued TLS leaf certs. The rollout is staggered: most major CAs (DigiCert, Sectigo) stopped including clientAuth by default in October 2025; Let's Encrypt removed it from the default ACME profile on February 11, 2026; the practical industry-wide cutoff for opt-in issuance lands in May 2026, with Chrome's hard enforcement now slated for March 15, 2027. Net effect: client identity belongs to private PKI, not public trust anchors. Server-only TLS is unaffected, and certs issued before each CA's cutoff keep working until they expire — the break only hits at the next renewal under the new policy. The narrow use case this hits A publicly-issued cert is being used to authenticate to a Pulsar cluster (i.e. the cert is presented as a TLS client identity, not just as a server cert). Concrete example: a geo-replication setup where the source broker connects outbound to a remote cluster, and the broker presents a public-CA-signed cert (often the same wildcard cert used for its inbound listener) for mTLS client auth on that outbound connection. When that cert is renewed under the new policy, it'll lack clientAuth and the replication handshake will fail. Same pattern applies to any external Pulsar client (producer/consumer/admin) presenting a public-CA-issued client cert. You're affected only if all three apply - mTLS / client cert auth is explicitly enabled in Pulsar (opt-in, not default) - The cert presented as the client identity is from a public CA - That cert currently includes the clientAuth EKU Kubernetes note cert-manager itself is not a CA — it's a certificate lifecycle controller that delegates signing to whatever Issuer you configure. With an in-cluster CA Issuer (root key stored as a K8s Secret, bootstrapped via SelfSigned), cert-manager will happily sign CSRs with clientAuth set via the Certificate's `usages` field. That's fine for in-cluster Pulsar mTLS — the break only hits when a publicly-acquired CA signs the client-side cert. For production setups with external clients, geo-replicated brokers, HSM/KMS key offload, or proper revocation (CRL/OCSP), point cert-manager at a real CA backend (Vault/OpenBao/step-ca via their cert-manager Issuers) instead of the in-tree CA Issuer. Open-source CA/PKI options These are the actual signing backends. cert-manager sits in front of any of them as the K8s-native interface (Certificate / CertificateRequest CRDs), or they can be used standalone for non-K8s workloads. - OpenBao — Linux Foundation fork of Vault (MPL-2.0, pre-BSL). Contains a full PKI secrets engine with per-role EKU policy, multi-tier hierarchies, ACME support, CRL/OCSP. Vault-API-compatible. cert-manager integrates via the Vault Issuer. https://openbao.org/docs/secrets/pki/ - HashiCorp Vault PKI — same engine, still works, BSL-licensed. - Smallstep step-ca — lightweight single-binary CA, ACME-first, cert-manager via ACME or the step-issuer. Best fit for greenfield cloud-native mTLS. https://github.com/smallstep/certificates - EJBCA Community — enterprise-grade, broad protocol support (CMP, EST, SCEP, ACME). Heavier, but the right pick for regulated environments. For most Pulsar setups: cert-manager + OpenBao (or step-ca) covers both K8s-native issuance and external clients with one PKI. The pure cert-manager CA Issuer is fine for small/dev clusters but stores the CA key in a Secret and lacks revocation infrastructure, so it's not a production substitute. Action Inventory mTLS usage: flag any public-CA cert presented as a client identity (geo-replication brokers, external producers/consumers), check your CA's specific cutoff date, migrate to a private CA backend (cert-manager-fronted or standalone), and test before the next renewal hits. Pulsar mTLS docs: https://pulsar.apache.org/docs/next/security-tls-authentication
