From bf79c630d5bb13d924021bf004fd2233cfcdd110 Mon Sep 17 00:00:00 2001 From: Robert Kaussow Date: Mon, 31 Jan 2022 23:16:26 +0100 Subject: [PATCH] chore: small adjustmens --- config.yml | 1 + content/posts/ssl-certificate-monitoring-pitfalls/index.md | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/config.yml b/config.yml index b3ccd46..cc0a7fd 100644 --- a/config.yml +++ b/config.yml @@ -7,6 +7,7 @@ pygmentsCodeFences: true enableGitInfo: true paginate: 5 +enableEmoji: True markup: goldmark: diff --git a/content/posts/ssl-certificate-monitoring-pitfalls/index.md b/content/posts/ssl-certificate-monitoring-pitfalls/index.md index 05d83cb..fc671b2 100644 --- a/content/posts/ssl-certificate-monitoring-pitfalls/index.md +++ b/content/posts/ssl-certificate-monitoring-pitfalls/index.md @@ -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: