Ssl – Issue with SSL for Apache and Tomcat

sslssl-certificatetomcat

I have a server where it's running Apache and Tomcat.
The front end app (built in angularjs) is running in Apache, there I installed the SSL cert and it is working fine, I can access with HTTPS and the browser trust on the cert.
But then this app is consuming some services from another app that is in the SAME server but it's running with Tomcat 8 (as it's an app built in Java).

The issue is that the browser (chrome) is not allowing the site in https consume services from another server (actually it's running in the same server but it's a different app) that is not using SSL.
So I'm trying to use the same SSL that I'm using in Apache in Tomcat. BUt I cannot make it work.
As per I was reading, I neet to add the certificate to the keystore, but when I try to do that, the cert is listed as trustedCertEntry and as per the documentation is beucause I'm not using the same alias that I used to generate the private key…. But when I create the private key I didn't use a alias, so I'm not sure how to fix this…

In Summary:
One server where an app in Apache (port 80) and other app in Tomcat(port 8080) are running.
In Apache the setting is ok to use SSL
I generate the private key with:

openssl genrsa -out mydomain.key 2048 
openssl req -new -key mydomain.key -out mydomain.csr

And then I tried to add the cert to the keystore with

keytool -import -keystore mydomain -alias mydomain -file [certificate file]

But it's listed as trustedCertEntry and the tomcat is not working with HTTPS in port 8080 or 8443.

What I'm missing? Can I do this with one cert? Or do I need two even if they are on the same server?

My server.xml is

<?xml version="1.0" encoding="UTF-8"?>

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
–>

–>

<!--The connectors can use a shared executor, you can define one or more named thread pools-->
<!--
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
    maxThreads="150" minSpareThreads="4"/>
-->


<!-- A "Connector" represents an endpoint by which requests are received
     and responses are returned. Documentation at :
     Java HTTP Connector: /docs/config/http.html
     Java AJP  Connector: /docs/config/ajp.html
     APR (HTTP/AJP) Connector: /docs/apr.html
     Define a non-SSL/TLS HTTP/1.1 Connector on port 8080
-->
<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
           port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />
-->
<!-- Define a SSL/TLS HTTP/1.1 Connector on port 8443
     This connector uses the NIO implementation. The default
     SSLImplementation will depend on the presence of the APR/native
     library and the useOpenSSL attribute of the
     AprLifecycleListener.
     Either JSSE or OpenSSL style configuration may be used regardless of
     the SSLImplementation selected. JSSE style configuration is used below.
-->

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" SSLEnabled="true">
    <SSLHostConfig>
        <Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
                     type="RSA" />
    </SSLHostConfig>
</Connector>

<!-- Define a SSL/TLS HTTP/1.1 Connector on port 8443 with HTTP/2
     This connector uses the APR/native implementation which always uses
     OpenSSL for TLS.
     Either JSSE or OpenSSL style configuration may be used. OpenSSL style
     configuration is used below.
-->

<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol"
           maxThreads="150" SSLEnabled="true" >
    <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
    <SSLHostConfig>
        <Certificate certificateKeyFile="conf/localhost-rsa-key.pem"
                     certificateFile="conf/localhost-rsa-cert.pem"
                     certificateChainFile="conf/localhost-rsa-chain.pem"
                     type="RSA" />
    </SSLHostConfig>
</Connector>

<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />


<!-- An Engine represents the entry point (within Catalina) that processes
     every request.  The Engine implementation for Tomcat stand alone
     analyzes the HTTP headers included with the request, and passes them
     on to the appropriate Host (virtual host).
     Documentation at /docs/config/engine.html -->

<!-- You should set jvmRoute to support load-balancing via AJP ie :
<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
-->
<Engine name="Catalina" defaultHost="localhost">

  <!--For clustering, please take a look at documentation at:
      /docs/cluster-howto.html  (simple how to)
      /docs/config/cluster.html (reference documentation) -->
  <!--
  <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
  -->

  <!-- Use the LockOutRealm to prevent attempts to guess user passwords
       via a brute-force attack -->
  <Realm className="org.apache.catalina.realm.LockOutRealm">
    <!-- This Realm uses the UserDatabase configured in the global JNDI
         resources under the key "UserDatabase".  Any edits
         that are performed against this UserDatabase are immediately
         available for use by the Realm.  -->
    <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
           resourceName="UserDatabase"/>
  </Realm>

  <Host name="localhost"  appBase="webapps"
        unpackWARs="true" autoDeploy="true">

    <!-- SingleSignOn valve, share authentication between web applications
         Documentation at: /docs/config/valve.html -->
    <!--
    <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
    -->

    <!-- Access log processes all example.
         Documentation at: /docs/config/valve.html
         Note: The pattern used is equivalent to using pattern="common" -->
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
           prefix="localhost_access_log" suffix=".txt"
           pattern="%h %l %u %t &quot;%r&quot; %s %b" />

  </Host>
</Engine>

Best Answer

Browsers can be a bit funny about ssl sites containing unsecure content. If you've got SSL working on Apache you could use Apache as a reverse proxy to publish the Tomcat app, either using an ajp connector or reverse proxy. That way you don't have to worry about SSL on Tomcat at all, its all taken care of on the Apache server (the connection between tomcat and apache is not secure, but that should be on a private network anyway). All the necessary docs are on from apache:

Tomcat AJP reference

Configuring the AJP connector on Apache

Or you can use a simple reverse proxy

The tomcat AJP docs aren't particularly clear - just edit the conf/server.xml file, and uncomment/include the following bit to make tomcat accept ajp requests:

<Service name="Catalina">
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
...

Related Solutions

Ssl – Control SSL Cipher Priority/Order for Tomcat to avoid BEAST attack

I have the same issue. It seems that we can't do what we want.
The Sun(Oracle) Java SSL implementation checks only the client side cipher suite order(priorities) and ignores the server side.

Related classes are:
sun.security.ssl.ServerHandshaker
sun.security.ssl.CipherSuite

On ServerHandshaker,
"private void chooseCipherSuite(ClientHello mesg)"
http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-sun/security/sun/security/ssl/ServerHandshaker.java.htm

/*
 * Choose cipher suite from among those supported by client. Sets
 * the cipherSuite and keyExchange variables.
 */
private void chooseCipherSuite(ClientHello mesg) throws IOException {
    for (CipherSuite suite : mesg.getCipherSuites().collection()) {
        if (isEnabled(suite) == false) {
            continue;
        }
        if (doClientAuth == SSLEngineImpl.clauth_required) {
            if ((suite.keyExchange == K_DH_ANON) || (suite.keyExchange == K_ECDH_ANON)) {
                continue;
            }
        }
        if (trySetCipherSuite(suite) == false) {
            continue;
        }
        return;
    }
    fatalSE(Alerts.alert_handshake_failure,
                "no cipher suites in common");
}

We can see that it itelates cipher suites in the client hello message and chooses cipher suite.

Tomcat – Apache / Tomcat port information

Ok, I'll try answering you.

Consider Apache HTTPD and Apache Tomcat two friends (I'll call them in short HTTPD and Tomcat). Each of them has means of comunicating with other people, let's say by mobile phone and lineland phone or IM.

Tomcat has three phones for recieving calls:

One for recieving international calls in which he speaks the langauage spoken by most people in the (informatic) world, HTTP. This phone has an international agreed subnumber (port) which is 80, but can be any number. It happens that Tomcat being a bit eccentric preferes 8080 by default, so you can speak him HTTP at port 8080 by default.
Another phone for recieving calls from international VIP people, which want to be ultra sure they are speaking with Tomcat and nobody can listen their call, so they speak the previous international language but switching words (encryption, HTTPS). By international agreements this port is 443, but as we said Tomcat is eccentric, he chooses for this port 8443.
The third Tomcat's phone he uses it to recieve calls only from people that speak his own language, AJP (He lives in Java Application Server Country). By International Common Law, it's port 8009.

HTTPD has only two phones for recieving calls

The first two are the same as for Tomcat but HTTPD is not that eccentric prefering to use the normal agreed numbers, 80 for HTTP and 443 for HTTPS.

The story

Now HTTPD has a shop. Sometimes costumers ask for stuff not present in the shop but when he knows Tomcat has it he calls Tomcat and asks him to bring the things.For speaking with Tomcat HTTPD can use international languages, HTTP and HTTPS, but often Tomcat is more happy to speak his own language, AJP. So HTTPD knows that there are two translators that can help him speak AJP with Tomcat, mod_jk (http://tomcat.apache.org/connectors-doc/) and mod_proxy_ajp (https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html).

Now being more serious, by default, HTTPD listens on ports 80 for HTTP and port 443 for HTTPS.

Tomcat listens on port 8080 for HTTP, port 8443 for https and port 8009 for AJP.

You can configure the ports for HTTPS using Listen directives in it's configuration file, httpd.conf or files included from it. So grep for Listen to check them.

You can configure Tomcat for the ports in server.xml. In Tomcat language those are connectors (as opposed to Listen in HTTPD). And as for your configuration, if you setup Tomcat to use HTTPS he will redirect requests in HTTP to the port configured.

Keep in mind, HTTPD keeps care of his ports, Tomcat of his own ports and a port can be in listen only from a single application at a time. So if you have both HTTPD and Tomcat in the same machine, they fit nicely, as the ports used are different by default:

HTTPD: Ports 80 and 443

Tomcat: Ports 8080 8443 and 8009.

Best Answer

Related Solutions

Ssl – Control SSL Cipher Priority/Order for Tomcat to avoid BEAST attack

Tomcat – Apache / Tomcat port information

Related Topic