ECDSA certificates and RSA fallback certificates

I noticed this visiting 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:

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?

If memory serves…OpenSSL 1.02f with NGINX 1.11 or Apache 2.4x support such a configuration. You simply define two certificates to use and simply give priority (“honoring”) to the EC related ciphers. I don’t recall any magic finagling with chains unless it wasn’t a supported version of OpenSSL.

If you have the ability to specify the cipher you want to use with your client, you could force RSA over ECC, if need be.

If you have OpenSSL or one of its variants…

openssl s_client -connect site:port cipher CIPHER-HERE

  1. Locate the Ciphers that site supports using Comodo’s SSL Analyzer in the Cipher Suites Enabled section (near bottom)


  1. Translate/map RFC Cipher name to something OpenSSL can understand as it does not yet understand either value shown in the SSL analyzer. I found an awesome site that has a bunch of this already mapped for us. ;D


[td]Cipher Type[/td]
[td]SSL Analyzer Cipher[/td]
[td] → [/td]
[td]OpenSSL Cipher[/td]

[td]ECC / ECDSA[/td]
[td]TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC02B)[/td]
[td] → [/td]

[td]TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9D)[/td]
[td] → [/td]

  1. Plug in cipher map and read output.

Since you’re trying to compare validity periods & the signature algorithm (which can be found on the CN of the CA), the commands would look like:

openssl s_client -connect -cipher AES256-GCM-SHA384 | openssl x509 -dates -noout
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
notBefore=Apr 23 00:00:00 2014 GMT
notAfter=Apr 22 23:59:59 2016 GMT

openssl s_client -connect -cipher ECDHE-ECDSA-AES128-GCM-SHA256 | openssl x509 -dates -noout
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Certification Authority
verify error:num=20:unable to get local issuer certificate
notBefore=Dec 7 00:00:00 2015 GMT
notAfter=Mar 6 23:59:59 2018 GMT

Note: You can ignore verify error:num=20:unable to get local issuer certificate for this exercise.
Note 2: You can use -text in place of -dates to show additional details of the certificate that has been parsed


You’ll notice that depending which cipher is used, you’ll get the corresponding RSA or ECDSA cert. :wink:

FYI, fallback cert has been updated and now expires in March 2019. 8)