TLS Extension Analyzer

Analyze TLS extensions supported by a server

About TLS Extensions

TLS extensions are parameters sent during the TLS handshake that enable additional features and capabilities. They include supported elliptic curves, ALPN (Application-Layer Protocol Negotiation), key share data for TLS 1.3, Server Name Indication (SNI), session tickets, and many others. Analyzing these extensions helps understand server capabilities, troubleshoot compatibility issues, and ensure optimal TLS configuration.

How to Use

Enter the domain name of the server you want to analyze.
Click "Check" to inspect the TLS extensions supported by the server.
Review the results showing supported groups, ALPN protocols, key share, and other extensions.
Use the information to verify TLS configuration and troubleshoot compatibility.

Use Cases

•Verify that a server supports the latest TLS 1.3 extensions
•Troubleshoot compatibility issues between clients and servers
•Check which ALPN protocols (HTTP/2, HTTP/1.1) a server advertises
•Audit supported elliptic curves for forward secrecy compliance

Frequently Asked Questions

TLS extensions are additional parameters that can be included in TLS handshake messages to enable optional features. They were introduced in TLS 1.0 and expanded significantly in TLS 1.3. Common extensions include SNI (server name), ALPN (protocol negotiation), supported_groups (elliptic curves), and key_share.

ALPN (Application-Layer Protocol Negotiation) is a TLS extension that allows the client and server to negotiate which application protocol to use over the TLS connection, such as HTTP/2 or HTTP/1.1. It is essential for modern web performance, as HTTP/2 requires ALPN to function properly.

TLS 1.3 requires the supported_versions extension and uses several mandatory extensions including key_share (for key exchange), signature_algorithms, and supported_groups. The server must also support the extension for pre_shared_key and cookie extensions for session resumption.

Because this client library does not expose the extensions the server sent. Reporting a plausible-looking list would mean inventing entries, which is worse than reporting none — an earlier version of the stapling checker did exactly that. Extensions are readable from the client side, so the client-hello page documents them properly; this page covers what a live server handshake actually reveals.

Usually the application protocol is not configured for that specific server block or vhost, so the server declines ALPN and the client falls back to HTTP/1.1. It can also mean a proxy is terminating TLS without passing ALPN through. Nothing breaks, which is why it goes unnoticed — the cost is lost multiplexing and header compression on every connection.

ALPN and status_request for daily value: the first decides whether HTTP/2 happens, the second whether revocation is checked without a round trip to the CA. Others matter for compatibility and security — supported_groups and signature_algorithms determine whether a handshake completes at all with older clients, and renegotiation_info protects against a class of attacks. Each affects different failure modes rather than ranking against each other.

Often yes, which is the counter-intuitive part. If the client's supported_groups and signature_algorithms lists do not intersect what the server accepts, the handshake fails outright despite a perfectly valid certificate. That is why these lists exist and why extending them as algorithms are deprecated matters — a server that never updated its accepted signature algorithms can refuse connections from clients that dropped older ones.

From the client side, which is where the extension data is available. The client-hello page on this site reads what a client sends, and a packet capture or a tool built on a lower-level TLS library will show both directions in full. What a high-level client library will not give you is the server's response list, and that limitation is why this page reports negotiation outcomes rather than pretending to enumerate them.

What Can Be Observed

Extensions are what make modern TLS do more than encrypt. This page reports the ones a client library genuinely exposes from the client side, and marks the rest as not visible rather than listing plausible-looking entries.

1Complete a real handshake offering HTTP/2 and HTTP/1.1 through ALPN, and record the protocol and cipher actually selected.
2Report the negotiated application protocol when one was selected, since a server that declines ALPN falls back to HTTP/1.1 without any visible error.
3Report stapling as not observable. Reading the server's extension list would require a client API that does not exist here, so it is returned empty rather than filled with entries that were never seen. The client-hello page covers extensions from the side that can read them.

The practical value here is confirming that negotiation works end to end. A server advertising HTTP/2 in its configuration but selecting nothing under ALPN has a problem no configuration review would reveal, and that gap is what this page closes.

Tips & Best Practices

•Analyze TLS extensions to understand client and server capabilities
•Configure important extensions like SNI, ALPN, and OCSP stapling
•Monitor extension usage for security and compatibility analysis
•Compare extension support across different TLS implementations

Technical Details

Extensions: TLS extension identification and analysis
Types: SNI, ALPN, OCSP stapling, session tickets, supported groups
Support: Extension support detection and negotiation
Output: TLS extension list with support and security assessment