HTTPS fingerprints

  • SpinRite v6.1 Release #3
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


Well-known member
Sep 24, 2020
Some time back I posted questions concerning comparing a website's certificate fingerprint to the value obtained using GRC's tool. I've been using that for a few accounts, and the occasional mismatches were always from a renewed certificate. Lately quite a few of those same sites have been coming up mismatched and not from renewed certificates, I always check GRC for that. Not being sure what was going on I posed the question to ChatGPT, asking about fingerprints and man in the middle attacks. Out of the reply it mentioned using SSL checker (SSLShopper com) to check certificates.

I tried a couple of my mismatches on SSLS and everything checks out OK. I am assuming that is correct since I think it unlikely that many of my sites have suddenly fallen to man in the middle attacks. Is anyone familiar with or has used SSLShopper? I am still exploring the services there. Out of curiosity I put GRC com in the searchbox of SSLTest and after a while it came up with an overall rating of "B" due to protocol support and key exchange. What was interesting is that GRC's fingerprint from GRC's checker did not match the output on SSLTest.

With all that said, adding I still don't fully understand things, I have a couple questions concerning how to tell if I am on an actual connection to a website or if there is a man in the middle intercepting comms.

I use Firefox almost exclusively and check it and add ons for updates daily. Can I trust Firefox to notify me of MITM attacks? Sometime back someone mentioned I should stop checking fingerprints since they are being depreciated. If that's the case is there another way detect a MITH? Could SSLLabs com detect a MITM? Is it as simple as looking for the lock symbol in the address bar.... that just seems too easy to trust.

Any links, documents or thoughts would be appreciated. As a final note I tried in SSLLabs com, one of the 'problem' sites. It showed 2 servers both with A+ ratings even though checking fingerprints don't match. When checking on GRC it gets:

One or more errors were encountered when querying:
  • The SSL/TLS security certificate obtained from the remote server was invalid. The trouble was severe enough that we were unable to obtain the certificate's common name and/or fingerprint. There is a server answering on the HTTPS port 443 of the IP address associated with the domain name you supplied (shown above). But the server may be answering HTTPS as if it was HTTP and returning a web page rather than a proper SSL/TLS setup handshake. (We have encountered this behavior.)
I don't understand how CDN services (like Akamai) are able to use SSL to proxy and cache sites. I wonder if this is what you might be seeing. It feels like changing the fingerprint of a certificate (for example having more than one, one for the source, and a different one for a CDN to use) would be troublesome for HTTPS pinning configurations. (Although I don't know a lot about pinning, beyond the fact that it exists, so maybe there are ways to pin multiple certs for the same site.)
Fingerprint will change probably, as each of the CDN servers will have a cert that is signed, but the actual primes used to sign are different across each one, so as to give each one a valid, but slightly different, cert per CDN block, so that one can be eg CDN NA1 and the other CDN NA2.
CDN services (at least Cloudflare) can work without the server behind them being HTTPS, so your browser would use an HTTPS connection, but the CDN would use an HTTP connection. Even if the server behind the CDN used HTTPS, that cert would not reach the browser.

For HTTPS pinning, all that matters is what your browser connects to, as it has no way of knowing what's going on in the back.

Now the CDN block thing I can see as something happening.
SSLLabs did show more than 1 certificate for Proton*ME has always and still does match GRC. Part of the SSLLabs output follows:

Certificate #1: RSA 4096 bits (SHA256withRSA)


Server Key and Certificate #1

Fingerprint SHA256: 58874ad5f400c7028b92c435941267715ce7973e0359c7fa7b7b3d181b547999
Pin SHA256: CT56BhOTmj5ZIPgb/xD5mH8rY3BLo/MlhP7oPyJUEDo=
Alternative names* * *
Serial Number043465513a7ee3becb998f729e3ee19f027b
Valid fromMon, 20 Feb 2023 13:11:30 UTC
Valid untilSun, 21 May 2023 13:11:29 UTC (expires in 2 months and 28 days)
KeyRSA 4096 bits (e 65537)
Weak key (Debian) No
Signature algorithmSHA256withRSA
Extended ValidationNo
Certificate TransparencyYes (certificate)
OCSP Must StapleNo
Revocation information OCSP
Revocation statusGood (not revoked)
policy host:
issue: flags:0
Mozilla Apple Android Java Windows


Additional Certificates (if supplied)

Certificates provided3 (4298 bytes)
Chain issuesNone
Fingerprint SHA256: 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd
Pin SHA256: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
Valid untilMon, 15 Sep 2025 16:00:00 UTC (expires in 2 years and 6 months)
KeyRSA 2048 bits (e 65537)
IssuerISRG Root X1
Signature algorithm SHA256withRSA
SubjectISRG Root X1
Fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
Valid untilMon, 30 Sep 2024 18:14:03 UTC (expires in 1 year and 7 months)
KeyRSA 4096 bits (e 65537)
IssuerDST Root CA X3
Signature algorithm SHA256withRSA


Certification Paths

The GRC tool shows:

If I pull up the fingerprint using Firefox the fingerprint matches GRC. My GUESS (based on nothing) is that something has changed with recently renewed certificates. These mismatches between Firefox and GRC are a fairly recent since they previously matched. I still feel comfortable when GRC and Firefox match, but it now seems if there is a mismatch it 'probably' does not mean anything is wrong. It would be nice to be able to get a definitive match/ mismatch that means exactly that. I've been using the certificate/ GRC fingerprint match on a few accounts, credit card, bank, &C- but now it seems that method is questionable.
This is a certificate chain, I think. This implies the 3rd cert signed the 2nd cert which signed the 1st cert.

#1 Subject
Issuer R3

#2 Subject R3
Issuer ISRG Root X1

#3 Subject ISRG Root X1
Your assessment is correct :)
Can any of this be used to verify you are connected to the site you think you are? Until recently matching fingerprints worked, but now that method seems questionable, at least with some sites.
Well certificates have ALWAYS been a chain of trust. You go to a site, it gives you a certificate, and it probably contains the trust layers your browser might not have. The issue, is that so long as the top of the trust chain ends up at one of the hundred or more certs your browser already contains as trusted, then the whole chain is trusted. This allows governments to get a cert put in the trusted list, and the to potentially abuse it later. This is how enterprise snooping works, they force an enterprise cert into your browser's trusted list, and then they can mint trust certs for ANY site they want.
It sounds as if unless you have a trusted list of certificates for your browser and check that against what is actually in your browser things cannot be trusted. IF that is correct, is there a way to get a copy of the valid certificate list, in my case Firefox?


  • PHolder2023Feb28_FirefoxCAs.png
    85.4 KB · Views: 130
Thanks for that, I'll check the link. After my last login here I went into Firefox and looked at the certificates. There were quite a few, including 2 or so from China. They may be legit, but it did make me pause a minute or so.

One thing I've noticed lately on some sites is that they have an initial screen saying something like 'Checking your browser's security', sometime followed by a I am human checkbox. Occasionally I get those annoying blurry pictures to identify. I use a VPN so it is expected my machine is not always recognized, and some sites do not like logins from strange countries, often saying something like there is a temporary issue, try later. That I expect and I keep a fixed profile for a few sites to avoid the foreign login issue instead of the usual random country connection.

Most of the sites I check fingerprints on go to a different not much used email address. I have to try using the links provided in the emails and then see if it changes the fingerprints I see. Those links are often quite a bit longer than I use, no doubt providing the site with information- but I'll give it a try out of curiosity.
I asked ChatGPT a few questions about fingerprints. It listed some of Firefox's trusted certificate suppliers, not all of cause. Perhaps the most interesting thing it mentioned to check for a 'planted' certificate was simply to try a different browser and see if it complains. I have Chrome and Edge installed but almost never use them. I'll have to let them update and give that a try.
I tried comparing fingerprints between GRC, Firefox, Chrome, and Edge. All were different and none gave any warnings about the site. Interestingly there are still sites that match GRC's fingerprint so whatever the cause of the differences it seems to be on a few and not all the sites I check.