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
    Commented Oct 4, 2013 at 17:55
  • That is great! @Lekensteyn Shame that such feature is not supported in Apache neither Nginx.
    – user30395
    Commented Oct 4, 2013 at 18:33
  • FYI: With Apache 2.4.8 and up, the SSLCertificateFile directive can be used two or more times: [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
    Commented Apr 12, 2022 at 16:37

1 Answer 1


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, 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.)

  • 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!
    – user30395
    Commented Oct 4, 2013 at 18:30
  • 1
    Seems that google.com is doing it right now.
    – lapo
    Commented Jan 23, 2014 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. Commented Nov 27, 2014 at 5:11

You must log in to answer this question.