New Chain Checker Tool


For fun and my own convenience, I have put together yet another certificate chain checker tool:

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).

Suggestions welcome. UI code (very minimal) is here: GitHub - webprofusion/certify-chain-checker: TLS Chain Checker


it does support long chain! :smile:


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 is not sending its intermediate. Yet this tool shows:

Subject Serial Issuer Start Expiry Type
* 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 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.


Like this?


W W W S ?
[What Would Windows Serve - LOL]


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.


No classification for E1 chains? :cry:


In addition to fixing missing intermediates, it also fixes incorrect ordering of intermediates:

This test server 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 UI source code is here if you want to fix it! certify-chain-checker/index.html at main · webprofusion/certify-chain-checker · GitHub

It's a minimalistic toy currently. It only exists so I can tweak the guidance it gives and the scanning it does..


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]


Yes now it shows weird orders, and missing intermediates etc.

However it always displays "Certificate Chain OK", even if I feed it with completly junk data?


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.


A post was split to a new topic: Kubernetes and LE secured API endpoint problem

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.