Certificate Compression Checker

Check if TLS certificate compression is supported

About Certificate Compression

TLS certificate compression reduces the size of certificates during the TLS handshake, decreasing latency and improving page load times. The compression is negotiated during the TLS handshake, and both client and server must support it. Our Certificate Compression Checker tests whether a server advertises support for certificate compression, helping you identify opportunities to optimize TLS performance.

How to Use

Enter the domain name you want to test (e.g., example.com).
Optionally change the port number (default is 443 for HTTPS).
Click the Check button to run the test.
Review the results showing whether certificate compression is supported and which compression methods are available.

Use Cases

Performance Optimization: Identify servers that can benefit from certificate compression to reduce TLS handshake size.
Mobile Optimization: Reduce bandwidth usage for mobile clients with compressed certificate chains.
CDN Configuration: Verify that your CDN or reverse proxy supports certificate compression for edge connections.
Security Auditing: Include compression support checks as part of your TLS configuration audit.

Frequently Asked Questions

TLS certificate compression is a mechanism defined in RFC 8879 that reduces the size of certificate chains during the TLS handshake. It uses algorithms like zlib or brotli to compress certificates, resulting in faster handshakes and reduced bandwidth usage.

Large certificate chains can add hundreds of kilobytes to the TLS handshake. Compression reduces this overhead, improving page load times especially on slow connections, mobile networks, and for users accessing sites with complex certificate hierarchies.

Support depends on the TLS library and server software. Modern versions of OpenSSL (3.0+), BoringSSL, and recent web servers like Nginx (with patches) may support it. Use this checker to verify if a specific server has compression enabled.

A compression side-channel attack. When a secret such as a session cookie is compressed together with attacker-controlled data, the response length varies in a way that leaks information about the secret, and a determined attacker can recover it from many observations. TLS compression was removed largely because of it — the exposure was not worth the small bandwidth saving.

Not by itself. Three things have to line up: compression enabled on a TLS connection, a secret present in that connection, and an attacker able to trigger requests of chosen sizes and observe responses. Compression is off by default in current clients and servers, so most servers offering 1.2 have already removed the mechanism. Upgrading to 1.3 removes the possibility structurally.

Because it is not observable from a client handshake. Compression is negotiated internally by the TLS library rather than advertised as an extension, so a checker has no way to see the server's offer. The honest answer is the version plus an explanation of the limit. Confirming the server side means reading its configuration or watching a capture, not running another probe.

No, and the distinction is worth being clear about. Compressing HTTP response bodies with gzip or brotli is unrelated to TLS compression and creates no comparable exposure, because application data is not compressed together with the secret. Only compression at the TLS record layer created the CRIME exposure. Disabling gzip on your web server would cost bandwidth and fix nothing.

If the server is on TLS 1.3, there is nothing to do — compression does not exist in the protocol. If it is on 1.2 or below, confirm TLS compression is disabled in the server configuration, which is the default in every current implementation, and treat a page result as inconclusive rather than as a pass. Enabling 1.3 alongside 1.2 makes the question moot for most clients.

What This Page Reports

TLS compression is the mechanism behind CRIME, and checking it honestly turns out to be mostly a question of protocol version rather than a server setting.

1Read the negotiated version, because on TLS 1.3 the question is settled: the protocol defines no compression at all, so CRIME cannot apply to such a connection regardless of configuration.
2On 1.2 and below, state plainly what cannot be read. Compression is negotiated inside the TLS library rather than advertised as an inspectable extension, so a client-side check has no way to observe whether the server offers it.
3Report no finding rather than a false pass. Compression is off by default in current clients and servers, so the practical answer for almost every host is that it is disabled — but the page says that as context, not as a measurement it made.

An earlier version returned compression unsupported on every successful connection without connecting the result to anything it had observed. The page now ties its answer to the negotiated version and explains the limit.

Tips & Best Practices

•Certificate compression is most beneficial for chains with 2+ intermediates
•Cloudflare enables compression automatically for eligible certificates
•Check OpenSSL version support before implementing on self-hosted servers
•Monitor performance metrics before and after enabling compression

Technical Details

Extension: TLS certificate_compression (RFC 8879)
Algorithms: Brotli and zlib compression analysis
Analysis: Certificate structure, chain length, compression ratio estimation
Servers: Nginx 1.19.4+, Apache with OpenSSL 1.1.1+