Let's say I have a TLS certificate for a domain but I'm not sure if all user agents potentially connecting over HTTP would accept it. Can I obtain another certificate, signed by another certificate authority, and use it in such cases as a fallback, transparently to the user? If it's possible, how would the client-server communication to establish a secure connection proceed? And is this use case well known and supported in configuration of popular HTTP servers?
I know there are similar questions but they ask about varying the used certificate by subdomain (possible) or path prefix (impossible IIUC because at negotiation time the server knows only the authority, not the full Request-URI).
Best Answer
A server can support more than one TLS certificate. But it can only offer a single TLS certificate in the TLS handshake with the client. AFAIK that is the limit set in the TLS (handshake) protocol RFC 5246
The capability to support multiple certificates is most frequently used when you have several different domain names that all point to the same server.
Server Name Indication sends the hostname of the server in the TLS handshake made by the client. That allows the server to select the best matching certificate to use for that connection. I.e. the server can then use the certificate for
www.example.comwhen the client indicates that it wants to connect towww.example.comand it can use a different (or default) certificate when the client is connecting with for example only the IP-address, no hostname or a different hostname in the ClientHello message.In addition to the server name from the ClientHello TLS handshake message a server can be configured to use other parameters to select a different certificate.
For example when during the TLSv1.2 handshake the client indicates that the first preference is to use elliptic curves rather than RSA , then an ECDSA key/certificate can be offered and for clients that don't, an RSA certificate can be offered instead.
See for example https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/ and/or https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile
You can do the same with for example legacy clients that don't support ciphers above TLSv1.0
But once the certificate has been selected by the server, there is no fallback, the client either accepts or rejects the offered certificate.