Digamos que eu tenha um certificado TLS para um domínio, mas não tenho certeza se todos os agentes de usuário potencialmente conectados por HTTP o aceitariam. Posso obter outro certificado, assinado por outra autoridade de certificação, e usá-lo nesses casos como um fallback, de forma transparente para o usuário? Se for possível, como procederia a comunicação cliente-servidor para estabelecer uma conexão segura? E este caso de uso é bem conhecido e suportado na configuração de servidores HTTP populares?
Eu sei que existem perguntas semelhantes, mas eles perguntam sobre a variação do certificado usado por subdomínio (possível) ou prefixo de caminho (impossível IIUC porque no momento da negociação o servidor conhece apenas a autoridade, não o URI completo da solicitação).
Um servidor pode oferecer suporte a mais de um certificado TLS. Mas ele só pode oferecer um único certificado TLS no handshake TLS com o cliente. AFAIK que é o limite definido no protocolo TLS (handshake) RFC 5246
A capacidade de oferecer suporte a vários certificados é usada com mais frequência quando você tem vários nomes de domínio diferentes que apontam para o mesmo servidor.
A Indicação do Nome do Servidor envia o nome do host do servidor no handshake TLS feito pelo cliente. Isso permite que o servidor selecione o melhor certificado correspondente a ser usado para essa conexão. Ou seja, o servidor pode usar o certificado para
www.example.comquando o cliente indicar que deseja se conectarwww.example.come pode usar um certificado diferente (ou padrão) quando o cliente estiver se conectando, por exemplo, apenas com o endereço IP, sem nome de host ou com um nome de host diferente na mensagem ClientHello.Além do nome do servidor da mensagem de handshake ClientHello TLS, um servidor pode ser configurado para usar outros parâmetros para selecionar um certificado diferente.
Por exemplo, quando durante o handshake TLSv1.2 o cliente indica que a primeira preferência é usar curvas elípticas em vez de RSA , uma chave/certificado ECDSA pode ser oferecido e para clientes que não o fazem, um certificado RSA pode ser oferecido.
Veja por exemplo https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/ e/ou https://httpd.apache.org/docs/ 2.4/mod/mod_ssl.html#sslcertificatefile
Você pode fazer o mesmo com, por exemplo, clientes herdados que não suportam cifras acima de TLSv1.0
Mas uma vez que o certificado foi selecionado pelo servidor, não há fallback, o cliente aceita ou rejeita o certificado oferecido.