This is a very basic and hopefully fast tool to summarize a particular servers current chain. I'd be interested in knowing if anyone can get it to return the wrong chain (it's hosted on Azure in a Windows based container, so there's a good chance).
When we debug chains from servers, it's often interesting to see what the server has send to us, because many clients rely on this information. So this is why I'm asking, is this supposed to show the actual chain send by server, or is it supposed to auto-fill missing intermediates (Which can also be interesting for some use cases)?
For example, the host incomplete-chain.badssl.com is not sending its intermediate. Yet this tool shows:
Subject
Serial
Issuer
Start
Expiry
Type
*.badssl.com
0AF06CDA37A60B641342F0A1EB1D59FD
DigiCert SHA2 Secure Server CA
Mon Mar 23 2020
Tue May 17 2022
End-Entity
DigiCert SHA2 Secure Server CA
02742EAA17CA8E21C717BB1FFCFD0CA0
DigiCert Global Root CA
Wed Sep 23 2020
Mon Sep 23 2030
Intermediate
DigiCert Global Root CA
083BE056904246B1A1756AC95991C74A
DigiCert Global Root CA
Fri Nov 10 2006
Mon Nov 10 2031
Root
As if the server had actually send the intermediate.
I then tried to replicate this with more than one intermediate and pulled together a test page here:
This host missing-chain.germancoding.com sends nothing apart from the leaf, yet the tool shows all intermediates. It definetly loads them from somewhere (AIA? Certificate cache?).
Good question! The tool is using the underlying mechanisms of .net 6 and as such would appear to be resolving some intermediates on its own. Really the point of this is for me to give some users so they can see they are serving the wrong chain (and it appears to be working for that). So it can highlight things like using the wrong R3 (I've just updated it to do that).
I only built this a couple of hours ago but yes it would be great to expand it, however there are probably better tools for general chain checks (qualsys etc are what I normally use, they are just a bit intimidating/confusing for some users).
I agree though if the server is not presenting an intermediate it's confusing if this does resolve it, because the point is really to verify what the server is sending.
Ha, yeah, their one is clearly better! Kind of like that but if you feed mine chains with known Let's Encrypt red flags it should let you know. Mine will let you know if your chain is the legacy or modern one or if you have the expiring R3 present.
In addition to fixing missing intermediates, it also fixes incorrect ordering of intermediates:
This test server wrong-chain-order.germancoding.com is configured to send the intermediates in swapped order, which gets autocorrected (by the way, OpenSSL does this too so it's not uncommon).
I guess .NET is designed like most modern libraries and fixes all kinds of server configuration issues on the fly.
The backend implementation for this tool has now been replaced with a Go implementation hosted on linux. The previous (.net) version resolved intermediates like a client which gave potentially misleading results, now it presents and examines just the intermediates your server has sent.
It's particularly useful to quickly see which LE chain you are serving (short, long or expired) [it will flag up use of the expired R3 chain, for instance]
Yeah, there's still plenty of room for improvement.
If it continues to see much use beyond this expiry situation it could warrant more work.
The main trick is that in order to get to the invalid certs being served (in a Go client) is to skip client validation, so that means client chain validation doesn't happen and you don't actually resolve it to a root.
There's possibly scope for having both versions of the API and comparing both sets of results.
