The interesting architecture of crt.sh
A while back I wrote myself a little dashboard for monitoring TLS certificates for my domains. Right now it works by talking to https://crt.sh/. Sometimes this works great, but sometimes crt.sh is really slow. Plus, it’s another thing that could be compromised.
So, I started looking at how crt.sh works. It’s kinda cool.
There are only 3 separate processes:
ct_monitoris program that uses libcurl to get CT log changes and libpq to put them into the database.
certwatch_dbis the core web application, written in PL/pgSQL. It even includes the HTML templating and query parameter handling. Of course, there are a couple of things not entirely done in pgSQL…
libx509pqadds a set of
x509_*functions callable from pgSQL for parsing X509 certificates.
cablint_embedded(bytea)function to pgSQL.
x509lint_embedded(bytea,integer)function to pgSQL.
- Apache HTTPD
The interface exposes HTML, ATOM, and JSON. All from code written in SQL.
And then I guess it’s behind an nginx-based load-balancer or somesuch (based on the 504 Gateway Timout messages it’s given me). But that’s not interesting.
The actual website is run
from a read-only slave of the master DB that the
ct_monitor cron-job updates; which makes several security
considerations go away, and makes horizontal scaling easy.
Anyway, I thought it was neat that so much of it runs inside the database; you don’t see that terribly often. I also thought the little shims to make that possible were neat. I didn’t get deep enough in to it to end up running my own instance or clone, but I thought my notes on it were worth sharing.