If you do not want to use SslTargetNameOverride, the other alternative is using SPIFFE credential in gRPC. This work is coming soon (estimate by the end of this year).
https://github.com/grpc/proposal/pull/98 https://github.com/grpc/grpc/pull/16614#pullrequestreview-179042959 In SPIFFE credential for gRPC, we will not verify hostname, instead, there is server authorization callback, where gRPC core will provide the peer identity and peer certificate chain, it is up to the caller's authorization policy to decide whether to accept server's credential. Mapping to your use case, you just need to check hostname in the server's certificate in the callback. We envision that SPIFFE credential rather than current SSL credential will be used for service-to-service communication. On Monday, November 19, 2018 at 12:57:19 PM UTC-8, Robert Engels wrote: > > I don’t know the C++ gRPC api but would assume there is a method to > configure and control the SSL transport layer. Almost have to be otherwise > you need to duplicate the entire SSL api. > > On Nov 19, 2018, at 2:55 PM, solomon lifshits <[email protected] > <javascript:>> wrote: > > You got totally right what I was asking about, the question is whether > there is any plan to make that support on grpc/c++ legit, rather than test > only. > > On Monday, November 19, 2018 at 3:00:07 PM UTC-5, eagle wrote: >> >> Robert Engels <[email protected]> writes: >> >> > I’m not sure I follow. The client knows the host it is expecting to >> > contact and verified that the certificate sent matches that host. As I >> > said in a later email there is almost certainly a way to bypass the >> > check but not sure you can change the setting while going through gRPC >> > layer. >> >> There are two parameters here: the hostname or IP address to which to >> connect, and the FQDN used for SNI and for certificate verification. >> >> The request, at least if I understand it correctly, is to support >> decoupling them in the API so that the client can specify an IP address >> to >> connect to and separately specify the FQDN in SNI and certificate >> verification, because the client knows (via some mechanism outside the >> scope of the API) that it wants to connect to some specific IP that isn't >> associated in DNS with the FQDN, but knows what certificate identity to >> expect. >> >> This is a quite common problem with any software using SSL. There are >> often reasons why you want to connect to some internal IP that isn't in >> DNS or has the wrong DNS or whatever, but you know as the client what the >> certificate will and should be. >> >> -- >> Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> >> >> > -- > 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] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > 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/d453f639-f617-495f-b1ff-4f0028ab2120%40googlegroups.com > > <https://groups.google.com/d/msgid/grpc-io/d453f639-f617-495f-b1ff-4f0028ab2120%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- 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/ee06d3f2-2810-4da5-a14d-78a6c42df375%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
