I’ve found an .onion site with a Let’s Encrypt certificate (I was surprised). I’ve tried to look up the certificate elsewhere around the net (SSL Labs, etc.) to verify it’s authenticity, but unsurprisingly none of the sites I used were able to contact the server. Presumably they don’t have the ability to connect to an onion service.
How can I manually and independently validate this certificate’s sha256/sha1 hash? Yes, I’m sure Let’s Encrypt is the issuer. The site has a clearnet address also with certs issued by LE, but those hashes are different. Those clearnet other SSL hashes do appear on various SSL checking sites.
This is posted in feature requests because I wish there was a domain lookup at the Let’s Encrypt site itself, but I’ll happily settle for some other solution if one exists.
Normally, you could use a certificate transparency lookup tool(like crt.sh or Google’s CT checker) to see if any certificate exists for a specific domain / hostname.
You can compare it to the certificate logged in the public Certificate Transparency lists. All publicly trusted certificates are now logged here, and Let’s Encrypt has been logging them for far longer than required. As you can see here (https://crt.sh/?q=%.onion) there have been plenty of certificates issued to .onion domains, but none seem to have been issued by Let’s Encrypt. You can search the domain you’re looking at and see what certificates have been issues by public CAs.
I would really like to see the certificate itself because Let's Encrypt is not yet allowed to issue .onion certs. You can see that no such certificate is publicly logged at
Interestingly, when I looked the domain in question up on crt.sh (I wasn’t familiar with that one until the previous replies) the hash I’m hunting was actually available: https://crt.sh/?id=1000647827&opt=ocsp.
You may notice that the domain there has many certs listed (that site seems to be a great resource, thanks everyone) and some of the other hashes listed for that domain are the ones returned by sites like ssl-tools.net and ssllabs.com, digicert, globalsign, etc… None of the latter sites produce the hash listed in the link above, or mention the onion address. Crt.sh does not list the onion address either, even though, as stated, it does list the hash associated with it. The onion address is here: https://www.draugr.de/details/.
Any wisdom you’ve got is appreciated.
Also what I really wanted was a reverse lookup (enter hash/signature, find associated domain). I couldn’t find them anywhere, so I’m really grateful for this link. If anyone knows of other sites that do reverse cert lookups I’d love to hear them - it’s always best to validate from multiple unconnected sources.
Thanks again for checking this out! It definitely is interesting.
Do you think you could make a screenshot so that we could see what we’re looking at here? Can you reproduce the interaction that ends up serving you this certificate?
I can also speak a little German and we have at least one native speaker who’s a regular user of this forum, so we might be able to help if we conclude that there’s a technical question that we need to look into further.
Here’s the message in question. It is reproducible; it appears each time I try to connect to the onion service. Not included in the screenshot are the buttons “once” “cancel” and “always”. My practice is to cancel until I can verify the certificate hash, ideally unanimously.
A notification like this (but with different hashes each time) appears periodically. It’s assumed to be either expiration of old certs, or rotation preemptively for extra security/paranoia.
The previous time this notification happened, it featured a hash that was researched and subsequently accepted. It’s unknown if this might be the same hash for the previous renewal, in other words the possibility that what changed this time was not the cert, but the listing of the cert/hash from the various analysis sites (except crt.sh, obviously), thus making it impossible to verify out-of-band. I don’t know why the same hash might be used for a renewal notification, only that the hash, though I don’t have it recorded anywhere, seems familiar, so I’m including that as a possibility.
Sorry if I’m not making sense with any of this or being too verbose! I’m just trying to be clear as I can.
So we would expect to see a browser error when the certificate is used on an onion site, and there is no currently supported way either on the Tor Browser end or on the Tor end or on the Let’s Encrypt end to confirm what this should look like or whether it’s appropriate for it to be present on a particular onion site or not.
Now, having said that, I can mention the Alt-Svc header again because it might provide a partial workaround to this. However, it would have to be used by the webmaster.
Apart from that, the existing solutions are to contact the people you think are supposed to be the site operators and ask them if the hash is right, or to connect with HTTP to port 80 of the onion site rather than with HTTPS to port 443, or to ignore the error. We don’t have any current technology to answer this question otherwise.
The onion site can also get a paid .onion certificate from DigiCert if it wants to use HTTPS on an onion site today and be accepted by browsers.
