Meta: this isn't really a programming or development question. Plus I'm pretty sure it's partly duplicate because I remember writing most of this answer before, but I can't find it now; if I do later I will add.
First, to be clear, changing the port in a Tomcat <Connector> doesn't enable SSL/TLS (HTTPS). Enabling SSL/TLS requires changing several other attributes and (usually) elements in the <Connector>, and does NOT require changing the port, although you often (probably usually) do change both together.
Also, you need the intermediate cert(s) for a proper SSL/TLS server but you don't need the root cert. All SSL/TLS standards explicitly allow the server to omit the root cert from the chain transmitted in the handshake, most non-Java servers do so, and all clients I have ever seen accept it. The Java KeyStore capability was designed to support multiple applications and not just SSL/TLS, so to be safe keytool encourages you to include the root, but with other tools like OpenSSL it's easy to omit it. OTOH if you want for some reason to include it, that's permitted and does work.
(To be pedantic, it's actually the (trust) anchor not the root. Traditionally the anchor was expected to be the root, but over time it has developed that it might not. RFC8446 for TLS1.3 in 2018 is the first SSL/TLS specification to reflect this, and even there it's extremely rare, so I will ignore it.)
Answer: to include chain and/or root cert(s) in a PKCS12 file created with OpenSSL commandline, there are two approaches:
manually determine the correct/desired cert(s) and supply them in either the -in option (which defaults to stdin, which in turn can be piped from e.g. cat) or -certfile (specifying a file containing one or more cert PEM blocks)
specify -chain and provide in the working truststore at least the correct cert(s). OpenSSL will automatically select the cert(s) that chain from the leaf cert, ignoring any others.
As with nearly all commandline operations, the working truststore can consist of -CAfile which is a file (only one) containing any number of cert PEM blocks; or -CApath which is a directory containing any number of files each containing one cert PEM block and with a name (or symlink) based on the subject hash, as described in the man page for c_rehash(1) on your system ((1ssl) or similar on some) or on the web; or both.
If -CAfile -CApath are not specified, and not suppressed by -no-CAfile -no-CApath (in 1.1.0 up only), they default to a file and directory configured at compile time, but upstream does not supply any contents for such a file and/or directory. Linux distros I am familiar with all build OpenSSL to use locations in /etc somewhere (but they vary as to where) and have a package named something like ca-certificates that provides default contents for the default truststore location(s), and may provide a way to change those contents. For example on RedHat-family see update-ca-trust and on Debian-family see update-ca-certificates.
Alternative: for Tomcat 9 (and 8.5) you don't need a keystore. Older versions of Tomcat required you to match the SSL/TLS implementation to the configuration: Java (JSSE) required a Java keystore while 'tcnative' (aka APR = Apache Portable Runtime) required OpenSSL-style PEM files. Modern Tomcat allows you to use either type of configuration with any SSL/TLS implementation, so you can simply use mykey.key mycert.crt intermediate.crt in the <Connector> or better the now-preferred <SSLHostConfig> and <Certificate> sub-elements; see http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support . If you are going by http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html be warned that hasn't been kept up to date and a number of details in it are wrong, although the basic ideas are mostly still valid.
