Tomcat often sits behind an HTTP server such as Apache, which serves static content and proxies requests for dynamic content to Tomcat. Another popular option is to use squid as a reverse proxy. If for any reason you want Tomcat to serve all HTTP requests, you need it to listen on port 80 (and possibly 443). However, only the superuser can bind to TCP ports below 1024 on Linux, so making Tomcat listen on port 80 requires some extra work.
The easiest-to-implement solution is to simply forward incoming port 80 requests to port 8080, or whatever non-privileged port you are running Tomcat on. The Amazon Linux AMI has iptables enabled by default, but does not have any packet filtering rules defined as it apparently relies on the surrounding AWS infrastructure for security.
Check that Tomcat is running and have your browser connect to your instance without specifying a port. If you succeed, save iptables rules:
sudo/sbin/service iptables save
The rules are stored in
and applied upon iptables (re)start, e.g. if you reboot the instance.
Note: The above rule applies to all packets arriving from outside to any network interface. If you are running any applications on the same instance that need to talk to Tomcat on the HTTP port, you need to add another rule.
Finally, you need the servlets inside your Web application to act as if the incoming requests were directed to port 80. This will prevent the appearance of the non-privileged port in any URLs sent back to the client. Include the proxyPort attribute in your HTTP connector config in
When you receive your server certificate from the certificate authority (CA), it might be in a format that is not supported by IAM. Typically you receive a public certificate, one or more intermediate certificates and a root certificate. The intermediate certificates and the root certificate can come bundled in a file or as separate files. The file names may vary depending on the type of SSL certificate you purchase and the certificate authority.
To upload your certificate using AWS IAM, you need the following three files:
Private key in PEM format
The key file you generated for creating Certificate Signing Request (CSR). If the key is not in PEM format, use OpenSSL as in the following example to convert the private key to PEM format:
This is the certificate you receive from the CA. Your public certificate is the domain-specific file. Your public certificate also must be in PEM format. If it is not, use the following OpenSSL command to convert your public certificate to PEM format:
This file is a concatenation of all the intermediate certificates and the root certificate one after the other. The certificate chain lets an end user’s browser build a certificate chain to a root certificate it trusts. As a result, the browser can implicitly trust your certificate.
If you are uploading a self-signed certificate and it’s not important that browsers implicitly accept the certificate, you can skip this step and upload just the public certificate and private key.
Typically, both intermediate and root certificates are provided by a CA in a bundled file with the proper chained order. If a certificate bundle is not available or not available in the required order, you can create your own certificate chain file.
To create your own certificate chain file, include the intermediate certificates and optionally, the root certificate, one after the other without any blank lines. If you are including the root certificate, your certificate chain must start with intermediate certificates and end with the root certificate. Use the intermediate certificates that were provided by your CA. Any intermediaries that are not involved in the chain of trust path must not be included.
Your certificate chain must be in PEM format. If it is not, use the following OpenSSL command to convert your certificate chain to PEM format: