I found another link, as the purpose of this was to use both RSA and ECDSA for signing, but that, to my understanding, requires different public/private keys and therefore different certificates
See the following link https://security.stackexchange.com/questions/43360/is-possible-that-a-tls-server-send-more-than-one-certificate-to-the-client-for-t
For signature algorithm support, there is a standard TLS extension
specified in section 184.108.40.206.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
So it seems to support both ECC and RSA you HAVE to get the client supported algorithms early then play a 'trick' by swapping out the cert. It seems there is no way to just have it be based on the support list of ciphers where you can send multiple certs and have one be your RSA one and the other your ECC one.
Here is another link https://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls that confirms that the certificate and the key exchange and cert keys have to match up
You may use a key exchange (as part of a cipher suite) only if the server key type and certificate match.