As per the SSL/TLS standard:
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it.
What may happen depends on the client: some will simply disregard the chain and simply revalidate the server's certificate, using the provided certificate as an unordered bag of "potentially useful certificates". Others will reject the chain and refuse to connect. A sub-case is when the certificates are so out-of-order that the first certificate in the chain is not the server's actual certificate: in that case, clients who did not rejected the chain will try to use the wrong certificate, and this ought to trigger a "name mismatch" warning (i.e. the client is trying to use the certificate of an intermediate CA, and the CA name does not match the expected server name); and it would ultimately lead to a handshake failure since the CA public key is not the server's public key.
In any case, the SSL handshake ends with a pair of Finished messages which are used to check that everything went well. If the client does not use the correct public key, the key exchange will fail, or (at worst) the Finished messages won't match, and no application data will be sent or received. There will not be any "incorrectly encrypted request/response".
