up vote 5 down vote favorite
2

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.

share|improve this question
4  
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 4 '13 at 17:55
    
That is great! @Lekensteyn Shame that such feature is not supported in Apache neither Nginx. – gsi-frank Oct 4 '13 at 18:33
up vote 8 down vote accepted

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

share|improve this answer
    
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! – gsi-frank Oct 4 '13 at 18:30
1  
Seems that google.com is doing it right now. – lapo Jan 23 '14 at 21:52
1  
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 5:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.