Online SSL/TLS checker
A padlock in the browser means the connection is encrypted. It does not mean the encryption is sound. Point the scanner at a host you control and get the protocol versions, the cipher suites, the certificate chain and the expiry date - graded, kept, and watched for the day any of it changes.
Watched, not just checked
This is one scan of one layer, run once. In AYAsec the same check runs on a schedule across every asset you own, and you are told the day a grade drops.
Six reasons to check your own TLS
TLS is the one part of your estate that fails on a calendar, not on a change. Nothing has to go wrong for a certificate to expire.
01
Catch a certificate before it expires, not after
An expired certificate is one of the few security failures your customers notice before you do - the browser shows them a full-page warning. It is also entirely preventable, because the expiry date is known months in advance. What is missing is usually not the knowledge but the reminder.
02
Find the protocol versions nobody turned off
TLS 1.0 and 1.1 were deprecated years ago, and most estates believe they disabled them. Belief is not the same as configuration. Old versions survive on the host somebody set up before the policy existed, on the load balancer that was replaced but not reconfigured, and on the appliance nobody logs into.
03
Prove the chain is complete
An incomplete certificate chain is the failure that is hardest to notice, because it does not fail for you. Browsers cache intermediate certificates, so the person who set it up sees a working site. Some clients - older devices, command line tools, other servers calling your API - do not, and for them the connection simply breaks.
04
Check what a redirect actually lands on
A site that redirects HTTP to HTTPS is doing the right thing. A site that redirects to an HTTPS endpoint with a different certificate, or to a hostname the certificate does not cover, is doing most of the right thing and failing at the end. Testing the endpoint rather than the intention is the only way to see it.
05
Cover the hosts that are not your website
Mail servers, APIs, VPN endpoints and admin panels all use TLS, and none of them show a padlock to anybody. They are the hosts where an expired certificate or a weak cipher can sit for a year, because no customer is ever going to report it.
06
Produce evidence for a security questionnaire
"We use TLS 1.3" is an assertion. A dated report showing which protocol versions each host accepts is evidence, and it is the format an auditor or a customer's security review actually wants. Building that record is a subject of its own.
Know the day your encryption changes
TLS configuration does not decay slowly - it changes in one step, on a deploy. A cipher is re-enabled to fix a compatibility complaint from one client. A certificate is renewed on one host in the pool and not the others. A new subdomain goes live with whatever the default is.
Scheduled scans turn that into a difference you are told about: this host now offers a protocol it did not offer last week, this certificate expires in thirty days, this grade dropped. Certificate-expiry alerts and grade-regression alerts arrive in-app, by e-mail, or through Slack, Teams, Jira or a webhook.
Step 01
Name the target
A hostname or a domain you control, added to your AYAsec account. Ownership is checked before anything is dispatched - AYAsec will not schedule scans against infrastructure you have not demonstrated control of, and proving it takes one DNS record. The quick check above skips this: no account, no verification, just IP rate-limiting and a rule that the target has to be a public address.
Step 02
Let the test run
The TLS scan is powered by testssl.sh, the open source test suite that is the reference for this kind of check. It negotiates with the host the way a real client would, rather than reading a configuration file and trusting it.
Step 03
Read the result
Findings arrive ordered by severity and scored A+ to F, so an expiring certificate and a cosmetic cipher preference are not sitting in the same undifferentiated list.
What the scan checks
01
Protocols and ciphers
Which TLS versions the host will negotiate, and which cipher suites it offers within them. Both matter: a host can support TLS 1.3 and still accept a 1.0 connection from a client that asks for one.
02
The certificate itself
Validity dates, whether the chain is complete and correctly ordered, whether the hostname matches, and the key exchange behind it.
03
Known TLS vulnerabilities
The named weaknesses that come from particular combinations of protocol and cipher rather than from a software version, which is why they survive patching. These run as part of the full test set once you sign in - the quick check above skips them to keep the free scan fast, and sticks to protocol versions, certificate validity and cipher strength.
Questions before you scan
What may I scan?
Infrastructure you own or are contracted to test. The quick check above doesn't verify that for you - it only rate-limits by IP and refuses to target anything but a public address. Add the target to an AYAsec account instead, and control is verified before anything scheduled runs: a legal boundary as much as a practical one, since an unverified scan is of no use to you as evidence either.
Will the scan disrupt anything?
No. A TLS test opens connections and negotiates, which is what every visitor's browser does. It does not send traffic to the application behind it.
My site scores badly but works fine. Does it matter?
Sometimes not, and the report says which findings are which. A weak cipher that no modern client will ever choose is a lower priority than a certificate expiring in a fortnight. That is what the severity ordering is for.
Why does the grade differ from other TLS testing sites?
Different tools weight findings differently, and some check things others do not. What matters more than the letter is whether it moves - a grade that drops between two scans of the same host is telling you something changed.
Can this replace certificate management?
No. It tells you what a certificate is doing today and warns you before it expires. Issuing, renewing and deploying them is a different job.
Do you keep the results?
Not the quick check above - it lives in memory for about fifteen minutes so you can read it once, then it's gone. That's a deliberate privacy choice, not a limitation: nobody but you ever sees that scan, and you can download the full result before it expires. Add the target to an AYAsec account instead, and every scan is kept - a series that tells you when the configuration changed and what it changed from. Retention depends on your plan.
Keep the history, not just the result
Run the full test against your own estate, on a schedule, with certificate-expiry warnings before they become customer-facing.
More free security scanners for HTTP, ports and DNS
TLS is one of five scored layers. The others each answer a different question:
Online port scanner
what is this estate willing to talk to a stranger about?
HTTP security checker
is the web application configured defensively?
DNS security checker
can anyone send mail that looks like it came from you?
All five together are what attack surface management means in practice.