SSL Cipher Checker

See the actual cryptography behind a site's HTTPS connection. Enter a domain and this tool completes a live TLS handshake and reports the negotiated cipher suite, its strength in bits, the certificate's key type and size (RSA / EC), the signature algorithm, whether the connection uses forward secrecy, and which TLS protocol versions the server supports. It is the quick way to sanity-check that a server negotiates strong, modern crypto.

We complete a real handshake from our server to see what gets negotiated. Nothing is stored.

How to use the SSL Cipher Checker

Enter a domain and press Check cipher. The tool performs a live TLS handshake and reports:

  • Negotiated protocol and cipher suite — for example TLS 1.3 with TLS_AES_128_GCM_SHA256, the exact combination your connection used.
  • Cipher strength — the symmetric key size in bits (128 and 256 are both strong with modern AEAD ciphers).
  • Certificate key — the public-key type and size, such as RSA 2048-bit or EC (ECDSA) 256-bit.
  • Signature algorithm — e.g. SHA-256 with RSA or ECDSA (SHA-1 is obsolete and would be a red flag).
  • Forward secrecy — whether the key exchange is ephemeral (ECDHE/DHE), which protects past traffic even if the server key is later compromised.
  • Protocol support — which TLS versions the server accepts.

This reflects what a real client negotiates with the server right now, which is the practical answer to "is this connection using strong crypto?"

What a TLS cipher suite is

When a browser and server set up an HTTPS connection, they agree on a cipher suite — the specific set of algorithms used to secure the session. A suite combines several pieces:

  • Key exchange — how the two sides agree on a shared secret. Modern suites use ECDHE (ephemeral elliptic-curve Diffie-Hellman), which provides forward secrecy: each session uses a fresh key, so capturing today's traffic and stealing the server key later still does not decrypt it.
  • Authentication — how the server proves its identity, tied to the certificate's key (RSA or ECDSA).
  • Bulk encryption — the symmetric cipher that actually encrypts the data, today an AEAD cipher like AES-GCM or ChaCha20-Poly1305.
  • Integrity — how each message is authenticated against tampering (built into AEAD ciphers).

TLS 1.3 simplified all of this. It removed every weak option, so its handful of suites (such as TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256) are all strong and all provide forward secrecy by design. TLS 1.2 has a much larger menu that ranges from excellent to obsolete, so on a 1.2 connection the specific negotiated suite matters more.

This tool shows the suite that was actually negotiated for a live connection, plus the certificate's key and signature details. That answers the everyday question — "did this connection use strong, modern crypto?" — directly. It is not a full per-cipher audit: enumerating every suite a server will accept (the kind of exhaustive scan a dedicated SSL-rating service runs) is a heavier process. For a fast, real-world reading of the crypto in use, the negotiated result here is exactly what you want.

Common use cases

  • Confirming strong crypto — verify a connection negotiates an AEAD cipher (AES-GCM / ChaCha20) over TLS 1.2 or 1.3.
  • Checking forward secrecy — make sure the key exchange is ephemeral (ECDHE), a baseline modern requirement.
  • Validating a key migration — confirm a move from RSA to a faster ECDSA (EC) certificate actually took effect.
  • Spot-checking signature strength — ensure the certificate is signed with SHA-256 or better, never SHA-1.
  • Quick security sanity checks — get a fast read on a server's negotiated crypto without running a full external scan.

Strong vs weak: what to look for

  • Good: TLS 1.3, or TLS 1.2 with an ECDHE key exchange and an AES-GCM or ChaCha20-Poly1305 cipher. EC (ECDSA) certificate keys, or RSA 2048-bit and above. SHA-256+ signatures.
  • Weak / avoid: non-ephemeral key exchange (no forward secrecy), CBC-mode ciphers, RC4, 3DES, RSA keys under 2048 bits, or SHA-1 signatures. Any of these means the server is offering legacy options it should disable.
  • To harden TLS 1.2, configure your server to prefer ECDHE + AEAD suites and remove legacy ciphers. Enabling TLS 1.3 sidesteps the issue entirely, since all of its suites are strong.

Frequently asked questions

What cipher is this website using?
Enter the domain above and press Check cipher. The tool completes a live handshake and shows the negotiated cipher suite, its strength, the certificate key, the signature algorithm and forward-secrecy status.

What is forward secrecy?
Forward secrecy means each session uses a fresh, ephemeral key (via ECDHE/DHE key exchange), so an attacker who records encrypted traffic and later steals the server's private key still cannot decrypt that past traffic. It is a baseline requirement on modern servers.

Is a 128-bit cipher weaker than 256-bit?
Not in any practical sense. With modern AEAD ciphers, 128-bit (AES-128-GCM) is considered fully secure; 256-bit adds margin but no meaningful real-world difference. The key-exchange and protocol version matter far more than 128 vs 256.

Does this list every cipher the server supports?
No. It shows the suite actually negotiated for a live connection, which answers "is the crypto in use strong?" A full per-cipher enumeration requires a dedicated, heavier scanner. This gives you the fast, real-world result.

RSA or ECDSA — which certificate key is better?
ECDSA (EC) keys are smaller and faster for the same security level, so they are generally preferred for new certificates. RSA 2048-bit and above is still perfectly secure and more universally compatible. Many sites serve both.

Does this store the domains I check?
No. The handshake runs against the live server and nothing is saved.