For those that don't know what Suche.org is, it is a website that has a perfect A+ rating on SSL Labs in every category: (Suche.org SSL Labs result). I became aware of this website when I opened another ticket about ECC certificates not working in Chrome, and one of the responders used the site as an example.

What confuses me is that although the Protocol Support section of the report says that the website only uses TLSv1.2...

TLS 1.2 Yes
TLS 1.1 No
TLS 1.0 No
SSL 3   No
SSL 2   No

That's clearly not the case since under the Handshake Simulation section, it displays that some of the simulated older clients are using TLSv1.0 to connect...

Android 4.0.4   EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.1.1   EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.2.2   EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.3     EC 384 (SHA256)     TLS 1.0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDH secp521r1  FS
Android 4.4.2   EC 384 (SHA256)     TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   ECDH secp521r1  FS

This is a bit frustrating because if I disable TLSv1.0 on my test website like so...

# Apache example
SSLProtocol all -SSLv3 -SSLv2 -TLSv1

Running the SSL Labs scan on my test website yields the following for some of the older clients:

Android 4.0.4   Server closed connection
Android 4.1.1   Server closed connection
Android 4.2.2   Server closed connection
Android 4.3     Server closed connection
Android 4.4.2   EC 384 (SHA256)     TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS

How is it possible to simultaneously allow only TLSv1.2 connections, yet support older clients as well?

  • Should we make the title more generic, something like "HTTPS cert switching logic"?
    – gxx
    Sep 1, 2017 at 10:50
  • 1
    @gf_ Good idea. Done. Sep 1, 2017 at 11:39

2 Answers 2


I'm quite sure that they're checking the client capabilities and act accordingly, as explained in the thread linked to in the answer of @Jeff.

To get an idea how this could look like in detail, have a look at this. It shows an implementation made with HAProxy to serve different clients different certs, depending on their capabilities. I've did a full copy / paste, to prevent link rot, and because I think this question could be of interest in the future:

SHA-1 certificates are on their way out, and you should upgrade to a SHA-256 certificate as soon as possible... unless you have very old clients and must maintain SHA-1 compatibility for a while.

If you are in this situation, you need to either force your clients to upgrade (difficult) or implement some form of certificate selection logic: we call that "cert switching".

The most deterministic selection method is to serve SHA-256 certificates to clients that present a TLS1.2 CLIENT HELLO that explicitly announces their support for SHA256-RSA (0x0401) in the signature_algorithms extension.

signature algorithm extensions

Modern web browsers will send this extension. However, I am not aware of any open source load balancer that is currently able to inspect the content of the signature_algorithms extension. It may come in the future, but for now the easiest way to achieve cert switching is to use HAProxy SNI ACLs: if a client presents the SNI extension, direct it to a backend that presents a SHA-256 certificate. If it doesn't present the extension, assume that it's an old client that speaks SSLv3 or some broken version of TLS, and present it a SHA-1 cert.

This can be achieved in HAProxy by chaining frontend and backends:

HAProxy cert switching


frontend https-in
        mode tcp
        tcp-request inspect-delay 5s
        tcp-request content accept if { req_ssl_hello_type 1 }
        use_backend jve_https if { req.ssl_sni -i jve.linuxwall.info }

        # fallback to backward compatible sha1
        default_backend jve_https_sha1

backend jve_https
        mode tcp
        server jve_https
frontend jve_https
        bind ssl no-sslv3 no-tlsv10 crt /etc/haproxy/certs/jve_sha256.pem tfo
        mode http
        option forwardfor
        use_backend jve

backend jve_https_sha1
        mode tcp
        server jve_https
frontend jve_https_sha1
        mode http
        option forwardfor
        use_backend jve

backend jve
        rspadd Strict-Transport-Security:\ max-age=15768000
        server jve maxconn 128

The configuration above receives inbound traffic in the frontend called "https-in". That frontend is in TCP mode and inspects the CLIENT HELLO coming from the client for the value of the SNI extension. If that value exists and matches our target site, it sends the connection to the backend named "jve_https", which redirects to a frontend also named "jve_https" where the SHA256 certificate is configured and served to the client.

If the client fails to present a CLIENT HELLO with SNI, or presents a SNI that doesn't match our target site, it is redirected to the "https_jve_sha1" backend, then to its corresponding frontend where a SHA1 certificate is served. That frontend also supports an older ciphersuite to accommodate older clients.

Both frontends eventually redirect to a single backend named "jve" which sends traffic to the destination web servers.

This is a very simple configuration, and eventually it could be improved using better ACLs (HAproxy regularly adds news ones), but for a basic cert switching configuration, it gets the job done!


A similar question was asked at https://community.qualys.com/thread/16387

I think this answer is the solution:

suche.org is a clever implementation. As far as I understand, it queries the client's capabilities and then only offers the best available, to take away any doubt.

  • 2
    "it queries the client's capabilities" isn't exactly a useful description, though. There's hardly enough information for anyone else to do their own implementation.
    – womble
    Jul 27, 2016 at 3:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .