Trust bundle should use leaf certificates #1498
Description
In what area(s)?
/area runtime
/area operator
/area placement
/area docs
What version of Dapr?
All
Behavior
When any of the Dapr control plane components load (operator, placement, sidecar injector, sentry), they load with the trust bundle secret which includes the (ca.crt, issuer.crt and issuer.key). The trust bundle secret is created by Sentry with either provided or generated certificates. These certificates are loaded as the cert chain and used to configure each of the API's TLS configs. The Dapr sidecar injector also reads the trust bundle secret and injects the config into each daprd sidecar using the environment variables DAPR_TRUST_ANCHORS, DAPR_CERT_CHAIN, DAPR_CERT_KEY. These daprd sidecar then loads these certificates and uses it for the client certificate when connecting to any of the Dapr control place servers. As the root ca (ca.crt) is loaded into the trusted CAs the mTLS authentication succeeds.
However, a change was made in Go 1.15.2 that meant that a SAN field should be used to verify leaf certificates rather than the CN. This resulted in the following error if a SAN field was not set on the certificate x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0.
When using Sentry to automatically create the root and issuer certificates, this isn't a problem as it adds the SAN extensions and add a DNS SAN entry. However, when trying to create your own certificates as documented in the Dapr docs with step certificate you cannot create a root CA or intermediate CA certificate with a SAN. I initially worked around this using openssl to include a SAN entry, however, on further inspection, it turns out this was a conscious decision not to allow Root CAs or Intermediate CAs to have SANs. This resulted in Linkerd changing the way they verify the root and intermediate certificates.
Given this, we can work around this as is done in Sentry today and offer alternative documentation with openssl instead of step certificate or we can look to address this and use leaf certificates for the gRPC TLS config rather than the CA certificates.