Cert Doctor is a GUI/CLI tool for QA engineers, helpdesk and DevOps - for anyone who has read PKIX path building failed or unable to get local issuer certificate on a corporate laptop, behind a proxy, or inside a container that cannot do what the host does without trouble. Point it at the URL that fails. It walks the whole path in one run - DNS, proxy and PAC script, TCP, TLS - and then does the part no other tool does: it asks each trust store on the machine, one by one, whether it trusts what the server presented, and prints the command that would fix each store that does not, with the real paths from your machine in it. curl -v and openssl s_client answer for one program. Cert Doctor answers for the Windows store or the Linux CA bundle, every Java installation, every git, every curl, every node, every Python and the pip of each it finds - and tells you whether the fault is on this machine at all.
https://certdoctor.donislawdev.com/
Features
- Say whose problem it is - this machine, or the server. A server that does not send its intermediate certificate is named as the server's fault, with the evidence to paste into a ticket.
- One row per trust store, not per runtime - the Windows store as your account sees it and as services see it, the Linux CA bundle, every JDK and JRE separately, every git, curl, node, Python and pip it finds. On the machine it was built on, one run in November 2026 read seventeen stores, eight of them Java runtimes.
- Print the command that fixes each store - certutil, keytool with the real cacerts path of that JDK, an append to git's own bundle - and say when it needs administrator rights. It prints them. It never runs them.
- Notice TLS inspection without accusing anyone - who signed the certificate, how many stores on this machine know that authority, and the product's name when it is one Cert Doctor recognises.
- Read your proxy settings the way your programs do - the environment variables, the Windows Internet Settings that Edge, Chrome and .NET follow, and the WinHTTP settings that services follow, side by side. It runs your PAC script in a sandbox to see where your URL really goes, and asks the proxy whether it wants credentials.
- Look at DNS twice - every configured resolver asked directly, and the system resolver, with the difference classified: split horizon, a leak past a VPN, a name that resolves nowhere.
- Try every address - a TCP connection to each address the name resolves to, and the full certificate chain from each one, with fingerprints and validity dates.
- Write a report for the ticket - terminal, Markdown, one self-contained HTML page, or JSON with a schema for CI. --redact masks host names, paths and user names. Credentials are masked always.
- Change nothing and call nobody - the only file it writes is the report, at the path you name, and the window keeps one setting of its own. It connects only where you pointed it: no telemetry, no update check.
- Ship the command line as one static binary - nothing to install next to it, and it runs as it is inside Alpine and Ubuntu images.
- Show the same report in a window - certdoctor-gui, for Windows, Linux and macOS: type the address, press Diagnose, read the report and save it as HTML, Markdown or JSON. The window runs the command line next to it, so it knows nothing the command line does not.