TLS Version: a beginner's guide
Check supported TLS protocol versions
TLS versions: why 'encrypted' isn't always 'secure'
TLS stands for Transport Layer Security, and it is the protocol that actually does the encryption when you load a website over HTTPS. There have been five major versions over the years: SSL 2.0 (1995, broken), SSL 3.0 (1996, broken), TLS 1.0 (1999, deprecated), TLS 1.1 (2006, deprecated), TLS 1.2 (2008, current), and TLS 1.3 (2018, current). The version number matters because "encrypted" is not the same as "secure" — older versions of TLS use cryptography that has known vulnerabilities, and a server that still accepts those older versions is exposing every visitor to attacks the newer versions would have prevented.
You should care because most compliance frameworks now explicitly require TLS 1.2 or higher, and many modern browsers now refuse to connect over TLS 1.0 or 1.1 at all. PCI-DSS (the credit-card industry's security standard) requires TLS 1.2 or higher. The HIPAA Security Rule effectively requires it. Banking integrations require it. Even Google's Chrome has shown a warning since 2020 for any page loaded over an insecure TLS version. If your server is still negotiating TLS 1.0 because it's there "for compatibility," you are inviting compliance findings, security incidents, and broken compatibility with the very devices you thought you were supporting.
The five things every TLS-version check looks at:
Which versions does the server accept? A modern server should accept TLS 1.2 and TLS 1.3 only.
Which versions does it actively prefer? When given a choice, the server should pick the newest available version.
Are SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 explicitly disabled? Leaving them enabled "for compatibility" is the most common configuration mistake.
What is the TLS 1.3 negotiation latency? TLS 1.3 reduces handshake round trips compared to TLS 1.2, which is a measurable speed win.
Are there known weak handshake parameters? Things like static Diffie-Hellman parameters, weak named curves, or downgradable cipher suites.
Three questions a TLS version check answers:
Is my server still accepting deprecated TLS versions that compliance frameworks now forbid?
After the recent OS or web-server upgrade, is TLS 1.3 actually enabled?
Would my server pass a PCI-DSS, HIPAA, or SOC 2 review on this single dimension?
The cost of running deprecated TLS versions is failing every modern compliance audit and inviting a small but real security risk. The fix is one configuration change at the web server. The full TLS protocol history is documented at Mozilla's TLS configuration recommendations.
The TLS Version endpoint, in plain language
In one sentence: Check supported TLS (Transport Layer Security) protocol versions
Verifies TLS (Transport Layer Security) connectivity for a domain and confirms support for modern TLS versions (1.2+). Note: Cloudflare Workers negotiate TLS 1.2 or 1.3 automatically; individual version testing requires dedicated tools like testssl.sh or SSL (Secure Sockets Layer) Labs.
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.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Performs a TLS (Transport Layer Security) handshake with the domain to verify connectivity. A successful connection confirms the server supports at minimum TLS 1.2. TLS 1.3 support may also be present but cannot be independently confirmed from this environment. For precise per-version enumeration, use testssl.sh, nmap, or Qualys SSL (Secure Sockets Layer) Labs.
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.
Why this specific tool matters
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 TLS Version 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.
TLS (Transport Layer Security) version support directly impacts security posture. PCI DSS 4.0.1 (current version) and NIST SP 800-52r2 require TLS 1.2 as a minimum, and HIPAA follows similar guidance. This endpoint helps verify compliance and identify servers needing protocol updates.
Picture this in real life. Imagine a compliance officer. Here's the situation they're walking into: Verify all public-facing servers have disabled TLS (Transport Layer Security) 1.0 and 1.1 as required by PCI DSS 4.0. 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 TLS Version 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 TLS Version 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.
Available on the free plan. The technical details: `GET /v1/domain/tls-version`.
When would I actually use this?
If you're still on the fence about whether the TLS Version tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a compliance officer, a penetration tester, and a devops 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: Security Compliance Audit
Imagine you're a compliance officer. Verify all public-facing servers have disabled TLS (Transport Layer Security) 1.0 and 1.1 as required by PCI DSS 4.0.
Why it matters: Maintain compliance by identifying servers with deprecated TLS (Transport Layer Security) versions.
Story 2: Security Assessment
Imagine you're a penetration tester. Identify weak TLS (Transport Layer Security) configurations during security assessments.
Why it matters: Document TLS (Transport Layer Security) misconfigurations for remediation recommendations.
Story 3: Infrastructure Hardening
Imagine you're a devops engineer. Verify TLS (Transport Layer Security) configuration after hardening load balancers or web servers.
Why it matters: Confirm TLS (Transport Layer Security) hardening was applied correctly across infrastructure.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the TLS Version 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 TLS Version 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 TLS Version 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.
The easiest way: just ask your AI assistant
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 TLS Version 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.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
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.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/domain/tls-version?domain=example.com"What you need to provide
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.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
domain | string | Yes | The domain to check TLS (Transport Layer Security) version support for | example.com |
port | number | Optional | Port to connect to (default: 443) | 443 |
What you get back
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.
| Field | Type | What you'll see in it |
|---|---|---|
domain | string | The queried domain |
port | number | The port used for connection |
supportedVersions | array | TLS (Transport Layer Security) versions confirmed as supported (at minimum TLS 1.2) |
preferredVersion | string | null | Negotiated TLS (Transport Layer Security) version (from Cloudflare metadata, or null if unavailable) |
negotiatedCipher | string | null | Negotiated cipher suite (from Cloudflare metadata, or null if unavailable) |
deprecatedVersions | array | Deprecated TLS (Transport Layer Security) versions detected (empty — per-version testing not available) |
recommendations | array | Security improvement suggestions |
Words you might be wondering about
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.
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.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.