HI Sachin,
Thanks a bunch for the quick response. Currently the camera (server) is running avahi and the uses mdns to find all cameras found on the network. I then use the IP address of a discovered camera to connect. The IP address of the camera or the clients are dynamic and are typically assigned by DHCP so I don’t think a static IP address would work. I can assign a hostname to the camera (server) though I cannot assign one to the clients. I have few questions based on my ignorance of mTLS. Assuming I could add the hostname of the camera to its server certificate’s common name, is this what the client will use in addition to the signature check to validate the server ? Given that the client can be any machine, I only want to confirm that the client program written by me is the one that can connect to the server. Is there a way I can tell the server to only validate the signature of client supplied certificate and skip the host name or IP address checks ? Finally, a question about subjectAlternateName. I’ve currently added the 0.0.0.0 address to both the server and client extension files. What does it mean to the client when it see a IP address of 0.0.0.0 in the server certificate’s subjectAlternativeName. Does it mean the client will accept the connection only if the server is on localhost ? Similarly what does it mean to the server when it sees 0.0.0.0 in the client’s subjectAlternativeName ? Thanks a bunch for the help and I truly appreciate your time. Here are logs of a remote call made from my computer to the camera both of which are on my home wifi. Server Sep 12 22:46:32 buildroot kt_cam[204]: E0912 22:46:32.284179389 208 ssl_transport_security.cc:1807] No match found for server name: 10.0.0.39. Client [2022-09-12 15:46:32.235] [info] Running on 10.0.0.39:50051 [2022-09-12 15:46:32.246] [info] Starting [2022-09-12 15:46:32.410] [error] 14: failed to connect to all addresses [2022-09-12 15:46:32.410] [info] Greeter received: RPC failed The only error I get from the client when I call the stub is “failed to connect to all addresses” however on the server end I get the above error which says no match for server name. Little confused why it says that. P.S: 10.0.0.39 is the server (camera) IP address. Thanks again for the help. Kartik On Monday, September 12, 2022 at 2:39:26 PM UTC-7 [email protected] wrote: > Hi Kartik, > > The below answer is assuming that your local mTLS is working but remote > mTLS is failing. If this is not the case, clarify what is not working and > are you getting any error logs. > > It is not mandatory for the client's IP to be part of the client's cert. > But the server's cert needs to have the server's IP or hostname. This > should match with how the client is going to connect to the server. > > For the local client, 0.0.0.0 might work but for the remote clients > running on a different machine, this server cert does not work. > > How is the remote client connecting to the server? > 1. If it is based on IP directly, add that IP as well in the server cert. > You can add multiple IPs in SAN > 2. If it is based on hostname, add the DNS name something like > this: subjectAltName=DNS:<serverHostname>,IP:x.y.z.a > > Let us know if it works > > Regards, > Sachin > > On Mon, Sep 12, 2022 at 2:02 PM 'Kartik Aiyer' via grpc.io < > [email protected]> wrote: > >> The following script is what I used to generate the certificates >> >> #!/bin/bash >> rm *.pem >> # Generate a self-signed CA certificate and private key >> openssl req -x509 -newkey rsa:4096 -days 3650 -keyout ca-key.pem -out >> ca-cert.pem -nodes -subj >> "/C=US/ST=California/O=Motive/OU=Embedded/CN=sc1-grpc-ca" >> # Display info on self-signed CA certificate >> openssl x509 -in ca-cert.pem -noout -text >> # Generate a server private key and CSR >> openssl req -newkey rsa:4096 -keyout kt-cam-key.pem -out kt-cam-req.pem >> -nodes -subj "/C=US/ST=California/O=Motive/OU=Embedded/CN=sc1-kt-cam" >> -addext "subjectAltName = IP:0.0.0.0" >> # Use the CA cert to sign the kt-cam server CSR >> openssl x509 -req -in kt-cam-req.pem -CA ca-cert.pem -CAkey ca-key.pem >> -CAcreateserial -out kt-cam-cert.pem -days 3650 -extfile kt-cam-ext.cnf >> # Generate a client private key and CSR for kt_iot >> openssl req -newkey rsa:4096 -keyout kt-iot-key.pem -out kt-iot-req.pem >> -nodes -subj "/C=US/ST=California/O=Motive/OU=Embedded/CN=sc1-kt-iot" >> -addext "subjectAltName = IP:0.0.0.0" >> # Use the CA cert to sign the kt-iot client CSR >> openssl x509 -req -in kt-iot-req.pem -CA ca-cert.pem -CAkey ca-key.pem >> -CAcreateserial -out kt-iot-cert.pem -days 3650 -extfile kt-iot-ext.cnf >> # Generate a client private key and CSR for kt_cli >> openssl req -newkey rsa:4096 -keyout kt-cli-key.pem -out kt-cli-req.pem >> -nodes -subj "/C=US/ST=California/O=Motive/OU=Embedded/CN=sc1-kt-cli" >> -addext "subjectAltName = IP:0.0.0.0" >> # Use the CA cert to sign the kt-cli client CSR >> openssl x509 -req -in kt-cli-req.pem -CA ca-cert.pem -CAkey ca-key.pem >> -CAcreateserial -out kt-cli-cert.pem -days 3650 -extfile kt-cli-ext.cnf >> >> All the extension files look like this >> >> subjectAltName = IP:0.0.0.0 >> >> Thanks >> Kartik >> On Monday, September 12, 2022 at 1:51:39 PM UTC-7 Kartik Aiyer wrote: >> >>> Hello folks >>> >>> We have implemented a gRPC server on our embedded linux based camera and >>> have a couple of clients that are expected to run on both the camera itself >>> (so local loopback connection) as well as on host computers that are on the >>> same subnet as the camera. Both the server and clients are written in C++ >>> and use the gRPC C++ API. I’m trying to use mutual TLS so that only clients >>> written by us can connect to the server. >>> >>> I setup a self-signed root CA and used it to sign a server certificate >>> and client certificate (more than one client certificate since I have more >>> than one client). I’m not sure what is the best way to setup the >>> certificate. From what I understand that either the common name or >>> subjectAlternativeNames will be used to verify a connection in addition to >>> the signature with the root certificate. >>> Server >>> >>> - I can setup the camera’s hostname to something that will match the >>> common name in the certificate. Is this the recommended approach ? >>> >>> Client >>> >>> - I can’t set the hostnames of the clients, so I’m not sure what to >>> put in the common name for the server to verify. Any recommendation here >>> ? >>> >>> Currently I’m using a subjectAlternativeName of IP:0.0.0.0 which allows >>> me to make calls over local loopback but its not usable over the network. >>> >>> I’m using SslCredentials and SslServerCredentials but I’m wondering if >>> I should be using the TlsCredentials and TlsServerCredentials with some >>> kind of of custom verification callback. I would appreciate any advice on >>> setting up the certificates appropriately for the usecase I have described. >>> >>> To summarize, the client is expected to connect to the cameras on the >>> same network and be able to use the remote API. >>> >>> Thanks >>> Kartik >>> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/grpc-io/87e3c94e-2935-46c4-8bd7-fd407f9070d0n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/grpc-io/87e3c94e-2935-46c4-8bd7-fd407f9070d0n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/077c26fa-1125-4180-888c-c52418aebdd2n%40googlegroups.com.
