You should concatenate all (that is intermediate - but you may have one or more of them - and CA) certificates and put it in "certificate CA" field, while you put the server certificate in the "certificate" field.
Note that the CA certificate ("root" certificate) is technically not needed in "certificate CA" field (which then introduces quite a misleading term) because clients should already have locally the CA (root) certificate, hence only the intermediate(s) should be needed. But adding the root one should not have drawbacks either.
The order is normally not relevant.
The latest TLS specifications (https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2) say this:
Because certificate validation requires that trust anchors be
distributed independently, a certificate that specifies a trust
anchor MAY be omitted from the chain, provided that supported peers
are known to possess any omitted certificates.
and
Note: Prior to TLS 1.3, "certificate_list" ordering required each
certificate to certify the one immediately preceding it; however,
some implementations allowed some flexibility. Servers sometimes
send both a current and deprecated intermediate for transitional
purposes, and others are simply configured incorrectly, but these
cases can nonetheless be validated properly. For maximum
compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.
(you do not need to care about the last part, since this is done automatically properly by the server software as you have two fields, to clearly separate the server certificate from the "others".)
That way the server should properly send on one side its certificate, and separately the chain of trust needed by clients to ascertain your server certificate is valid and descending from some known CA they trust.
