You pick up the phone, hear the dial tone, and assume your call is private. But someone could have tapped the line — listening to every word without you ever knowing. Your connection to our website works exactly the same way. Most people see that padlock in their browser and assume they are safe. The padlock alone says nothing about who is really on the other end. This page tries to find out.
We are going to do something concrete. Right now, our server will connect to itself over an encrypted channel — exactly as your browser does — and read back the certificate it receives. We will extract the certificate’s unique serial number and SHA-256 fingerprint, then ask an independent public database to confirm that this exact certificate was legitimately issued and publicly logged. You can see every step of that check in real time below.
🟢 Live Certificate Check — Results fetched fresh on every page load
You must be logged in to view this information.
The check above tells us whether the server is sending out a legitimate certificate.
But did your browser actually receive that same certificate — or did someone intercept the connection and swap in their own? If the fingerprints match, you are talking directly to this server. If they differ, someone is in the middle, reading everything.
We cannot check this automatically. Browsers deliberately prevent web pages from reading the certificate they received. The reason is privacy: many corporate and government networks route traffic through an interception proxy, which presents its own certificate instead of the website’s. That proxy certificate is unique to the organisation. If JavaScript could read it, any website could use it as a hidden tracking identifier — one that persists across private browsing, cookie deletion, and IP changes — to silently identify which company or agency you work for. To close that loophole, browsers keep certificate data out of reach of page code entirely. So this last step has to be done by hand, using your browser’s built-in certificate viewer. Here are step-by-step instructions for the four major browsers.
🦊 Firefox
- Click the padlock icon at the left end of the address bar.
- In the panel that appears, click Connection secure.
- Click More information. The Page Info window opens.
- Make sure the Security tab is selected, then click View Certificate.
- A new tab opens showing the full certificate. Scroll down to the Fingerprints section.
- Copy the value next to SHA-256 Fingerprint and compare it to the fingerprint in the table above.
🌐 Google Chrome
- Click the padlock icon (or the tune / info icon) at the left end of the address bar.
- Click Connection is secure.
- Click Certificate is valid. The certificate viewer opens.
- Select the Details tab.
- Scroll to the very bottom of the field list to find Certificate Fingerprints. Click it to expand it if needed.
- Compare the SHA-256 fingerprint to the one in the table above.
🔷 Microsoft Edge
Edge is built on the same Chromium engine as Chrome, so the steps are almost identical.
- Click the padlock icon at the left end of the address bar.
- Click Connection is secure.
- Click Certificate is valid. The certificate viewer opens.
- Select the Details tab.
- Scroll to the bottom of the field list and click Certificate Fingerprints to expand it.
- Compare the SHA-256 value to the fingerprint in the table above.
🧭 Safari (macOS)
- Click the padlock icon at the left end of the Smart Search field (address bar).
- A small panel appears. Click Show Certificate.
- A certificate sheet drops down. Click the ▶ Details disclosure triangle to expand the full certificate fields.
- Scroll down to the Fingerprints section. You will see both an SHA-1 and an SHA-256 fingerprint listed.
- Compare the SHA-256 value to the fingerprint in the table above.
Safari on iPhone or iPad: Mobile Safari does not expose certificate fingerprints through its standard interface. To inspect certificates on iOS, use a third-party tool such as SSL Trust, or switch to Firefox for iOS, which provides limited certificate details via the padlock menu.
Interpreting What You Find
- ✅ Fingerprints match — Your browser received the genuine server certificate. The connection has not been intercepted.
- 🚨 Fingerprints differ — Your browser received a different certificate than the one this server uses. This is a strong indicator of a man-in-the-middle interception and warrants immediate concern. Do not enter any credentials or sensitive information, and report the discrepancy.
Why Does This Matter?
Every time you visit a website over HTTPS, your browser and the server agree on an encrypted channel using the site’s SSL certificate. That certificate is issued by a trusted Certificate Authority and proves you are talking to the real server — not an impostor.
In a man-in-the-middle attack, someone intercepts your connection and presents their own forged certificate instead. Your browser may still show a padlock, but you would be communicating with the attacker, not this site. This page gives you the tools to independently check whether that is happening.
Limitation: A sophisticated man-in-the-middle attacker could in theory intercept this page and rewrite it on the fly — replacing the certificate details from the origin server in the table above with details matching their own certificate, making everything appear to check out. In practice this is extremely unlikely: it requires specialized interception software capable of real-time parsing and rewriting of this specific paget, and this site is not a high-value enough target to justify that effort. But there are no absolute guarantees. Treat this as a reasonable check, not a forensic one.
Certificate data fetched live via SSL self-connect · CT log data courtesy of crt.sh (Sectigo) · Learn more about Certificate Transparency