-
Notifications
You must be signed in to change notification settings - Fork 3.9k
xDS with TrafficDirector and spiffe: CertificateException: no name matching foo.bar found #10810
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
From a brief glance, spiffe id is incorrect. Normally it would be |
sorry thats part is on me removing some information before posting.. the actual spiffe id is correct but its that not being equal to foo.bar thats throwing the exception |
Also, that CSDS dump doesn't show any endpoints. It should be something like "endpoints": [{
"locality": {
"subZone": "ib:us-central1-a_2827676496526826176_neg"
},
"lbEndpoints": [{
"endpoint": {
"address": {
"socketAddress": {
"address": "10.12.0.189",
"portValue": 8080
}
}
},
"healthStatus": "HEALTHY"
}],
"loadBalancingWeight": 1000000
}] I'm attaching a log file with xDS responses received by grpc-java 1.60.x xDS client setup for spiffe TLS: downloaded-logs-20240110-104310.csv. Hope this helps while we're looking into this. Here's the TD setup we did for the attached client log: setup.log. However, It's not GCE, but k8s-to-k8s. |
Which Java version are you using? I'm suspicious that it may matter. It seems weird to me that |
zulu21.30.15-ca-jdk21.0.1-linux_x64 |
I just ran our tests with
The tests passed, so I commented out the
The failure path is close but not identical, at least partly because the test certs had a different SAN setup. But I think the important part is X509TrustManagerImpl.java:291. That line should only be executed if |
stepping through I see that after disabling the check in sslParams, |
I thought I put a comment here, but now I wonder if I put it somewhere else... I noticed AdvancedTlsX509TrustManager sets the endpoint identity algorithm to "", not null. |
For posterity, both netty-tcnative and Conscrypt appear to observe XdsX509TrustManagerTest failing or passing doesn't tell us much, because it uses a fake SSLEngine. |
grpc_java version 1.60.0
Hello,
I'm trying to get traffic director to provide security configuration to a client but I am encountering a failure in checkServerTrusted of XdsX509TrustManager https://github.com/grpc/grpc-java/blob/v1.60.0/xds/src/main/java/io/grpc/xds/internal/security/trust/XdsX509TrustManager.java#L244
because the target hostname does not match the SAN (spiffe id) in the server cert. I am wondering if the problem lies with the config from TD or with the client.
here is a snippet of the java code, written using the xds example in this repo:
stack trace:
and this is xds config traffic director is giving the client:
I should mention also TD is being configured via a NetworkSecurityClientTLSPolicy attached to a ComputeBackendService as documented here: https://cloud.google.com/traffic-director/docs/security-overview#:~:text=A%20client%20TLS%20policy%20lets,a%20global%20backend%20service%20resource.
I've tried adding the spiffe id as an subjectAltName to the computebackend service which does appear in the xds config under defaultValidationContext but iiuc that isnt used until verifySubjectAltNameInChain in https://github.com/grpc/grpc-java/blob/v1.60.0/xds/src/main/java/io/grpc/xds/internal/security/trust/XdsX509TrustManager.java#L245
Thanks
The text was updated successfully, but these errors were encountered: