Domain Names and SSL in the OpenShift Web Console

After launching the new lighter web console theme, we decided to add a few more killer features to OpenShift’s web interface!

The web console now allows you to configure your application’s hostname, and set up secure access to custom domains through a new SSL certificate configuration area.

Grab your own domain name and an OpenShift Online account with at least one application, and get ready see how easy the new web-based domain configuration process is.

I’ll be using my recent restify+postGIS+parks mapping application as the example application in this post.

Configuring Domain Aliases in the OpenShift Web Console

First, open your OpenShift web console, and select the app that you would like to modify.

On the application’s settings page, there should be a “change” link next to your initial OpenShift-provided hostname:

Change your application's domain name

Clicking this link will open up the new hostname configuration page:

Configure OpenShift to field requests addressed to your domain

Here you can enter the domain name that you would like to associate with your application. I’ve decided to make my parks application available at “http://parks.ryanjarvinen.com/“.

Configuring your application to be available on a subdomain is generally easier. We’ll see why in the next section.

Click “Save“, at the bottom of the page when you’re ready to save your settings.

You should see a notification message if the host alias was configured successfully:

OpenShift console domain configuration success message

Additional host aliases can be added as needed.

Configuring your DNS Host Records

OpenShift takes advantage of CNAME records to route requests to your application instance.

CNAME records are nice because they can defer to OpenShift’s DNS system for IP address resolution (which isn’t garanteed to be static in OpenShift Online). However, CNAME records can also come with a few hidden limitations:

  1. Not all Domain registrars allow you to set your base host name as a CNAME (“www.foo.com” is allowed, while “foo.com” may not be).
  2. If your registrar does allow you to configure a root-level CNAME record, then all additional Host records will like be limited to the CNAME record type as well. This means that you would not be able to configure MX records on any host that uses a CNAME for it’s root host record (“@“).

The simplest solution is to make your app available on a subdomain, as in my example (“http://parks.ryanjarvinen.com/“). This configuration is supported by all domain registrars, and it doesn’t limit your ability to set up an external mail provider.

Here is a screenshot of my “parks.ryanjarvinen.com” subdomain being tied to the Red Hat-hosted “parks-shifter.rhcloud.com“:

CNAMES and subdomains

Remember: when in doubt, check your domain registrar’s support documents for DNS Host record configuration assistance

Shortly after adding the CNAME record, I was able to connect to my application via the new hostname URL:
custom domain name in effect!

Advanced Host Record Configuration

If your Domain registrar allows root-level CNAMEs, and if you are absolutely sure that you do not need support for MX records (email), or other record types – then you should be able to make your application available on your root domain by setting your primary Host record’s Hostname to @.

Another advanced configuration option involves creating an “A” Host record at the root level of your domain that points to the IP address of another machine which is responsible for issuing redirects. Some DNS providers even offer services to help issue these redirects, or even workflows to assist developers in configuring the related DNS Host records.

My registrar provided a redirect that automatically prepend a “www.” before the host address, allowing me to handle requests which were initially targeted for the base domain via the www subdomain, without introducing any additional DNS configuration limitations. MX records are still supported in this configuration, and the need for root-level CNAMEs is avoided.

Support for SSL

OpenShift includes support for Server Name Identification, which improves support for TLS by sending your OpenShift-configured domain alias as a part of the handshake.

You can always take advantage of our *.rhcloud.com wildcard certificate in order to securely connect to any application via it’s original, OpenShift-provided hostname URL.

Support for enabling HTTPS connections to custom, aliased hostnames is available for users of OpenShift Online’s Bronze and Silver plans.

If you are still getting by on OpenShift Online’s generous Free plan, you’ll see the following warning message at the top of your application’s SSL configuration area. Upgrading to the $0/month Bronze plan adds support for providing your own SSL cert:

After saving, you should be able to make HTTPS-based connections to your hosted application on your custom domain.

Updated command line tools

The latest rhc command-line utility also includes support for configuring domain names and SSL. To update to the latest version of rhc, type sudo gem update rhc (or gem update rhc).

If your copy of rhc is up to date, then you should be able to run rhc help alias to read the command-line usage notes.

Next Steps

Categories
OpenShift Online, OpenShift Origin
Tags
, , , , , , ,
Comments are closed.