SSL Certificates: a beginner's guide

An SSL certificate (more accurately a TLS certificate, since SSL was renamed to TLS in 1999 — but everyone still calls it SSL) is a small file installed on a web server that does two things at once: it encrypts the connection between a visitor's browser and the server, and it proves to the visitor that they are actually talking to the right server (not an impostor in the middle). When a browser sees a valid certificate, it shows the famous padlock icon in the address bar. When the certificate is missing, expired, or untrusted, the browser shows a scary full-page warning that essentially scares every visitor away.

You should care because the padlock is universally recognized and almost universally misunderstood. Most people assume the padlock means "this website is safe" — it does not. The padlock proves only two things: (1) the connection between your browser and the server is encrypted, and (2) the server has a certificate signed by a trusted certificate authority for this exact domain name. It does not prove the website is honest, that the company behind it is real, or that your data won't be misused after it arrives. The padlock is necessary for safety but not sufficient. Understanding the difference is the difference between a meaningful security check and a superficial one.

The five things every SSL certificate check looks at:

• Is the certificate valid? Not expired, not revoked, signed by a trusted CA.

• Does the certificate match the domain? A certificate for `example.com` is not valid for `www.example.com` unless it explicitly includes that hostname (in the SAN field).

• What type of validation was used? Three options: Domain Validated (DV) — the cheapest, just proves DNS control; Organization Validated (OV) — proves the legal entity exists; Extended Validation (EV) — full legal verification, used by banks.

• What is the chain of trust? Every certificate is signed by an intermediate CA, which is signed by a root CA in the browser's trust store. Missing intermediates cause the chain to break in some browsers but not others.

• When does it expire? Modern certificates max out at 398 days (just over a year), and many automation systems renew every 60–90 days. An expired certificate is one of the most common preventable outages on the web.

Three questions an SSL certificate check answers:

• Is my certificate valid right now and trusted by every major browser?

• When does it expire, and do I have automated renewal in place?

• Is the chain of trust complete, or am I about to have a "works on Chrome, broken on Firefox" disaster?

The cost of a broken or expired SSL certificate is total: visitors get a full-page warning, search rankings drop, conversion rates collapse. The fix is automated renewal (Let's Encrypt's free certificates rotate every 90 days, and most modern hosting platforms handle the rotation automatically). Monitoring expiry on a recurring schedule is the cheapest insurance you can give a domain you actually care about.

In one sentence: Analyze active SSL/TLS certificate details

Analyzes the currently active SSL/TLS certificate for a domain per X.509 (X.509 certificate standard) standards. Returns certificate details including issuer, validity dates, Subject Alternative Names (SANs), key type, certificate type (DV/OV/EV), and self-signed detection. Enriches data with Certificate Transparency (CT) logs via crt.sh for historical context and subdomain discovery.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Performs a TLS (Transport Layer Security) handshake with the domain and retrieves the active certificate. Extracts issuer organization (CN, O, C), validity period (notBefore/notAfter with days remaining and expiry warning), SANs, wildcard detection, and certificate type classification (DV, OV, or EV based on issuer patterns). Queries crt.sh Certificate Transparency logs for real certificate metadata enrichment. Detects self-signed certificates by comparing subject CN to issuer CN.

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the SSL Certificates tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

Certificate monitoring is critical for preventing HTTPS (secure HyperText Transfer Protocol) outages — expired certificates cause immediate user-facing errors. SAN (Subject Alternative Name) analysis reveals related subdomains for asset inventory, issuer tracking ensures only authorized Certificate Authorities (per CAA records) are issuing certificates, and certificate type classification helps verify compliance with organizational security policies. CT log integration provides an independent verification source.

Picture this in real life. Imagine a devops engineer. Here's the situation they're walking into: Monitor active certificates approaching expiry to prevent service outages caused by expired SSL/TLS certificates. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the SSL Certificates tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the SSL Certificates tool is built for you:

• Is my website encrypted properly, or are visitors going to see a scary browser warning?

• Am I missing any of the security headers that modern browsers expect?

• Could a known weakness on my site quietly be costing me trust, traffic, or compliance?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Founders and freelancers running their own sites, agencies handing off projects to clients, security and compliance teams chasing audit findings, and developers hardening login pages. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and visitors get browser warnings, search engines lose trust in your site, and a single missed setting can become a public security incident. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the SSL Certificates tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a devops engineer, a penetration tester, and a security engineer — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Certificate Expiry Monitoring

Imagine you're a devops engineer. Monitor active certificates approaching expiry to prevent service outages caused by expired SSL/TLS certificates.

Why it matters: Prevent HTTPS (secure HyperText Transfer Protocol) outages by catching certificate expirations before they impact users.

Story 2: Subdomain Discovery

Imagine you're a penetration tester. Enumerate subdomains by analyzing Subject Alternative Names (SANs) in the active certificate.

Why it matters: Discover related domains and subdomains covered by the same certificate.

Story 3: Certificate Configuration Audit

Imagine you're a security engineer. Verify certificate key size, algorithm strength, and issuer comply with organizational security policies.

Why it matters: Ensure certificate configurations meet security standards (e.g., RSA 2048+, SHA-256+).

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the SSL Certificates tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• After every site redesign or platform migration.

• Before a penetration test, security review, or vendor questionnaire.

• When your SSL certificate is about to expire and you want to confirm the renewal worked.

• On a recurring monthly schedule, so you catch new issues before attackers do.

If you can see yourself in even one of those bullets, the SSL Certificates tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the SSL Certificates tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the SSL Certificates tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

You need to provide 2 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with SSL Certificates. If you're already running this check, the related ones often answer the next question that comes up:

• CAA Records — Check which CAs can issue certificates

• HSTS Check — Check HSTS policy and preload status

• Security Score — Composite security score from 8 weighted factors

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check SSL Certificates and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

HTTPS (secure HyperText Transfer Protocol) — HTTP with encryption — the little padlock in your browser. It means nobody between you and the website can read what you're sending.

SSL (Secure Sockets Layer) — The original encryption used by HTTPS. The name stuck even though every modern site actually uses TLS, the newer replacement.

TLS (Transport Layer Security) — The encryption that puts the 'S' in HTTPS. It scrambles data so nobody between you and a website can read it.

X.509 (X.509 certificate standard) — The international standard that describes what's inside an HTTPS certificate — who issued it, who it's for, when it expires, and so on. Almost every certificate on the web follows this format.

SAN (Subject Alternative Name) — Extra domain names listed inside an HTTPS certificate. One certificate can cover example.com, www.example.com, and api.example.com all at once if they're all listed as SANs.