FYI: I got a similar error.. https://github.com/grpc/grpc-java/pull/2662
explains our configuration.
On Thursday, January 26, 2017 at 11:52:54 AM UTC-8, Carl Mastrangelo wrote:
>
> 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/776e5dc2-9df3-4df9-97f5-bdea194136bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
