The idea that "2 billion certificates ought to be enough for any PKI" (to misquote Bill Gates) didn't seem that daft to me back when crt.sh was born (June 2015). Let's Encrypt had not yet launched, there were only a few million active certificates in the WebPKI (Introducing Universal SSL), and certificate lifetimes of >=1yr were the norm. However...
Yesterday, there was an int32-overflow.
Now a new database is startet.
The new database is currently busy importing data and building indexes. I'm hoping it'll be production-ready and available by early next week (caveat: I am rubbish at predicting ETAs). I'll update this thread with more details when I have them.
For the admins out there with MySQL/MariaDB databases, you can monitor your own databases with https://github.com/prometheus/mysqld_exporter and ensure youāre collecting the autoincrement stat.
Not really. In the Google group there is an update.
A test version runs under
91.199.212.73 crt.sh
so you can change your hosts file to use that new ip address. My tool "check your website" uses two CT monitors, Certspotter and crt.sh, so Certspotter shows the new certificates.
As there seems to be no progress or information about estimated recovery of this tool, are there any alternatives for crt.sh? I am aware of https://transparencyreport.google.com/, would you say this is comparable?
Thank You, I just checked out your tool. It is very informative and lists a lot of possible problems and checks for best practices. I have two questions about it.
How is it possible to display all published certificates for a given domain (and it's subdomains), like it was possible with crt.sh or the google-tool? I couldn't achieve this here, I have to explicitly give a specific FQDN, which is then checked, and transparency log for this name is listed.
Why is the name automatically prepended with "www" and also checked? This breaks the functionality for me basically.
That's not possible. And I don't want to implement it.
That's one of the most important functions.
I've started the tool 2018-10 because of the questions in this forum. One main problem: The first certificate. So all 4 urls (non www + www, http and https) with redirects are checked. If there are three correct redirects and one destination -> Grade B. Two destinations (https + non-www and www) -> Grade C.
A general problem: The webmaster doesn't see a problem, because he uses one preferred version and the browser has cached the redirect. A user uses the non-preferred version, the certificate has only one domain name (or the non-preferred version has a wrong certificate): The new user has that problem, the webmaster has no problem. Running that tool -> oh, there is a Grade N.
So the first part: Url-Checks, Comments and a small ranking system, later Connections + certificates.
Crt.sh was added 2019-03, Certspotter 2019-05, after a lot of other features.
It's not the idea to replace a CT-monitor. But checking certificates is helpful to see, if a user has already created certificates or has hitted a limit.
CertSpotter can display all nonexpired certificates for a domain. (In JSON form.)
Edit: There are also other CT monitoring websites. Censys likely has a syntax for any kind of search, though they don't seem to monitor all logs. I don't know what features Facebook has.
I understand and respect. In this case, your tool is no replacement for crt.sh - because that's what I used it for. Monitoring what certificates are being published for a certain domain, and providing true certificate transparency in the process.
But how to proceed when there is no www-counterpart of a given site?
Then try to use the new crt.sh. There is a description with an own host entry and the new ip address (didn't check it). If you have one or two domains, my tool may be enough. With 15 or more domains - it's painful, too much other things.
The checked domain / subdomain -> used to check the CT-monitors. If no www exists -> no problem.
PS: May be that
works. Check the output of google.com (there are sometimes uses who test google, facebook etc.). There are a lot of certificates with subdomains - meierf.zrh.corp.google.com, tstldap3.ldaps.corp.google.com.
