Slashdot Mirror

https://crt.sh/

It uses SQL style wildcards (%) so you can search e.g. %.slashdot.org.

https://crt.sh/

It uses SQL style wildcards (%) so you can search e.g. %.slashdot.org.

For example, I can look at my old university's computer society's CT log and see that they switched from StartCom to Let's Encrypt when everyone stopped trusting StartCom last year and see that their last three certificates all have different public keys, which implies that either someone is rapidly rolling over certs for no reason and is a numpty, or that someone else is playing silly buggers.

That seems pretty reasonable: all of the listed certs from 2016-09-23 to the present (except on 2017-05-21, I have no idea what's going on there) have been replaced at 2-month intervals, which is in line with the recommendations and when the reference implementation of their ACME client (certbot) renews certs (the certs are valid for 90 days and are renewed after 60 days). Each renewal involves the generation of a new public/private keypair. All in all, seems pretty reasonable.

It demonstrates that the one holding the cert also holds the domain name. Nothing else. And nothing else is implied by the whole deal.

Not quite: the key exchange happens over HTTP and doesn't always use DNSSEC, so all that it actually proves is that the person issuing the certs was able to receive and reply to TCP packets going to the IP address that the Let's Encrypt server's DNS reported was associated with the domain name. That's a somewhat weaker guarantee (though no weaker than most non-EV certs).

Let's Encrypt also logs all certs with certificate transparency and so you can check (by grabbing the CT logs or using a web search) which certs have been issued for your domain and see if any of them don't match the public key that you think that you're using (and you can automate this from another machine). Chrome also reports certificates that it's seen to the CT logs, so you can spot when someone sees a cert that you don't think is yours. For example, I can look at my old university's computer society's CT log and see that they switched from StartCom to Let's Encrypt when everyone stopped trusting StartCom last year and see that their last three certificates all have different public keys, which implies that either someone is rapidly rolling over certs for no reason and is a numpty, or that someone else is playing silly buggers.

It demonstrates that the one holding the cert also holds the domain name. Nothing else. And nothing else is implied by the whole deal.

Not quite: the key exchange happens over HTTP and doesn't always use DNSSEC, so all that it actually proves is that the person issuing the certs was able to receive and reply to TCP packets going to the IP address that the Let's Encrypt server's DNS reported was associated with the domain name. That's a somewhat weaker guarantee (though no weaker than most non-EV certs).

Let's Encrypt also logs all certs with certificate transparency and so you can check (by grabbing the CT logs or using a web search) which certs have been issued for your domain and see if any of them don't match the public key that you think that you're using (and you can automate this from another machine). Chrome also reports certificates that it's seen to the CT logs, so you can spot when someone sees a cert that you don't think is yours. For example, I can look at my old university's computer society's CT log and see that they switched from StartCom to Let's Encrypt when everyone stopped trusting StartCom last year and see that their last three certificates all have different public keys, which implies that either someone is rapidly rolling over certs for no reason and is a numpty, or that someone else is playing silly buggers.

No it's not. Let's Encrypt is even a bigger offender. Example: Let's Encrypt issued over 15,000 certificates for domains containing PayPal in their name (obvious phishing sites): https://crt.sh/?identity=paypa...