On Thursday, 7 May 2020 01:27:14 UTC+1, H T wrote: > > In my case, remote server is using a self-signed certificate and based on > your comments I tried the below approach which worked and other which > didn't. > > *Working Scenario -> (Both remote server and Prometheus using same CA > certs but separate private and crt files)* > > 1.) Self-signed CA certs were generated first(crt and key files) > 2.) Remote server (Node.js app) used above CA to generated its crt and key > files. > 3.) Prometheus server running on a separate box used above CA to generated > its crt and key files. > > For clarity, this isn't what I'd describe as the server using a "self-signed cert". All CA root certificates are self-signed, by definition.
This is what I'd describe as a private CA, which is issuing certs for both the remote server and the prometheus server. > > *Not working Scenario -> (Remote server and Prometheus using their own CA > certs) -* I think this is expected behavior. > > Do you mean, two different private CAs? This should work fine. At each end, the "ca_cert" setting that you give is the *other* CA, i.e. the one you need to use to verify the peer's certificate. e.g. at the prometheus end: tls_config: key_file: "server.key" # my key cert_file: "server.crt" # my certificate, signed by CA 1 ca_file: "ca.crt" # CA 2's root certificate, used to verify exporter's cert At the exporter side it's the other way round. Should we always use the same CA to generate Remote server and Prometheus > certs for HTTPS communications? Also, should both remote servers and > Prometheus client use the same key and cert files? > Don't use the same key and cert for both ends. This would mean that the node's certificate could be used to pretend to be prometheus. Actually, that's a good reason for using two different CAs. At the moment, prometheus verifies the identity of the exporter's certificate matches the hostname in the HTTPS scrape URL (you can override the identity using the "server_name:" setting); but node_exporter doesn't verify the identity of prometheus' certificate. So any node could use its own cert to scrape any other node. You can workaround this by signing prometheus' certificate by a different CA, and then node_exporter only trusts *that* CA. However if you are writing your own custom exporter, you can add a check to verify the client certificate's identity is the one which belongs to prometheus. > > Lastly, our remote server is running on a VM and we have other apps > running inside a docker container and pods. As of now, I am we are using > DNS names like (test.server.com) and it works. But I would like to know > if we can generate certs for IP address(127.0.0.1), localhost, and use them > instead of DNS name. Our goal is that the remote server will expose > /metrics api at default IP like 127.0.0.1 and generate certs which > Prometheus uses to connect- but we are not sure how can we generate certs > for default IP or loccalhost > Well, you technically you *can* issue certs for an IP address - there is a SAN IP address extension. It's unconventional and I wouldn't recommend it, and I wouldn't be surprised if not all software supports it. Better to use /etc/hosts if you need to force the IP address. Also, using SSL for communication to 127.0.0.1 or localhost is pretty pointless. -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/02dab5a6-7363-4714-8946-c0ef69ec8bf1%40googlegroups.com.
