i:/C=US/ST=State/L=Location/O=, Inc./OU= Daddy Secure Certificate Authority - G2 1 s:/OU=Domain Control Validated/CN= *. However, every once in a while, this happened: $ openssl s_client \ -connect clientsite.tld:443 \ -servername clientsite.tld \ 2> /dev/null \ | grep ' CN ' 0 s:/OU=Domain Control Validated/CN= *. The above example is a functioning one, it correctly returned us the certificate of the site, and we could verify everything was intact. This is what you'd expect: a connection to the host clientsite.tld, where we make clear that we want to retrieve the certificate information using SNI - Server Name Indication. It's similar to how OpenSSL's client would do it: $ openssl s_client \ -connect clientsite.tld:443 \ -servername clientsite.tld \ 2> /dev/null \ | grep ' CN ' 0 s:/CN=clientsite.tld i:/C=US/O=Let ' s Encrypt/CN=Let ' s Encrypt Authority X3 1 s:/C=US/O=Let ' s Encrypt/CN=Let ' s Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 subject=/CN=clientsite.tld issuer=/C=US/O=Let ' s Encrypt/CN=Let ' s Encrypt Authority X3 When we connect to a host to do our in-depth certificate analysis, we fetch as much information as we can. We were sending alerts to clients that their certificates had changed, but they could never quite verify this.
In this case, we received reports from multiple of our clients that our certificate change reporting "seemed wrong". This allows us to quickly identify situations where a certificate has changed (use case: did you renew all the SANs on the certificate?) or one that has incorrectly been replaced. With over 250 checks a day for the SSL certificate alone, it means we have a lot of opportunities to catch errors related to your site certificates.
We fetch and validate the SSL TLS x.509 certificates every 5 minutes, for each site, to report on changes and problems. While we're a traditional website monitoring service in some aspects, we do a couple of things differently from our competition (and I'm not just talking about our crawler that looks for broken links & mixed content). In this post, we'll do a technical deep-dive into how we found this problem! Why we found it in the first place We do this slightly different than other providers, which is why were able to detect a problem with the SSL certificates of a large, commercial, CDN provider. As part of our service, we perform SSL certificate monitoring.
0 kommentar(er)
