Whenever we deploy an enterprise Java Web application we should consider turning on SSL/TLS. In the case of Tomcat, that means going through the certificate issuance process with the CA of your choice, and then editing your /conf/server.xml file, and adding an SSL/TLS-enabled connector. The required configuration will look something like this:
<Connector port="8443" maxThreads="42" scheme="https" secure="true" SSLEnabled="true“ keystoreFile="/path/to/my/keystore" keystorePass="Don'tPanic!" clientAuth="false" sslProtocol="TLS"/>
However, as mentioned in my previous post, things are different in Cloud Foundry.
In the case of deploying your application to Pivotal Cloud Foundry, you don’t have the requirement to directly configure the Tomcat server.xml file. We will explain in detail why this is, but first it must be said that the whole point of deploying to the PaaS is that the developer does not need to deal with these things.
Instead, the approach is that the SSL/TLS connection from the user’s browser will terminate at the entry point to Cloud Foundry. The application itself runs inside the perimeter of the Cloud Foundry deployment. In my case, this is behind the HA Proxy server instance that serves as the front door for all the applications that are running in the cloud. To understand this, let’s take a look at the way a typical enterprise application URL is remapped when it is deployed to the cloud.
Typical Enterprise Application URL Format
When the user accesses an application that has been deployed to a standalone Tomcat instance (or a cluster) the URL typically has the form:
Thus, the X.509 certificate that is presented to the users browser authenticates the hostname of the Tomcat server that is hosting the application. The application itself is identified by the context portion of the URL, the “/myapplication” part. If you host another application on the same Tomcat server, it will likely be located at, say:
…And so on. There are likely a number of such applications on that enterprise Tomcat instance. (We should mention that it’s also possible to use different ports and virtual hosts, though that is less common with the enterprise applications deployed inside a typical data center). The key point here is that the SSL/TLS server certificate actually identifies the Tomcat server instance, and the SSL/TLS session is terminated at a port on the server that hosts the application.
Application URL Format in Pivotal Cloud Foundry
When that same enterprise application has been deployed to Pivotal Cloud Foundry, the URL will have the format:
And my other application would have the URL:
Notice how the Tomcat application context now becomes a subdomain. The user’s HTTP request for that application is routed (via the client’s DNS) — not to the Web application server — but to the entry point of Cloud Foundry. In my deployment, that is the IP address of the Cloud Foundry HA Proxy server. You can also choose to use a hardware load balancer, or another software proxy. All the applications exist on a subnet behind that designated proxy server. So the SSL/TLS session from the users browser is terminated by the proxy server, and the traffic to the application server itself (through the Cloud Foundry Router, and on through to the DEA) happens inside the perimeter of the cloud. The subject name in the SSL/TLS certificate is the cloud subdomain.
Now, don’t panic. Before we jump up and demand that the user’s SSL/TLS connection be set up end-to-end — from the browser all the way to the Tomcat server instance — we should consider that there is a precedent for this. It is actually quite common for enterprise SSL/TLS connections to be terminated at a proxy server. This may be done to leverage a dedicated host (that contains SSL/TLS accelerator hardware), or perhaps for security monitoring purposes. In fact, many enterprise security operations teams will also terminate any outbound SSL/TLS connections at an enterprise perimeter firewall such as a Blue Coat box.
The threat model here is that the entry point to the cloud is a high availability, secured proxy server. Once the traffic traverses that perimeter, it is on a trusted subnet. In fact, the actual IP address and port number where the Tomcat application server are running are not visible from outside of the cloud. The only way to get an HTTP request to that port is to go via the secure proxy. This pattern is a well established best practice amongst security architecture practitioners.
In addition, we need to keep in mind that there are additional security capabilities — such as a Warden container — that are present in the Cloud Foundry deployment, that typically don’t exist on the average enterprise Tomcat instance. (Discussing Warden containers in more detail would be out of scope for this post, but I’ll be sure to revisit this topic — along with Docker — in a future post).
So, now, let’s finally take a look at how the administrator will configure that SSL/TLS certificate in Pivotal Cloud Foundry.
Configuring SSL/TLS Certificate in Pivotal Cloud Foundry
Configuring the SSL/TLS certificate for Pivotal Cloud Foundry may be done using the Pivotal Operations Manager UI. From the Installation Dashboard, click on Pivotal Elastic Runtime tile, and then the settings tab, and “HA Proxy.” This makes it easy for the administrator to supply a certificate PEM file, or choose to let PCF generate the certificate for you. Below is a screen shot that shows the page.
If you happen to be are deploying your Cloud Foundry instance using the open source code, e.g. using Bosh, then the PEM certificate file for the HA proxy may be configured manually. Look in the /templates subdirectory of the haproxy job to find the configuration details. When the instance is deployed, the certificate and private key will ultimately find their way to the bosh manifest file. The PEM encoded certificate and private key are found in the manifest under “jobs”, i.e.
jobs: - name: ha_proxy template: haproxy release: cf lifecycle: service instances: 1 resource_pool: ha_proxy persistent_disk: 0 networks: - name: default static_ips: - 10.x.y.z properties: networks: apps: default ha_proxy: timeout: 300 ssl_pem: "-----BEGIN CERTIFICATE—— ....foo bar.... -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- ...foo bat... -----END RSA PRIVATE KEY-----" router: servers:
In either case — whether you are using PCF or the open source code base — it’s important to recognize that this is a task needs to be done once by the security administrator for the cloud — and not by every developer that deploys an application, or another instance of Tomcat.
Moving your enterprise application deployments into Cloud Foundry will mean that your developers will have the benefit of always having an SSL/TLS connection from their users’ browsers, to the “front door” of the cloud infrastructure, for free. One of the key benefits of a PaaS is that your busy developers do not have to waste valuable time dealing with configuration details such as provisioning server certificates, and editing their Tomcat server configurations. The developers can spend their time writing code that drives revenue for the business, and then just do “cf push <my-application>”. Dealing with the operational security of the application server infrastructure is factored out of their workday.
Finally, it’s important to note that while using Cloud Foundry makes things easy by eliminating routine configuration tasks like enabling SSL/TLS, it is still possible to customize your Tomcat server configuration, if and as needed. This would be done by creating and deploying a customized Cloud Foundry Buildpack, which contains your enterprise-specific changes. In my next post, I’ll describe a use case scenario in which a customized build pack is necessary, and we’ll describe how this is done.