exporter-toolkit icon indicating copy to clipboard operation
exporter-toolkit copied to clipboard

Further secure TLS communications

Open saroshali-dbx opened this issue 3 years ago • 6 comments

Closes https://github.com/prometheus/exporter-toolkit/issues/96

saroshali-dbx avatar Jun 06 '22 16:06 saroshali-dbx

gentle ping @roidelapluie @SuperQ :)

For context, here's the issue created for the downstream dependency - https://github.com/weaveworks/common/issues/242

saroshali-dbx avatar Jul 15 '22 14:07 saroshali-dbx

I thought most certificate validation has moved to verifying SANs, not CNs.

SuperQ avatar Aug 01 '22 04:08 SuperQ

I thought most certificate validation has moved to verifying SANs, not CNs.

Yeah, thats the intention with SANs to be able to get around the limitation of only being able to specify a single server-name in CN. I ported this functionality from etcd -- and my organization still utilizes common-name -- but I can update this PR to check SANs first and then fallback to CNs. How does that sound?

saroshali-dbx avatar Aug 01 '22 12:08 saroshali-dbx

Actually that's a good point @SuperQ , even go uses SAN's and has removed support for CN. I think we should follow go and use SANs

roidelapluie avatar Oct 18 '22 10:10 roidelapluie

@saroshali-dbx are you likely to return to this, or shall we close it?

bboreham avatar Mar 17 '23 12:03 bboreham

Just a question: isn't SAN or any other DNS unusual for client certs? I usually create them with

C = DE, ST = xxx, L = xx, O = xxx, OU = xxx, [email protected]

Thus given the 3.2 SHOULD check the identity as described above

leads me to Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used

logopk avatar Mar 17 '23 15:03 logopk