Authentication handshake failed: x509: cannot validate certificate for 10.0.10.186 because it doesn't contain any IP SANs

Community Support
1

Trying some mTLS examples and getting this error

"transport: authentication handshake failed: x509: cannot validate certificate for 10.0.10.186 because it doesn't contain any IP SANs"

FWIW, the IP corresponds to the history service.

The issue is, our services may come up on any IP address in the subnet (10.0.0.0/16), however in the openssl config it appears you cannot add an entire IP address block to the SAN config.

How does one work around this? Is there a way to tell the SDK to connect via hostname instead? (All the services have a service.domain-name.com DNS entry, and these ARE in the SAN config for the cert).

The web UI and TCTL command line work fine, so not sure why the SDK examples are failing. I’m providing the exact same certs.

I am telling the SDK to connect to the frontend via DNS name, but I think $something is happening where its connecting to the other services via their internal IP, and baulking because those IPs are not in the cert SANs.

2

hmm. If I set the following vars ONLY on the worker service, it seems to work. Not sure if that’s a good thing or not. :joy_cat:

        "TEMPORAL_TLS_SERVER_CA_CERT" = "/temporal/ca.cert"
        "TEMPORAL_TLS_SERVER_CERT"    = "/temporal/cluster.pem"
        "TEMPORAL_TLS_SERVER_KEY"     = "/temporal/cluster.key"

It looks like because I have the TLS_FRONTEND and CLI_TLS vars set on the other services, I should be good from a security PoV (i.e. anonymous people wouldn’t be able to make calls to our frontend/api). Can anyone confirm / or is there a good way to test the frontend won’t accept any unauthenticated requests?

3

because it doesn’t contain any IP SANs

From the client perspective, do your sdk clients/workers connect directly to frontend or go through an API gateway / LB? From what I understand frontend service does not require IP SANs. If so maybe check this proxy configuration.

4

The clients connect via a load balancer, which points to the frontend.

The other services can connect either via local IPs, or via the same load balancer if they knew how to. Pretty sure they all talk on local IPs, hence the above error. :slight_smile: