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