TLS includes the capability for the server to authenticate the client using a certificate. This is known as symmetric authentication or client authentication. Symmetric authentication is rarely used with public HTTPS websites, due to the complexities of issuing personal certificates to users, but is more common with various TLS applications within organizations.
While server certificates are expected to identify the server host machine, generally by its domain name, PKIX does not specify what a client certificate will identify. The possibilities include:
If you want to use symmetric authentication with features such as CICS Web Interface, DCAS, or ELF (TN3270 Express Login Facility, which uses DCAS and TN3270 macros to sign users in automatically) you might want to consider expanding the use of symmetric authentication. For example, if you are issuing client certificates to users anyway, they could set other TLS-enabled listeners to require client certificates, making it more difficult for attackers to connect to those listeners.
When you configure a certificate for a server or client, you can, and often should, specify not just the entity certificate (which identifies the server or client) but an entire certificate chain. A chain includes the entity certificate, the certificate which was used to sign it, the certificate which was used to sign that certificate, and so on.
Best practice for a CA is to sign entity certificates not with a root certificate but with an intermediate. CAs can have multiple intermediates, and multiple levels of intermediate (one intermediate signed by the root, then another intermediate signed by the first, which is then used to sign entity certificates). There are a number of reasons for this, mostly related to CA security and reducing the impact of a CA compromise.
Because clients might not always have all the intermediates available – they might only have the root as a trust anchor – applicable standards require the server send a chain including at least the entity certificate and any intermediates needed to reach the root.
Sending the root itself is optional. PKIX and the CA/BF Baseline Requirements do not address the question, except for PKIX noting that trust anchors (including roots) should be delivered using a trusted out-of-band mechanism. But this does not mean the server should not send the root regardless. RFC 6066 (TLS Extensions) and RFC 8446 (TLSv1.3) both say that the chain can omit the root. Clients must not automatically trust an unrecognized root, but could prompt the user; and having the root in the server's chain can be useful for problem determination. Including the root does increase the size of the TLS handshake – certificates can be a few kilobytes in size on the wire – so there is a small performance penalty.
With Enterprise Server, a listener can send a chain rather than a single certificate by including all the necessary certificates in a single file, and then configuring that as the certificate file. The PEM and PKCS#12 (or PFX) file formats can hold multiple certificates. For PEM, simply concatenate the certificate files into one file. For PKCS#12, a tool such as the OpenSSL utility can be used to construct a file containing multiple certificates.