Frequently asked questions

Sign up for a free account, add the domains you want to monitor, configure alert preferences, and you're done. Most users complete setup in under five minutes - no agents to install.

No. TLS Radar monitors your certificates externally over the public internet, the same way your visitors and customers see them. Nothing to install, no agents to maintain.

Most users are up and running in under 5 minutes. For larger portfolios, our bulk import lets you add hundreds of domains at once.

When a certificate expires, visitors see a browser warning like "Your connection is not private" and most will leave. The fix is to issue and install a replacement certificate, then reload your web server so it serves the new one. If you use Let's Encrypt or another ACME provider, renewal is usually a single command - and if an automated renewal failed silently, run it manually and check the logs to see why. Need a certificate right now? Beacon issues a free 90-day Let's Encrypt certificate in minutes with a guided DNS step, no account or command-line tools required. To stop it happening again, put the domain into monitoring so you're alerted well before the next expiry instead of after.

The fastest way is to run a free SSL scan - enter your domain and the report shows the exact expiry date, how many days remain, and whether anything else is wrong. From a terminal you can also read the expiry with openssl. Checking by hand doesn't scale past a domain or two, so for anything larger, ongoing monitoring tracks every certificate's expiry for you and alerts at 30, 14, 7, 3, and 1 day before it lapses.

You can get a free, publicly trusted certificate from Let's Encrypt. The simplest way without installing an ACME client is Beacon: enter a domain you control, add the DNS TXT record it shows you, and download your certificate as a PEM chain or PKCS#12 bundle. Certificates are valid for 90 days and cover apex domains and subdomains (Beacon does not issue wildcard certificates). Because 90-day certificates renew often, pair issuance with monitoring so a missed renewal never takes your site down.

They are the same idea at different ages. SSL (Secure Sockets Layer) is the original protocol; TLS (Transport Layer Security) is its modern successor. Every version of SSL is now deprecated and insecure, and today's "SSL certificates" actually secure connections using TLS (currently TLS 1.2 and 1.3). The industry still says "SSL certificate" out of habit, but the certificate and the encryption are TLS.

Yes, but gradually. The CA/Browser Forum has approved a phased reduction in the maximum lifetime of public TLS certificates: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. Shorter lifetimes mean far more frequent renewals, which is why teams are moving from manual tracking to automated monitoring and renewal now, before the cadence becomes unmanageable.

Expiration windows, weak ciphers, deprecated protocols (SSL 2.0/3.0, TLS 1.0/1.1), broken chains, hostname mismatches, revocation status, and known vulnerabilities. Each issue ships with a clear remediation hint.

Depends on your plan. Free accounts get manual scans on demand. Paid plans add automated scanning from hourly down to per-minute. You can always trigger an instant manual scan from the dashboard.

TLS Radar focuses on publicly reachable endpoints. For private PKI and internal-only certificates, our Enterprise plan includes a self-hosted scan agent that reports back to your dashboard.

Every scan report has a grade (A+ to F), the certificate details (who it is for, who issued it, when it expires), trust and validation signals, per-platform trust stores, the protocol versions and cipher suites your server accepts, and a prioritised list of issues. Our scan report fields guide explains each one in plain English - what a good value looks like and what your visitors see when something is wrong.

Yes - free forever, no credit card required. The free tier is generous enough to monitor a small portfolio and try every core feature.

Anytime. Upgrades take effect immediately with prorated billing. Downgrades apply at the next billing cycle so you keep what you paid for.

Yes. Enterprise plans include unlimited domains, SSO, custom branding, white-label reports, private PKI support, and a dedicated contact. Contact sales for a tailored quote.

Email is included on every plan. Paid plans add Slack and webhook delivery. You configure exactly which thresholds (30, 14, 7, 3, 1 day before expiration) trigger which channels.

Yes - our REST API is available on every plan, including Free. Manage scans, fetch results, and stream events directly into your own systems. Paid plans get higher rate limits and more monitors.

Absolutely. We actively collect requests and prioritize them publicly. Enterprise customers get priority consideration for custom development.

A dedicated client authentication certificate, not a regular TLS server certificate. Two specifications matter most. First, the certificate's Extended Key Usage must be TLS Web Client Authentication only (OID 1.3.6.1.5.5.7.3.2), with no Server Authentication EKU - modern browser root programs reject certificates that mix both. Second, it should chain to a root in your partner's required trust program; for most public API partners, this means a root in the Mozilla Root CA Program, since their portals typically validate against Mozilla's trust list. Ask your CA for their "Client Authentication" or "mTLS Client" certificate product specifically. If they only offer combined server-and-client certificates, that product no longer works for this use case. For internal service-to-service mTLS (your own services talking to each other), a private CA is the appropriate tool - service mesh CAs, secrets-management tools with PKI features, managed private CA services, or your own internal PKI.

Not from a public certificate authority. Modern browser root programs require public TLS certificates to be dedicated to server authentication only; certificates issued after the relevant policy's effective date that include both Extended Key Usages are rejected by the leading browsers and the Chromium-based browsers, and the major browser trust programs are moving in the same direction. No public CA can issue dual-EKU certificates and remain in the major root stores. If a legacy partner integration documented a dual-EKU requirement years ago, three options work today. First, deploy two separate certificates side by side - one server-authentication-only, one client-authentication-only - and route each integration to the certificate it expects. Second, use a private CA certificate, which works if the partner is willing to add your private CA to their trust store. Third, push the partner to update their integration to accept separate server and client certificates, which aligns with current PKI standards.

Check four things in order. First, confirm the new certificate is actually being served by every endpoint. Verify from outside your network rather than checking the file on disk - old certificates can be cached on a CDN edge, load balancer, or proxy in front of your origin while the file on the origin is updated. Second, confirm the certificate's Extended Key Usages. If your CA reissued from the same profile, both Server and Client Authentication may still be present, which is the combination major browser root programs now reject. Request issuance from a server-authentication-only profile explicitly. Third, confirm the chain. Some CAs maintain dual hierarchies during a root migration and can mistakenly reissue from the legacy hierarchy. Ask the CA to confirm the issuing root is the current (post-2020) hierarchy, not a legacy 2014-2016 era root. Fourth, confirm full deployment. After verifying from outside the network, you may find that some endpoints serve the new certificate while others still serve the old.