SSL/TLS Certificate Security & Expiry Scanner
Certificate details, chain validation, TLS version testing, and CT log history.
The SSL/TLS Checker connects to any HTTPS endpoint and returns the full certificate chain, subject and issuer details, SAN entries, TLS protocol version support, and expiry status. It also queries Certificate Transparency logs for historical issuance on the domain.
SSL/TLS Certificate Auditor
How to Use
Work through these steps in order. Use this tool for educational and ethical purposes only.
| 1 | Select SSL/TLS Checker from the tool navigation. |
| 2 | Enter the target hostname (without https://) and port number (default: 443). |
| 3 | Click Analyze SSL/TLS. The tool opens a socket connection to retrieve the live certificate chain. |
| 4 | Review the Certificate Details panel: Subject CN, issuer CA, serial number, and signature algorithm. |
| 5 | Check the Validity panel for Not Before and Not After dates, plus the Days Until Expiry counter. |
| 6 | Review the Subject Alternative Names (SANs) list covering all domains the certificate protects. |
| 7 | Check the Chain of Trust panel showing intermediate CA and root CA certificates. |
8 | Review TLS Protocol Support to see which versions (TLS 1.0, 1.1, 1.2, 1.3) the server negotiates. Check the Certificate Transparency panel from crt.sh for all certificates historically issued to the domain. |
How TLS Works
TLS (Transport Layer Security) encrypts traffic between a browser and a web server. When you see https:// in a URL, TLS is active.
The TLS Handshake
Before any data is exchanged, the browser and server run a handshake that establishes three things: which TLS version to use (both sides agree on the highest mutually supported version), which cipher suite to use for key exchange and encryption, and whether the server’s certificate is valid and trusted. The handshake takes milliseconds, but its outcome determines whether the connection uses modern algorithms or falls back to weaker ones.
What a Certificate Contains
An SSL/TLS certificate is a digitally signed document proving the server owns the domain it claims and that a trusted authority verified that ownership.
Field | What It Means |
|---|---|
Issued To (CN) | The domain the certificate covers |
Issuer (CA) | The Certificate Authority that signed the cert |
Signature Algorithm | The signing algorithm (RSA-SHA256 is current standard) |
Key Size | The public key size; RSA 4096 bits is strong |
Serial Number | A unique identifier used for revocation tracking |
Valid From / Expires | The active date range; outside this window, browsers reject the cert |
The Chain of Trust
Every domain certificate (end-entity certificate) is signed by an intermediate CA, which is itself signed by a root CA trusted by operating systems and browsers. For recosint.com, the chain runs from the site certificate through Let’s Encrypt’s intermediate R12 up to the Internet Security Research Group (ISRG) root.
Browsers verify every link in that chain. A single missing, expired, or untrusted certificate anywhere in it triggers a browser warning, regardless of whether the end certificate itself is valid.
Common TLS Failures
Most TLS vulnerabilities come from configuration drift, missed renewals, and defaults that are years out of date, not sophisticated attacks.
Expired Certificates
An expired certificate triggers a full-page browser warning and most users leave immediately. The audit tool shows the expiry date and days remaining in the summary. With 49 days left on a Let’s Encrypt certificate (90-day validity), renewal is due within weeks. Automated renewal via Certbot eliminates the risk of manual tracking failures.
Common causes of expiry incidents: manual renewal with no alerting, certificates pinned to replaced servers, and wildcard certs managed outside the main renewal workflow.
Legacy Protocol Support
The protocol panel for recosint.com shows TLS 1.0 and TLS 1.1 as active alongside TLS 1.2 and TLS 1.3. Both are deprecated by the IETF (RFC 8996) and disabled in all major browsers. Servers still accepting them expose users to POODLE and BEAST attacks, and violate PCI DSS requirements for cardholder data environments.
Weak Cipher Suites
Protocol version alone doesn’t determine encryption quality. A server running TLS 1.2 with RC4 or 3DES cipher suites offers little practical improvement over TLS 1.0. Cipher suite auditing requires protocol-level negotiation testing beyond what certificate validity checks cover.
Weak Key Sizes
RSA keys below 2048 bits are considered insecure. The recosint.com certificate uses RSA 4096 bits, well above the minimum. Sites still using 1024-bit keys expose private key material to factorization attacks within realistic computational reach.
Self-Signed Certificates in Production
A self-signed certificate means no CA validated the domain. Browsers reject them for public sites. Security teams encounter them on internal infrastructure accidentally exposed to the internet, a finding that combines an invalid certificate with an exposure risk.
Hardening TLS in Production
A valid certificate is the starting point, not the finish line. Hardening TLS means disabling legacy protocols, enforcing strong cipher suites, and keeping renewal automated.
Disabling Legacy Protocols
Since recosint.com shows TLS 1.0 and 1.1 as active, the fix is a single server config change:
Nginx:
ssl_protocols TLSv1.2 TLSv1.3;
Apache (mod_ssl):
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
After applying the change, reload the server and re-run the audit to confirm the legacy protocols no longer appear.
Enforcing Strong Cipher Suites
Nginx:
ssl_ciphers ‘ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305’;
ssl_prefer_server_ciphers on;
This prioritizes ECDHE key exchange (forward secrecy), AES-GCM authenticated encryption, and ChaCha20-Poly1305 for mobile CPUs without hardware AES acceleration.
Apache:
SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!RC4
SSLHonorCipherOrder on
Enabling OCSP Stapling
Without OCSP Stapling, the browser contacts the CA’s OCSP server on every TLS handshake to check certificate revocation, adding latency and exposing browsing behavior to the CA. OCSP Stapling moves that check to the server: it fetches a signed OCSP response periodically and includes it in the handshake.
Nginx:
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 1.1.1.1 valid=300s;
Automating Certificate Renewal
Let’s Encrypt certificates expire every 90 days. Manual renewal at that cadence is error-prone. Certbot handles it automatically:
certbot renew –pre-hook “systemctl stop nginx” –post-hook “systemctl start nginx”
Add this to a cron job or systemd timer to run twice daily. Certbot only renews when 30 days or fewer remain.
Cloud Provider TLS Settings
AWS (ALB / CloudFront): Use the ELBSecurityPolicy-TLS13-1-2-2021-06 security policy to enforce TLS 1.2 minimum. Avoid ELBSecurityPolicy-2016-08, which permits TLS 1.0.
Cloudflare: Set Minimum TLS Version to TLS 1.2 in the SSL/TLS dashboard and enable the TLS 1.3 toggle. Certificate renewal is handled automatically for proxied domains.
GCP (Cloud Load Balancing): Apply the MODERN SSL policy profile, which sets TLS 1.2 as the minimum and excludes weak cipher suites.
Technical Details & Use Cases
SSL/TLS certificates have failure modes that browser checks do not surface. The tool retrieves the peer certificate using PHP stream contexts with peer verification, then parses the full chain.
Chain of trust analysis validates that each certificate is signed by the next in sequence, ending at a trusted root CA. A broken chain causes validation failures in strict clients even when the leaf certificate itself is valid.
TLS protocol version testing checks which versions the server will negotiate. TLS 1.0 and 1.1 are both deprecated per RFC 8996. TLS 1.3 support is flagged as the preferred configuration.
SAN enumeration lists every domain the certificate covers. This is essential for scoping penetration tests and confirming multi-domain certificate coverage. Wildcard entries (*.example.com) are identified separately.
Certificate Transparency log integration queries crt.sh for all certificates ever issued to the domain. This surfaces shadow certificates, previously compromised keys, and unauthorized issuance, making it a useful supply chain security check.
Typical use cases: pre-expiry monitoring, chain troubleshooting, TLS hardening, and CT log audits for unauthorized certificates.
Pros & Cons
| Pros | Cons |
| ✓ CT log check surfaces unauthorized certificates without running any active scan | ✗ Cipher suite enumeration requires multiple handshakes, which may trigger WAF rate limits |
| ✓ Chain-of-trust visualization pinpoints missing intermediate certificate problems | ✗ Cannot test mutual TLS (mTLS) configurations that require a client certificate |
| ✓ Days Until Expiry counter gives a precise renewal deadline rather than a vague warning | ✗ crt.sh query depends on external API availability and can have brief response delays |
Related Network Intelligence Tools
Frequently Asked Questions
How do I check if an SSL certificate is valid?
Enter the domain URL into the SSL/TLS Certificate Auditor and click “Check Certificate.” A valid certificate shows a Strong Configuration badge, a current validity window, a trusted issuer, and a complete chain of trust. An invalid or expired certificate triggers a warning status.
What does "Chain of Trust" mean in a certificate check?
It is the sequence of certificates linking a domain’s cert back to a root CA that browsers and operating systems trust by default. For recosint.com, the chain runs: site certificate → Let’s Encrypt intermediate (R12) → ISRG root. If any link is missing or expired, browsers display a security warning even if the site’s own certificate is valid.
Is TLS 1.0 still safe to use in 2026?
No. TLS 1.0 is deprecated (RFC 8996) and disabled in all major browsers. It is vulnerable to POODLE and BEAST attacks and violates PCI DSS requirements. Servers still accepting it should disable it immediately via ssl_protocols TLSv1.2 TLSv1.3; in Nginx or the equivalent in Apache.
What are Subject Alternative Names (SANs)?
SANs are the list of domains a single certificate covers. The SANs for recosint.com include both recosint.com and www.recosint.com. They replaced the older Common Name (CN) field for multi-domain coverage and are standard in modern certificates. Security researchers treat the SAN list as reconnaissance data since it can reveal subdomains or related properties covered under a shared certificate.
What is a good SSL key size in 2026?
RSA 4096 bits is strong and future-resistant. RSA 2048 bits is the current industry minimum and acceptable for most use cases. RSA 1024 bits is insecure. ECDSA keys (256-bit or 384-bit) offer equivalent or better security with smaller key sizes, which reduces TLS handshake overhead on high-traffic servers.
Recosint Intelligence Suite
For Business Inquiries, Sponsorship's & Partnerships
(Response Within 24 hours)
