britcey commented 2 years ago

Hi @ribbybibby,

I can't quite decide if I need to write a new exporter or open a PR with ssl_exporter:

We have internal OCSP servers for our internal CAs; we have some old Nagios tests using openssl to ensure they're still properly responding, via:

/usr/bin/openssl ocsp -host ocsphost1.example.com:80 -path /ocsp -issuer ./ExampleCorpRoot.crt -cert ./ExampleCorpServerCA.crt

i.e., we're probing a particular OCSP host and path (instead of using the 'OCSP Server URL(s)' listed in the client cert), with a given cert and issuer to ensure we're getting back a good OCSP response (we're using one of the subordinate CAs as the 'client' cert, since it's long-lived).

We're providing the issuer cert vs. downloading it from the 'Issuing Certificate URL' in the client cert, since we want to isolate testing to just the OCSP functionality.

Would it make sense to add an 'ocsp' prober? You'd have to specify the 'client' cert in the prober config and, optionally, the issuer (otherwise have it download the issuer cert as specified in the client cert).

I don't think there would even be any new metrics, just the existing sslocsp* ones.

Thoughts?

britcey commented 2 years ago

Open PR #101

johanfleury commented 2 years ago

This is probably a duplicate of #63.

britcey commented 2 years ago

It's a bit different - this is to check if a OCSP responder itself is functioning - the OCSP responder is the target.

63 might flag a non-functioning responder as a side-effect of checking the OCSP response, but wouldn't tell you which responder was non-functional, etc.

It'd only be of interest to people running their own CA and OCSP responders (as we do, internally).

ribbybibby / ssl_exporter

OCSP server check? #100

63 might flag a non-functioning responder as a side-effect of checking the OCSP response, but wouldn't tell you which responder was non-functional, etc.