Name resolution happens before the connection, so I'm not sure what you
mean by "connection in progress". Could you clarify?
Also, ClientInterceptors work on an RPC level, not a connection level. You
can change the authority there, but thats mainly for reducing connections
that go through the same backend, but are logically different.
On Thursday, January 26, 2017 at 6:46:08 AM UTC-8, Jorg Heymans wrote:
>
> 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/ebc9eea3-6acd-4c8b-8ca3-a3f30f6af5fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
