certificate transparency

I went to a certificate transparency hack day at google london.

Dodgy x509 host certs really annoy me - they were a hassle when I worked on globus where we pretty much have out free host certs without any checking, to anyone who asked.

An achievable goal seemed to be to get a nagios plugin to check for certificates issued against a given hostname. I sort of have that working, with both OK/CRITICAL and a graph:

For now, the plugin is looking for certificates with the substring google in the subject name - there are plenty of such certificates in the log

When new certificates are discovered, they count as suspicious: they appear in red on the graph and the nagios notification system sends me an email. When an administrator (i.e. me) approves of the certs (by running an appropriate script), they turn into OK certificates and go green on the graph.

The underlying python code I'm using has a terribly slow ASN.1 parser, and so is only getting through a few hundred of the 2 million certs in the log every minute (see the blue line on the graph) - in a few days time hopefully it will have caught up. At least gives a pretty graph over time. In real life I'd expect a much smaller number of green certificates and hardly any/zero red certificates, as a flat line over time.

My original intention was to use this for matching domain names, but someone pointed out that it could be used to matching eg. trademark names anywhere in a certificate for some anti-phising detection.

Plenty of flaws:

• doesn't check certificate alternate names (subjAltName)
• doesn't check domain names at all
• doesn't check consistency of data coming from the log server
• doesn't deal with multiple log servers
• doesn't deal with multiple domain name probes efficiently (eg by caching or sharing download/ASN.1 decoding between domain names) - this is perhaps better implemented by using Nagios's passive plugin interface where a monitor could push interesting results (for various domains) into Nagios, rather than the present active/polling style (whichI chose because its easy to do)
• doesn't deal with unknown certificate extensions (at the moment, it ignores them which I think is sometimes the wrong behaviour - if the extension is one that authorises the use of new names (such as subjAltName does...)
• its fairly synchonous which is a bad thing for nagios probes - spending 2 days to verify the initial log is not good for a probe that should take less than 10s

https in cpanel

working with someone who has a cpanel server. they want https on it. cpanel doesn't do that by default. google doesn't reveal much in the way of tutorials for this, so here's a note for people to find.

1. generate a key pair and certificate using the Generate a SSL Certificate & Signing Request page. Copy the certificate onto your clipboard.
2. go to the Install a SSL Certificate and Setup the Domain page. Paste in the certificate. click fetch on the key text field and it should populate that field for you. Set the username to nobody so that all users can use this key pair.
3. When you save that page, apache will reload and you'll get https service on port 443, with a self-signed certificate (and so with consequent certificate mismatch error messages). But your existing domains won't work on that server - they'll go to the default cpanel parking page - cpanel only configures its virtual hosts on port 80... grr
4. So next I made an apache mod_rewrite rule in the VirtualHost directive for the port 443 virtual server. That causes all the internal sites appear on port 443.

       RewriteEngine on
       RewriteRule   ^(.+)          http://%{HTTP_HOST}$1 [P]
   

   That's an awkward hack to have to add to cpanel's generated config, but it seems to work (modulo invalid certificate warnings that all users ignore anyway)...

There's also a hole in the way that that rewrite rule is implemented: with a custom http client, you can probably make this server act as an arbitrary proxy for you, depending on mod_proxy configuration.