View SSL certificate details in Chrome

View ssl certificate chrome in the padlock panel, open certificate details and read Valid until—the same notAfter engineers verify with OpenSSL on port 443.

Support staff without shell access still need to answer “when does our cert expire?” Marketing sees a scary interstitial and asks whether DNS or TLS is at fault. Chrome exposes the presented chain for the current tab, which is exactly what most users experience.

The mistake is clicking through “Advanced” during an incident without copying dates, then misremembering whether the error was expiry versus name mismatch. Another is checking Chrome on an admin URL that customers never visit while www still serves an old cert.

You will open the padlock certificate viewer on current Chrome builds, read validity and SAN fields, and know when to escalate to live command-line checks.

What to check

Chrome displays the server certificate (leaf) presented during the TLS handshake for the active tab’s hostname. You should record:

• Issued to / subject and SAN list (does the name match the URL bar?)
• Issued by (public CA vs corporate vs self-signed)
• Valid from and Valid to (maps to notBefore and notAfter)
• Whether Chrome shows Certificate is valid or an error state

Chrome does not show registrar domain expiry or private CA inventory across the whole estate—only this connection.

If the page fails to load, use the Not secure or Your connection is not private interstitial: details still expose certificate dates when Chrome received them during the failed handshake. See NET::ERR_CERT_DATE_INVALID when the message explicitly mentions dates.

Enterprise policies and extensions can inject additional roots; note if Chrome is managed when dates look unexpected compared with external monitors.

Chrome updates frequently relocate security UI under Site settings or the tune icon. Pin this guide’s revision date in your internal wiki and screenshot each quarter so L1 staff are not hunting menus during outages.

Mobile Chrome on Android shares similar flows but may hide advanced fields behind Advanced → Certificate information. Collect both desktop and mobile screenshots when executives test on phones first.

Step-by-step

Loaded HTTPS page (happy or warning with details available)

1. Navigate to https://HOSTNAME/ (replace with the customer-visible site).
2. Click the tune or lock icon left of the address bar (Chrome 120+ uses a tune/connection chip on many sites).
3. Choose Connection is secure → Certificate is valid (wording varies slightly by version).
4. In the certificate viewer, select the Details tab.
5. Scroll to Validity or read the summary line showing expiration date.
6. Expand Subject Alternative Name if present and confirm hostnames.

Export for ticketing (optional)

• In the certificate viewer, open the Details tab → Copy to File or use system export if offered on your OS dialog.

When Chrome blocks the page

1. On NET::ERR_CERT errors, click Advanced.
2. Choose Proceed only on known staging hosts; otherwise stay on the warning.
3. Some builds expose Certificate details or View certificate without proceeding—use that path first.
4. Copy Expires on into the incident ticket.

Cross-check from terminal (recommended for renewals)

HOSTNAME=example.com
echo | openssl s_client -connect "${HOSTNAME}:443" -servername "${HOSTNAME}" 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

SNI must match the hostname in the address bar.

Compare Chrome’s Valid to with notAfter from OpenSSL. They should match when you are hitting the same hostname and path.

Firefox users should mirror the workflow in view certificate in Firefox.

Developers with Chrome DevTools open can switch to the Security panel for a summary, but the padlock certificate viewer remains the canonical path for support macros. DevTools can show outdated summaries if the tab stayed open across a renewal—hard refresh before recording dates.

For PDF or download links served inline, confirm you are inspecting the top-level document cert, not a subresource loaded from a CDN subdomain.

How to read the output

Valid to / Expires on is the customer-facing renewal deadline in local timezone formatting. Convert to UTC in tickets if your on-call spans regions.

Issued to common name may be obsolete; modern sites rely on SAN entries. If the URL bar shows https://shop.example.com/ but SAN lacks that host, Chrome fails name checks even with a future expiry.

Issued by shows the CA brand (Let’s Encrypt, DigiCert, etc.). After migration between CAs, issuer changes while URLs stay constant—update runbooks.

The Certificate Hierarchy or chain tree in some viewers lists intermediates. An expired intermediate can break subsets of clients while Chrome on your laptop still works if it cached a different chain—do not assume one green padlock means global health.

When Chrome says Certificate transparency or Revocation information, that affects trust posture, not notAfter directly. Fix expiry first during outages.

Extended Validation green bars are largely gone, but organization fields still appear in details. OV versus DV changes wording, not the expiry field location.

Chrome may show This certificate is valid on managed devices that trust a private root customers lack. Always pair internal screenshots with external test an SSL certificate online checks before closing customer tickets.

Common mistakes

Checking certificate details on chrome://settings or devtools Security panel of an unrelated tab—always use the tab serving the affected URL.

Using Incognito to “see what customers see” but logging into SSO first, which swaps the hostname or injects corporate certs. Test logged-out on the exact public URL.

Assuming a green padlock on https://203.0.113.10/ means the named vhost is fine—IP URLs often hit default certs with unrelated expiry.

Screenshotting only the summary card without SAN list, then discovering a partial coverage issue described in ERR_CERT_COMMON_NAME_INVALID guides.

Clearing SSL state in Chrome settings does not renew server certificates—it only drops client session tickets. Teams waste time “resetting Chrome” when notAfter on the server is the problem.

Guest profiles help reproduce customer trust stores without your extensions interfering—use a fresh guest window when validating post-renewal.

When to use automation

Browser checks help humans during support calls; production needs scheduled live TLS monitoring that does not depend on someone opening Chrome. Automate notAfter probes per hostname and alert before thirty-day cliffs.

After cert deploys, keep a short runbook line: “Confirm in Chrome padlock plus openssl s_client.” ssldays complements manual viewing with external reminders.

For bulk estate reviews, browsers do not scale—export inventory from CMDB or use test an SSL certificate online batch patterns instead of clicking hundreds of padlocks.

Record Chrome version in incident tickets. Certificate viewer layout changes ride the release train; future investigators need to know which UI generation your screenshot depicts.

When teaching non-technical stakeholders, highlight only Valid until and Issued to—defer cipher commentary until after renewal confirms future dates.

Pair Chrome inspection with NET::ERR_CERT_DATE_INVALID triage when users paste exact error codes into chat.