I noticed this visiting https://sslanalyzer.comodoca.com/ and my browser failed to connect, complaining that the site’s certificate had expired.
So I tried testing the Comodo site using the Qualys SSL Labs test site:
https://www.ssllabs.com/ssltest/analyze.html?d=sslanalyzer.comodoca.com
It turns out, that if the client is unable to support Elliptical Curve Cryptography (ECC) for either ECDHE key exchange or ECDSA signatures, the site presents a second “fallback” certificate that uses an RSA key.
I was testing using a browser/client/SSL inspection appliance that does not have ECC libraries, and so cannot process the primary ECDSA certificate. The server appears to be detecting this via the ClientHello CipherSuite which tells the server that the client cannot perform ECDHE key agreement (and/or ECDSA signature validation). The server then responds by presenting the client with the RSA fallback certificate.
However, the current RSA-keyed “fallback” certificate is expired: Fri, 22 Apr 2016 23:59:59 UTC (expired 7+ months and counting).
If Comodo support fixes this, you’ll just have to inspect the certificate directly, or examine Cert #2 using the Qualys SSL Labs test site.
While I’ve filed a separate support ticket for the Comodo operations support team to get a valid replacement RSA certificate for the site, my question has more to do with what webserver software currently supports such a “dual” response by presenting different certificates depending on the CipherSuites supported by the Client in the ClientHello.
- What server software or TLS/SSL libraries support this?
- Is it a forced configuration to always present both certificates to the client and let the client sort it out?
- Is there magic ordering in the response chain required?