Certificate Inspector Guide
A reference for the desktest.net Certificate Inspector. The tool reads an X.509 certificate you paste or drop, entirely in the browser, and tells you who it is for, who issued it, when it expires, which host names it covers, and whether it is self-signed. This guide explains what each field means and how to read the result in the cases a front-desk or IT technician actually hits.
Open the Certificate Inspector ->
What the X.509 fields mean
An X.509 certificate is a signed statement that binds a public key to an identity. The Inspector surfaces the fields that matter day to day:
| Field | What it is |
|---|---|
| Subject | Who the certificate is for. Rendered as its Distinguished Name parts, for example CN=test.desktest.net, O=Desktest, C=US. The CN (Common Name) is the primary identity; O is the organization, C the country. |
| Issuer | Who signed the certificate. For a CA-issued certificate this is the certificate authority. For a self-signed certificate it is identical to the Subject. |
| Serial | A unique number the issuer assigned, shown in uppercase hex. Useful when a vendor or CA asks you to identify a specific certificate. |
| Signature algorithm | How the certificate was signed, for example SHA-256 with RSA or ECDSA with SHA-256. Anything with SHA-1 is obsolete and modern clients reject it. |
| Public key | The key type inside the certificate: RSA, EC (elliptic curve), or Ed25519. |
| Certificate Authority | Whether the basicConstraints extension marks this as a CA certificate (one allowed to sign other certificates) rather than an end-entity (leaf) certificate. |
The Inspector parses the DER structure with a hand-written walker. It does not verify the signature or build a chain to a trusted root; it reports what the certificate says about itself. That is exactly what you want when triaging a device or a browser warning.
Self-signed vs CA-issued
The single most useful thing this tool tells you is whether a certificate is self-signed. A self-signed certificate has the same Issuer and Subject: it vouches for itself, with no certificate authority behind it.
- CA-issued. A public certificate authority (or your organization's internal CA) signed it. Browsers and the operating system already trust the well-known public CAs, so a valid CA-issued certificate produces no warning.
- Self-signed. No authority vouches for it, so clients show a "not trusted" or "your connection is not private" error until the certificate (or the CA that issued it) is installed in the trust store on that machine.
Reading validity and expiry
Every certificate carries two timestamps: Not before and Not after. The certificate is only usable in the window between them. The Inspector compares that window against the current time on your workstation and shows one of four statuses:
| Status | Meaning |
|---|---|
| Valid, N days remaining (green) | Inside the window and not due to expire soon. Normal, healthy certificate. |
| Valid, but expires in N days (amber) | Still valid, but the Not after date is within 30 days. Time to renew. |
| Expired N days ago (red) | The Not after date has passed. Clients reject it with an expiry error. Renew or reissue it. |
| Not yet valid (red) | The Not before date is in the future. Usually the workstation clock is wrong; occasionally the certificate was issued to start later. |
Because the check uses the local clock, a machine with a badly wrong date can report a good certificate as expired or not-yet-valid. If the status looks impossible, confirm the system clock and time zone first. The Clock Test on desktest.net can confirm the workstation clock against a trusted time source.
Subject Alternative Name (SAN)
Modern browsers no longer trust the Common Name for host matching. The host names a certificate is valid for live in the Subject Alternative Name extension, and the Inspector lists every dNSName it finds there. For the sample self-signed certificate, SAN contains test.desktest.net and www.test.desktest.net.
- If the site's host name is not in the SAN list, the browser shows a name-mismatch error even when the certificate is otherwise valid.
- A certificate with no SAN entries at all will fail host verification in every current browser, regardless of what its CN says.
- Wildcard entries such as
*.example.comcover one label of subdomain, soa.example.commatches buta.b.example.comdoes not.
When a user reports "the address bar says the certificate is for the wrong site," compare the site's host name against the SAN list here. That comparison is usually the whole answer.
Common front-desk cases
These are the certificate questions that show up at a property-management or branch front desk, and how the Inspector answers them.
FIS WebScan (FISCA.crt) not trusted
WebScan serves its SignalR hub over HTTPS on a loopback port, using a self-signed certificate (often distributed as FISCA.crt). Drop that file into the Inspector: you should see Issuer equal to Subject (self-signed: yes) and a CA flag. If it is expired or the machine's clock is off, that explains a scanner that suddenly stopped connecting. The fix is to (re)install FISCA.crt into the Windows Trusted Root Certification Authorities store and restart the WebScan service.
Topaz SigWeb certificate
SigWeb similarly serves a local HTTPS endpoint for the signature pad and ships its own certificate. If signature capture fails with a trust error, inspect the SigWeb certificate the same way: confirm it is present, not expired, and installed in the Trusted Root store on the workstation.
"Your connection is not private" on an internal site
Export the certificate the browser is complaining about (see the next section) and inspect it. Self-signed with an internal Issuer usually means the internal CA root is not installed on that machine. Expired means renewal lapsed. A SAN that does not list the host name means the certificate was issued for a different address.
Confirming a vendor sent you the right certificate
When a vendor emails a certificate file, drop it in and read the Subject, SAN, and Not after. That confirms it is for the host you expect and that it has not already expired before you even deploy it.
How to export a certificate to PEM
The Inspector accepts a pasted PEM block or a dropped .pem, .crt, .cer, or .der file. PEM is the base64 text form wrapped in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----; DER is the raw binary. Here is how to get one:
- From a browser. Click the padlock in the address bar, open the certificate details, and use Export or "Save to file." Chrome and Edge save DER (
.cer) by default; Firefox offers PEM directly. Either works here. - From Windows. Double-click a
.crtor.cerfile to open the Certificate dialog, go to the Details tab, and choose "Copy to File" to run the export wizard. Pick "Base-64 encoded X.509 (.CER)" for PEM. - With openssl. Convert DER to PEM with
openssl x509 -inform der -in cert.der -out cert.pem, or pull a live server's certificate withopenssl s_client -connect host:443 -servername hostand copy theBEGIN/END CERTIFICATEblock from the output. - A device file. WebScan's
FISCA.crtand similar vendor files can be dropped in directly, whether they are PEM text or binary DER; the Inspector detects which and reads it either way.
-----BEGIN PRIVATE KEY----- is a key, not a certificate, and the Inspector will report that it could not parse. You want the block that says CERTIFICATE.Related
- Certificate Inspector - the tool itself
- Scanner Test Guide - FIS WebScan connectivity and its loopback certificate
- Signature Pad Test Guide - Topaz SigWeb setup and trust
- Clock Test Guide - confirm the workstation clock before you trust an expiry result
- About desktest.net
- desktest.net home
Elsewhere on the web:
- Qualys SSL Labs Server Test - fetches and grades a public site's live certificate and chain (this local tool inspects a certificate you already have).
- crt.sh - searches public Certificate Transparency logs for every certificate ever issued for a domain.