7

What I'm trying to archive is enable ECDSA and DSS ciphers in my site, but at the same time not depend just of self signed certificates, so I could sent to my client more than one certificate and them could select ECDSA and DSS over RSA if they can verify my self signed certificate, and if not, fall back to a CA signed certificate and refuse ECDSA and DSS.

  • 5
    For the question whether it is possible to configure multiple certificates depending on the chosen cipher, it depends on the server. `openssl s_server` and GnuTLS' `gnutls-serv` allows you to specify additional certificates. Try `openssl s_server -cert rsa.crt -key rsa.pem -dcert secp384r1-dsa.crt -dkey secp384r1-dsa.pem -www` for fun with `openssl s_client -cipher ECDHE-ECDSA-AES256-SHA` and `openssl s_client -cipher ECDHE-RSA-AES256-SHA`. (requires appropriate ECDSA and RSA certificates of course) – Lekensteyn Oct 04 '13 at 17:55
  • That is great! @Lekensteyn Shame that such feature is not supported in Apache neither Nginx. –  Oct 04 '13 at 18:33
  • FYI: With Apache 2.4.8 and up, the `SSLCertificateFile` directive can be used [two or more times](https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#page-header): _[SSLCertificateFile] points to a file with certificate data in PEM format.... The directive can be used multiple times (referencing different filenames) to support multiple algorithms for server authentication - typically RSA, DSA, and ECC. The number of supported algorithms depends on the OpenSSL version being used for mod_ssl_ – GLRoman Apr 12 '22 at 16:37

1 Answers1

10

Strictly speaking, the server can send an arbitrary number of certificates to the client, as part of its Certificate message. However, as the standard says:

The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it.

Therefore, a really compliant server cannot send a choice of certificates to the client, and cannot expect clients to use any other certificate than the first one they send.

For signature algorithm support, there is a standard TLS extension specified in section 7.4.1.4.1, by which the client can tell to the server, early in the handshake (in the ClientHello, which is the very first message of the procedure), which hash functions and signature algorithms it supports. This allows a server who owns, for instance, both a RSA-signed certificate and an ECDSA-signed certificate, to send one or the other, depending on what the client supports. This is typical of how things go in TLS: the client suggests, the server chooses.

(In practice, support for this extension is not yet widespread. But, also in practice, everybody uses RSA and supports RSA.)

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • I got it! Anyway, after read your reply I realize that beside the server have the capacity to send one certificate or another depending on what the client said it support/prefer, the client must have too the capacity to send one ClientHello or another depending of the type of the certificate signature it know was used to sign the server certificate. In resume, if I want support such behavior, I must have a custom client implementation.This constrain is not a problem in my case, but the fact that server support of such TLS extension is poor by these day,I must forget about.Thanks a gain Thomas! –  Oct 04 '13 at 18:30
  • 1
    Seems that https://www.google.com/ is doing it right now. – lapo Jan 23 '14 at 21:52
  • 2
    Sigalgs is new in TLS1.2, but in all protocols (back to SSL3) DHE-DSS or ECDHE-ECDSA suites require a server cert *containing* a DSS or ECC key, regardless of the algorithm *signing* the cert. However, the OP wants to choose based (partly) on which certs the client trusts, which isn't related to what algorithms it supports. RFCs 3546,4366,6066 do define an extension for "Trusted CA Indication" but I've never seen anybody implement it. – dave_thompson_085 Nov 27 '14 at 05:11