Frequently asked questions

Sign up for the 30-day free trial (no credit card), add the domains you want to monitor, choose which alerts you get, 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 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 as it approaches: up to 30, 14 and 7 days before it lapses, sooner for short-lived certificates.

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 (64 days from February 10, 2027, when Let's Encrypt shortens its default) and cover apex domains and subdomains (Beacon does not issue wildcard certificates). Because short-lived 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, distrusted roots (including Chrome's cut-off dates and removals announced but not yet made), compromised keys, CA serial numbers that are not random enough, risky CAA and validation contact records, and known vulnerabilities, on websites and on mail and other servers that use STARTTLS. Starter plans and up also find every certificate public Certificate Transparency logs hold for your domains and alert you when a CA you have never used issues one. Revocation checking of your own certificate, alerts when your CA opens an incident about revoking certificates, and the monthly compliance report are on Business and Enterprise plans. Each issue ships with a clear remediation hint.

Depends on your plan. The free plan has manual scans, one every 5 minutes. The trial and paid plans add automated scanning on a schedule (hourly, or down to per-minute on paid plans). A full vulnerability scan runs every 7 days, with certificate checks in between. You can always trigger a manual scan from the dashboard.

Yes, on Enterprise plans, set up on request. Every plan monitors publicly reachable sites. For private PKI we add the certificates your own CA issues (imported from the CA or uploaded) with the same expiry and health alerts, and scan internal hosts through a scanner you run inside your network, so nothing inside has to be opened to the internet. Contact sales and we set it up for your environment.

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. The free plan watches one domain with manual scans, and emails you once, 7 days before its certificate expires. New website signups start with a 30-day free trial covering three domains with automated scans and alerts; when it ends without a paid plan, the account moves to the free plan. No credit card for either.

Anytime, from the billing page. A change between paid plans takes effect immediately and is prorated: an upgrade charges the difference, a downgrade credits it. A move to the free plan takes effect at the end of the billing period, so you keep what you paid for. Before a downgrade, bring your domains, team members and teams within the smaller plan's limits. Enterprise plans are changed through sales.

Yes. Enterprise plans include unlimited domains, SSO, custom branding, white-label reports, private PKI monitoring (your own CA's certificates and internal hosts, set up on request), and a dedicated contact. Contact sales for a tailored quote.

By email on the trial and every paid plan; Business and Enterprise add Slack and webhooks. Alerts come at three levels as a certificate nears expiry (up to 30, 14 and 7 days before), and you choose which levels email your team. The free plan sends one email, 7 days before expiry.

Yes - our REST API is available on every plan, including Free, with the same limit of 1,000 requests an hour per key. Manage monitors, trigger scans and fetch results; AI agents can use the same actions over MCP. The full reference is at /docs/api.

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. Public server certificates are dropping client authentication: Chrome's root program requires server-authentication-only certificates from March 15, 2027, and many CAs have already stopped including it. 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. Combined server-and-client certificates from public CAs end on March 15, 2027, so don't build on them. 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 for long, and often not today. Chrome Root Program Policy v1.8 requires public TLS certificates issued on or after March 15, 2027 to carry server authentication only, and many public CAs have already removed client authentication from their certificates. A certificate that already has both keeps working until it expires: browsers don't reject a connection because of the extra Extended Key Usage. 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 include Server Authentication; a certificate without it can't be used for a website. Having Client Authentication as well doesn't cause a warning today, but Chrome requires server-authentication-only certificates from March 15, 2027, so ask for that profile. 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.