Using a Root CA with nameConstraints fails

[govihari]

I am using strimzi 0.31.0. While using a CA with nameConstraints extension defined for a specified domain, the cluster does not come up with zookeeper pods repeatedly ending with CrashLoopBackOff with log saying No CA found

Detected Zookeeper ID 3 ?
? Preparing truststore ?
? Adding /opt/kafka/cluster-ca-certs/ca.crt to truststore /tmp/zookeeper/cluster.truststore.p12 with alias ca ?
? Certificate was added to keystore ?
? Preparing truststore is complete ?
? Looking for the right CA ?
? No CA found. Thus exiting.

==========================

With restricted nameConstraints in the certificate, how do I get the cluster running?

[scholzj]

I guess you will need your name constraint to allow all the names used in the server certificates?

[govihari]

I am little confused. I have generateCertificateAuthority as false and am giving my own root CA. The root CA has specific nameConstraints permitting only a pair of domain names.

While providing this CA through secret is when the zookeeper pods are crashing saying No CA found

Not sure where the server certificates come into picture here

[scholzj]

The CA is used to sign the server certificates. So without any further details, it needs to allow them to use the SANs and common names they need to use.

[govihari]

I have the extensions as below:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name:
DNS:xxx.xxx.com, IP Address::xx.xx.xx.123
X509v3 Name Constraints: critical
Permitted:
DNS:xxx.xxx.com
DNS:xxx1.xxx.com

With this, it should be able to sign all the certificates in the specified DNS. I guess, kafka is trying to get the cluster under kafka.local? and that is the reason? How do I circumvent this?

Again, even here, the No CA is not correct, I feel

[scholzj]

The Kafka cluster is running inside Kubernetes. So it has to use the Kubernetes addresses / DNS names and it has to have them in the certificates for the TLS to work.

Assuming this issue is caused by the naming restrictions (sounds reasonable, but I do not know anything else about your cluster and never used the naming restrictions, so cannot know for sure), then the only solution is to fix or remove them. The Kubernetes cluster is using private DNS names, so it makes little sense to have them there.

I'm not really sure why are you trying to use a CA which looks like this - not sure what your motivation is. But TBH It makes only little sense to have these restrictions in a Cluster CA.