Skip to content
YAS.SH
TLS & Email🌐 YAS server-sideAPI availableadvanced

TLS Analyzer

Analyzes a host's TLS: certificate chain, expiry, SANs, HSTS, OCSP, protocols and ciphers.

Processed by YAS · not stored
Ready to runInstant execution
All tools →
TLS Analyzer — certificate & handshake audit

Connects with TLS, walks the certificate chain, reports expiry, SANs, protocol, cipher, OCSP stapling and HSTS status.

What does this tool do?

Analyzes a host's TLS: certificate chain, expiry, SANs, HSTS, OCSP, protocols and ciphers.

Why would I use it?

  • Your site shows a certificate error and you want the details.
  • You are auditing a domain's TLS posture.
  • You want to confirm HSTS and certificate validity before launch.

Real-life example

Input
example.com
Output
Certificate valid until 2027-01-01 · SANs: example.com, www.example.com · HSTS: enabled · TLS 1.3 supported

A comprehensive posture report for one host.

Input → Process → Output → Next

Input
Enter a hostname.
Process
YAS opens a TLS connection, validates the chain and inspects headers.
Output
A structured report: cert, chain, protocols, HSTS, OCSP.
Next action
Renew expiring certs and fix any chain or SAN issues.

Common mistakes

  • Entering a full URL instead of a hostname.
  • Testing IPs that require SNI (use the hostname).
  • Ignoring intermediate chain problems the analyzer flags.

What the result means

Each check confirms or flags part of the TLS setup.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint
POST https://yas.sh/api/v1/tools/tls-analyzer
Request Header
Content-Type: application/json
cURL
curl -X POST "https://yas.sh/api/v1/tools/tls-analyzer" \
  -H "Content-Type: application/json" \
  -d '{"input":"yas.sh"}'
JavaScript
const res = await fetch("https://yas.sh/api/v1/tools/tls-analyzer", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "input": "yas.sh"
}),
});
const data = await res.json();
Python
import requests

r = requests.post("https://yas.sh/api/v1/tools/tls-analyzer", json={"input":"yas.sh"})
data = r.json()
FieldTypeRequiredDescription
inputstringYesHostname, e.g. yas.sh (host:port form allowed)
portintegerNo (default 443)TLS port (1–65535). Also accepted as host:8443.
Success response
{ "result": { "authorized": true, "expiresInDays": 89, "sans": [...], "hsts": { "present": true, "maxAge": 63072000, "includeSubDomains": true, "preload": true }, ... } }

Full TLS audit of a host: cert chain, expiry, SANs, protocol, cipher, OCSP stapling + HSTS header.

Error responses
  • 400 VALIDATION_ERROR — invalid input or unsupported option.
  • 413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
  • 429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).
Limits
  • Maximum input: 64 KB per request.
  • Rate limit: 60 requests/min per IP address.
  • Authenticated accounts benefit from higher tier quotas.

TLS Analyzer: technical reference, use cases and FAQ

How TLS Analyzer works

The analyzer negotiates a TLS connection and reports what the server supports and selects: protocol versions, cipher suites, key exchange groups, certificate chain completeness and ordering, and extensions such as OCSP stapling and ALPN. Modern posture means TLS 1.2 and 1.3 enabled, everything earlier disabled, and forward-secret key exchange (ECDHE) as the only option — so that a future compromise of the private key cannot decrypt recorded past traffic.

TLS 1.3 removed most of the ways to configure this badly: static RSA key exchange, renegotiation, compression and the weak cipher suites behind BEAST, CRIME and Logjam are simply gone from the protocol. The remaining common misconfigurations are structural rather than cryptographic — an incomplete chain, a certificate that does not cover the requested name, or a chain served in the wrong order.

When to use it: real-world scenarios

Verifying a new endpoint before it goes live

Confirm protocol versions, chain completeness and hostname coverage while there is still time to fix them without an incident.

Diagnosing clients that fail while browsers succeed

Browsers ship intermediate certificates from previous visits; strict clients do not. A missing intermediate fails everywhere except the browser you tested with.

Producing evidence for a compliance review

PCI DSS and similar regimes require documented disablement of TLS 1.0/1.1 and weak suites. The report is the artefact.

Checking after an infrastructure change

A load balancer or CDN change can silently reintroduce old protocol versions across an entire fleet.

Pro tips

  • Serve the full chain: leaf first, then intermediates in order, excluding the root. Wrong order breaks strict clients even when every certificate is present.
  • Enable OCSP stapling. It removes a client-side round trip to the CA and avoids the privacy leak of clients announcing which sites they visit.
  • Do not enable HSTS preload until every subdomain is HTTPS-capable. Removal from the preload list takes months.
  • Test each hostname separately. SNI means one IP can serve many certificates with entirely different configurations.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

  • Configuration assessment only — it cannot detect a compromised private key or a mis-issued certificate.
  • Client compatibility is inferred from the negotiated parameters rather than tested against a matrix of real clients.
  • Servers behind WAFs or DDoS protection report the edge's configuration, not the origin's.
  • Revocation status is not queried; a valid-looking certificate may already be revoked.

Frequently asked questions

Should I disable TLS 1.2 now that 1.3 exists?
No. Keep both: 1.3 for clients that support it and 1.2 for those that do not. Disable 1.0 and 1.1, which are deprecated by RFC 8996 and rejected by current browsers.
Why do browsers work but curl fails?
Almost always an incomplete chain. Browsers cache intermediates from earlier visits and can fill the gap; command-line and server-side clients cannot.
What is forward secrecy and do I need it?
Ephemeral key exchange (ECDHE) means each session uses a fresh key, so compromising the server's private key later does not decrypt recorded traffic. It is mandatory in TLS 1.3 and should be the only option you offer in 1.2.
Is a higher key size always better?
No. RSA 4096 costs measurable performance for marginal benefit; ECDSA P-256 gives comparable security with far less computation. Configuration quality matters more than key size.
Ask YAS AI
🍪 Cookies & privacy. Essential cookies keep you signed in and remember language and theme. Google AdSense and reCAPTCHA are Google technologies: AdSense runs only after Accept All; reCAPTCHA loads on sign-in and contact forms. See how Google uses data: https://policies.google.com/technologies/partner-sites cookie policy · privacy policy.
Settings