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