Can Prometheus scrape TLS and mTLS targets using a common scrape job?

I tested this myself, I can see both TLS and mTLS targets scraped by Prometheus with a common scrape job.

My Prometheus job has the below configuration:
scheme: https
tls_config:
ca_file: /run/cacertbundle.pem
cert_file: /run/clicert.pem
key_file: /run/cliprivkey.pem
server_name: my-favorite-target
insecure_skip_verify: false

I expected TLS config as below:
scheme: https
tls_config:
ca_file: /run/cacertbundle.pem
server_name: my-favorite-target
insecure_skip_verify: false

I wonder how TLS and mTLS work simultaneously. I’m happy that Prometheus can scrape TLS and mTLS targets using a common scrape job but I didn’t understand the underlying design pattern. Can someone explain this behavior?

Thanks,
Teja

https://www.ietf.org/rfc/rfc5246.txt, 7.4.6. Client Certificate section says

" This is the first message the client can send after receiving a
ServerHelloDone message. This message is only sent if the server
requests a certificate. If no suitable certificate is available,
the client MUST send a certificate message containing no
certificates. That is, the certificate_list structure has a
length of zero. If the client does not send any certificates, the
server MAY at its discretion either continue the handshake without
client authentication, or respond with a fatal handshake_failure
alert. Also, if some aspect of the certificate chain was
unacceptable (e.g., it was not signed by a known, trusted CA), the
server MAY at its discretion either continue the handshake
(considering the client unauthenticated) or send a fatal alert."

Now I understand how this works.

  • TLS Server, Scrape Target will send its certificates to TLS Client
  • TLS Client, Prometheus will verify TLS Server Certificate
  • TLS Client, Prometheus will send its certificates to TLS Server
  • TLS Server, Scrape Target continue the handshake without client authentication (let’s say it doesn’t support mTLS, clientAuthType is set to “NoClientCert”)
1 Like