Hi,
The error is caused by my NameResolver implementation returning the service
id as authority:
public class DiscoveryClientNameResolver extends NameResolver {
private DiscoveryClient discoveryClient;
private final String name;
private Listener listener;
public DiscoveryClientNameResolver(String name, DiscoveryClient
discoveryClient) {
this.name = name;
this.discoveryClient = discoveryClient;
}
@Override
public String getServiceAuthority() {
return name;
}
@Override
public void start(Listener listener) {
this.listener = listener;
refresh();
}
@Override
public void refresh() {
List<ResolvedServerInfo> servers = new ArrayList<>();
for (ServiceInstance serviceInstance :
discoveryClient.getInstances(name)) {
if (serviceInstance.getMetadata().get("type").equals("grpc")) {
servers.add(new ResolvedServerInfo(
InetSocketAddress.createUnresolved(serviceInstance.getHost(),
serviceInstance.getPort()),
Attributes.EMPTY));
}
}
Collections.shuffle(servers);
this.listener.onUpdate(Collections.singletonList(servers),
Attributes.EMPTY);
}
@Override
public void shutdown() {
}
}
My question then becomes how the NameResolver is supposed to return the
correct authority for the connection in progress so that TLS verification
succeeds ? At the ClientInterceptor level i do not seem to have access to
this information.
Jorg
On Thursday, January 26, 2017 at 2:17:14 PM UTC+1, Jorg Heymans wrote:
>
> Small mistake in my mail, the stacktrace is shown clientside NOT
> serverside.
>
> Jorg
>
> On Thursday, January 26, 2017 at 1:13:07 PM UTC+1, Jorg Heymans wrote:
>>
>> Hi,
>>
>> I have a grpc client-server setup using TLS (ClientAuth.REQUIRE) which is
>> working fine. I am now trying to implement service discovery using Spring
>> DiscoveryClient and zookeeper, very much like what was done here for eureka
>> https://gist.github.com/Xorlev/eafce32667931b78fac003f228cedc53#file-eurekanameresolver-java-L51
>>
>> .
>>
>> Basically in the client I am creating a
>> channel.forTarget("zookeeper://myservice-dev").nameResolverFactory(...).sslContext(...)
>>
>> and i get this exception serverside:
>>
>> Caused by: java.security.cert.CertificateException: No subject
>> alternative DNS name matching myservice-dev found.
>> at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:204)
>> at sun.security.util.HostnameChecker.match(HostnameChecker.java:95)
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:436)
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:252)
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
>> at
>> io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:223)
>>
>> It seems that the logical service id i am trying to connect to is used
>> during TLS verification. Is this expected ? Adding this service id in the
>> certificate SubjectAltNames makes things work but that's not a real
>> solution. I have verified that the service discovery works fine without TLS
>> and it does.
>>
>> Any ideas what could be causing this, is it expected at all ?
>>
>> Many thanks,
>> Jorg
>>
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/5e8ad0fd-4680-4942-a654-7c8b67066391%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
