SSL Toolkit Logo
Tools Features Compare FAQ Login

SSL/TLS Protocol Compatibility Matrix

Check which SSL/TLS protocols are supported by a server

Protocol Support

About

The Protocol Support Matrix provides a comprehensive view of which TLS and SSL protocol versions are supported across your entire server infrastructure. It creates a matrix view showing protocol support status for each server, making it easy to identify inconsistencies.

This matrix view is essential for organizations managing multiple servers, as it highlights configuration differences that could indicate security gaps or compatibility issues.

How to Use

  1. 1Enter multiple server addresses (domain:port), one per line
  2. 2Click "Generate Matrix" to test protocol support on all servers simultaneously
  3. 3Review the matrix showing support status for each protocol version on each server
  4. 4Identify and address any servers with unsupported or deprecated protocol configurations

Use Cases

  • •Infrastructure Audit: Get a complete view of protocol support across all TLS endpoints
  • •Consistency Check: Identify servers with different protocol configurations that should be uniform
  • •Hardening Validation:** Confirm that deprecated protocols are disabled on all servers
  • •Compliance Reporting:** Generate protocol support evidence for compliance auditors
  • •Migration Tracking:** Monitor protocol configuration changes during security hardening projects

How Each Version Is Tested

A version counts as supported only when a handshake restricted to exactly that version completes. Pinning both the minimum and maximum is what makes the test mean anything.

  1. 1Offer TLS 1.0, 1.1, 1.2 and 1.3 one at a time, each in its own connection pinned to that single version. This is the same technique as the downgrade page, and it is what distinguishes acceptance from preference.
  2. 2Report each version's result and list the deprecated ones found. Every deprecated version costs 20 points, so the score reflects how much legacy surface remains reachable.
  3. 3State that SSLv2 and SSLv3 are not testable here, rather than reporting either result. The TLS library this server uses has removed both, so no client handshake can probe them; claiming they are absent would be an assertion nobody made. An earlier version of this page tested them with an unpinned context that simply negotiated modern TLS, reporting both as supported on every host.

The score counts only versions actually probed. A clean score means no deprecated TLS version is negotiable and says nothing about SSL versions that cannot be tested from here.

Tips & Best Practices

  • •Aim for consistent TLS 1.2/1.3 support across all servers
  • •Flag any server still supporting SSL 3.0, TLS 1.0, or TLS 1.1 for immediate remediation
  • •Use the matrix to establish a baseline and track changes over time
  • •Export the matrix for regular compliance reporting

Technical Details

●Protocols: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 support testing
●Capacity: Up to 50 servers per matrix generation
●Matrix: Visual table with color-coded support status
●Export: CSV and JSON export for compliance documentation

Frequently Asked Questions

The protocol matrix supports up to 50 servers per operation. For larger infrastructure, generate multiple matrices and combine the results. The export functionality allows combining results from multiple matrix operations.
Green indicates the protocol is supported and should be supported (TLS 1.2/1.3). Yellow indicates the protocol is supported but may pose security risks (TLS 1.1). Red indicates the protocol is supported but should be disabled (SSL 3.0, TLS 1.0). Gray indicates the protocol is correctly disabled.
Yes, matrix results are stored in your scan history. You can compare current results with previous matrices to track protocol configuration changes and demonstrate compliance over time.
Because the TLS library this server uses no longer implements SSLv2 or SSLv3, so a client here cannot complete a handshake with either regardless of what a server offers. Reporting them as absent would be a claim no measurement supports. They are shown as untestable and excluded from the score, which is why an older version of this page that appeared to test them was reporting false results.
They disabled the version instead of requiring it. The context was built without pinning and then had that specific version switched off, so the handshake simply negotiated whatever modern version both ends preferred and reported success — every host looked as though it supported SSLv2 and SSLv3, and lost 40 points for versions never actually attempted. Version tests must pin both the minimum and maximum.
Scope rather than method. Both pin each version individually; the downgrade page reduces the results to a single risk grade suited to a yes-or-no decision, while this page keeps the per-version results alongside a score and a deprecated list. Use the downgrade page to answer whether action is needed, and this one when you want the detail behind it.
It means no deprecated TLS version was negotiable, which is the meaningful part for modern clients. It does not speak to SSL versions untestable from here, to ciphers you never offered, or to anything on a proxy that terminates TLS before reaching your server. It is a strong signal with a well-defined boundary — useful precisely because you know what it excludes.
Either the server does not offer it, or the TLS library here cannot reach it for that particular connection. Some middleboxes and older stacks negotiate 1.2 successfully while blocking 1.3. The downgrade page covers this case explicitly and includes a way to distinguish a server that lacks 1.3 from a path that prevents it, which is worth running when this page and your expectations disagree.

Related Tools

TLS Version Checker Protocol Version Matrix Cipher Scanner SSL Hardening SSL Scanner Batch Checker