Lo que estoy tratando de archivar es habilitar los cifrados ECDSA y DSS en mi sitio, pero al mismo tiempo no depende solo de los certificados autofirmados, por lo que podría enviar a mi cliente más de un certificado y estos podrían seleccionar ECDSA y DSS sobre RSA si pueden verificar mi certificado autofirmado y, de no ser así, recurrir a un certificado firmado por CA y rechazar ECDSA y DSS.
Estrictamente hablando, el servidor puede enviar un número arbitrario de certificados al cliente, como parte de su mensaje Certificate . Sin embargo, como dice el estándar :
del remitente El certificado DEBE estar primero en la lista. Cada siguiente El certificado DEBE certificar directamente el que lo precede.
Por lo tanto, un servidor realmente compatible no puede enviar una selección de certificados al cliente y no puede esperar que los clientes usen ningún otro certificado que no sea el primero que envían.
Para compatibilidad con algoritmos de firma , hay una extensión TLS estándar especificada en sección 7.4.1.4.1 , mediante la cual el cliente puede informarle al servidor, al comienzo del protocolo de enlace (en ClientHello , que es el primer mensaje del procedimiento) , que hash funciones y algoritmos de firma que soporta. Esto permite que un servidor que posee, por ejemplo, un certificado firmado por RSA y un certificado firmado por ECDSA, envíe uno u otro, según lo que el cliente admita. Esto es típico de cómo van las cosas en TLS: el cliente sugiere, el servidor elige.
(En la práctica, el soporte para esta extensión aún no está muy extendido. Pero, también en la práctica, todos usan RSA y son compatibles con RSA).
Lea otras preguntas en las etiquetas tls certificates certificate-authority cipher-selection