Author Topic: ECDSA certificates and RSA fallback certificates  (Read 852 times)

Offline mike808

  • Newbie
  • *
  • Posts: 1
ECDSA certificates and RSA fallback certificates
« on: December 21, 2016, 01:15:07 PM »
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?

Offline Sal Amander

  • Comodo's Hero
  • *****
  • Posts: 740
Re: ECDSA certificates and RSA fallback certificates
« Reply #1 on: December 21, 2016, 01:33:25 PM »
...
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.

Offline Sal Amander

  • Comodo's Hero
  • *****
  • Posts: 740
Re: ECDSA certificates and RSA fallback certificates
« Reply #2 on: December 21, 2016, 02:39:59 PM »
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)

e.g. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  (0xC02B) & TLS_RSA_WITH_AES_256_GCM_SHA384  (0x9D)

2) 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

So...
Cipher TypeSSL Analyzer Cipher --> OpenSSL Cipher
ECC / ECDSATLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  (0xC02B) --> ECDHE-ECDSA-AES128-GCM-SHA256
RSATLS_RSA_WITH_AES_256_GCM_SHA384  (0x9D) --> AES256-GCM-SHA384


3) 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 sslanalyzer.comodoca.com:443 -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 sslanalyzer.comodoca.com:443 -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.  ;)

Offline Sal Amander

  • Comodo's Hero
  • *****
  • Posts: 740
Re: ECDSA certificates and RSA fallback certificates
« Reply #3 on: December 23, 2016, 12:36:24 PM »
FYI, fallback cert has been updated and now expires in March 2019. 8)

 

Free Endpoint Protection
Seo4Smf 2.0 © SmfMod.Com Smf Destek