xoxys/thegeeklab
1
0
Fork 0
Code Issues 1 Pull Requests Releases Wiki Activity

chore: small adjustmens
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse Source
This commit is contained in:
Robert Kaussow 2022-01-31 23:16:26 +01:00
parent 13e190796c
commit bf79c630d5
Signed by: xoxys
GPG Key ID: 4E692A2EAECC03C0
2 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
config.yml
View File

@ -7,6 +7,7 @@ pygmentsCodeFences: true
enableGitInfo: true
paginate: 5
enableEmoji: True
markup:
goldmark:

2
content/posts/ssl-certificate-monitoring-pitfalls/index.md
View File

@ -22,4 +22,4 @@ I'm using Prometheus to monitor my infrastructure, and for Prometheus there are
A week ago, Let's Encrypt has informed affected users that they need to [revoke faulty certificates](https://community.letsencrypt.org/t/questions-about-renewing-before-TLS-ALPN-01-revocations/170449) issued and validated with the `TLS-ALPN-01` challenge. Even if I'm using the `DNS-01` for almost all of my certificates, I have also received a mail and started to look into it. Sadly, the notification mail only contained a "random" ACME registration ID, and I was not able to find the matching client. As mentioned, I don't really use `TLS-ALPN-01`, so I decided to stop the research and leave it to my monitoring to tell me which forgotten service is the evil one after the certificates were revoked. Nothing happened after the revocation, and the monitoring was not complaining. Good - well no, a user reported that one of the services is not reachable anymore and of course this was the one missing client that was using `TLS-ALPN-01` verified certificates - dang. While the issue itself was easy to resolve by a force renew of the certificate, I was still wondering why the monitoring has not caught it.
Well, this was the first time that I had to deal with _revoked_ certificates instead of _expired_ certificates. To be honest, I never thought about the detection of revoked certificates in my monitoring setup before, and therefore this case wasn't covered. But it looks like a fix is also not that straight forward as expected. The used Telegraf input `x509_cert` is not able to detect revoked certificates yet, and the common Prometheus [`blackbox_exporter`](https://github.com/prometheus/blackbox_exporter/issues/6) also don't want to handle this case. The only way I have found so far is to use the [`ssl_exporter`](https://github.com/ribbybibby/ssl_exporter) that provides some revocation information of the certificates using OSCP. If you are already running multiple exporters, that might be the way to go for you. Personally, I prefer to handle as much as possible using Telegraf, so I might look into a [fix](https://github.com/influxdata/telegraf/issues/10550) for the `x509_cert` during the next weeks.
Well, this was the first time that I had to deal with _revoked_ certificates instead of _expired_ certificates. To be honest, I never thought about the detection of revoked certificates in my monitoring setup before, and therefore this case wasn't covered. But it looks like a fix is also not that straight forward as expected. The used Telegraf input `x509_cert` is not able to detect revoked certificates yet, and the common Prometheus [`blackbox_exporter`](https://github.com/prometheus/blackbox_exporter/issues/6) also don't want to handle this case. The only way I have found so far is to use the [`ssl_exporter`](https://github.com/ribbybibby/ssl_exporter) that provides some revocation information of the certificates using OSCP. If you are already running multiple exporters, that might be the way to go for you. Personally, I prefer to handle as much as possible using Telegraf, so I might look into a [fix](https://github.com/influxdata/telegraf/issues/10550) for the `x509_cert` during the next weeks. However, lessons learned :blue_book: