It is now possible to force HTTPS redirection! No more .htaccess black magic, no redirection handling code… Let's have a tour of this new feature.

Forcing HTTPS on Clever Cloud

Let's start practical. There are two ways to achieve our goal.

Using the CLI

In your linked application, in your own terminal just type in clever config set force-https enabled.

clever config is a new CLI command that allows you to display in your console the current configuration of your application. You can edit any setting with clever config set {name} {value} and bulk edit with clever config update [options].

Here we just set the force https option to enabled and if we want to set if off we can just clever config set force-https disabled.

If this does not work for you, make sure you are running version 2.5.0 or newer (with clever version).

Using the Clever Cloud console

In the information page of each application, you will find a checkbox form with options you can tune in and out. One of them is Force HTTPS. Enable its checkbox and save.

From now on and as long as you do not disable it, every non-secured HTTP request to this application will be redirected to HTTPS with a 301 Moved Permanently status code.

How the magic happens

The Clever Cloud way

The redirection is handled at the reverse proxy level so you don't need to update your application to use it. Each time the browser will request a resource using HTTP, it will get a 301 response back with the same resource prefixed by https in the Location header field. The 301 redirection is recognized as the best practice for HTTPS upgrade.

Why enforce HTTPS

Before explaining why it is important, I shall provide a definition of HTTPS.

Simple definition

First of all, HTTPS is an extension of the HTTP protocol. Which itself is the application protocol the world wide web is relying on for communications. Full definition to be found on wikipedia.

The main difference between HTTP and HTTPS communication is encryption.

Using HTTPS, the communication is bidirectionaly encrypted between the client and the server. Both the headers and the response/request data are ciphered. This is achieved using TLS cryptographic protocol in addition to operations involved in a simple HTTP transmission.

The identification process requires the server administrator to create a public key certificate signed by a trusted certificate authority.

We have automated this part. So every time you create a new application on Clever Cloud, a cleverapps.io subdomain name is given to your application and comes along with encryption because a certificate covers cleverapps.io and all its subdomains. And each time you add a custom domain to your application like example.com, Clever Cloud asks Let's Encrypt for a TLS public key certificate that we automatically add to your application's configuration on our reverse proxies. Thanks to that, you can accept HTTPS requests on a brand new application without further configuration.

Enforcing HTTPS is just the beginning

I explained to you how HTTPS enforcing was working on Clever Cloud and that felt very simple, right?

To be honest this is because the tech team has decided only to handle the first step of the process.

Strong security on an application requires knowledge on many topics.

Sometimes, your application itself will link to HTTP content, which will result in mixed-content. When HTTP resources are served by the application on a page requested using HTTPS the browser will usually not load those resources.

You will also probably want to know more about HTTP Strict Transport Security (HSTS), and the Content-Security-Policy header.

You can start by reading this great article from Scott Helme to start your journey. If you cannot handle advanced security yourself, think about asking for the help of a security expert.

HTTPS is good for everyone, except hackers

In 2020 the HTTPS protocol is ubiquitous. It's more and more widely used thanks to the Let's Encrypt initiative which made it free for everyone; which makes the web more secure for both applications creators and clients.

The clients know they can trust the integrity of the content that's being displayed to them and feel safer about using the Internet in general. This safety feeling extends to their privacy. Today the regular user's main concern is about what the owner of the website do with their data. Not about that black hooded bad guy they were freaking out about a few years ago. The most used websites have raised their confidence about communications ciphering to such a level it's now the norm. Everyone puts credit-card numbers in forms eyes wide shut.

Yeah, but me ? Having a website to offer to the world, I want to meet my client’s expectations, of course. But HTTPS has more to offer me. From the SEO perspective, having it will naturally boost ranking. I also ensure my user's privacy and confidentiality. Most importantly, I can trust that the data I receive from my client has not been altered. That doesn’t mean that I shall trust my user intentions obviously. But now if I need to watch out for a hacker, it will not come from a man in the middle or this kind of attack.

Anyway, this is everywhere now and already almost mandatory. Take this train now! This feature is free, does not require extra code and works out of the box with the automatically generated Let's Encrypt certificates.

We have been issuing and automatically installing Let's Encrypt® certificates for a while now. The only manual thing was the trigger of this process. But today, we are glad to announce fully automated Let's Encrypt certificates for everyone!

When you add a domain — which targets Clever Cloud — to an application; it will have its own certificate a few minutes later (up to 12 minutes later).

This has been live since 2018-11-16. Hundreds of certificates have been issued since then. This has been possible thanks to Let's Encrypt, who also extended their rate limiting on their API.

How do we do this?

As explained in the previous blog post, queries to the path used by Let's Encrypt to check the ownership of the domain are routed to our Let's Encrypt integration service. This allows us to process the Let's Encrypt queries, get the certificate and give it to our certificates manager.

Here is what's new. Once a user adds a new domain, we periodically check that we can reach our Let's Encrypt integration service. When we do, we start the usual process et voilà.

What if I want another kind of certificate?

That's not a problem:

If you already have a certificate, we will not create a Let's Encrypt certificate.

How about existing domains?

Existing domains which do not yet have a certificate will all get a Let's Encrypt certificate.

This will be done over the next weeks to come. We can't do this in a single batch for two reasons:

• Let's Encrypt rate limiting (we have extended limits but we still cannot send such a big batch all at once)
• We need to spread this out so that we don't have a big batch of renewals every 3 months

If you don't want to wait, you can simply ask us to enable it.

Next steps

There are a few things yet to come:

• Interface in the console to track the status of the certificates
• Support of wildcard certificates (which will not be quite as automatic because it requires DNS validation; this will require an action from you at first)

One last thing

We are now proud sponsors of Let's Encrypt!

We have been working on Let's Encrypt support for quite some time now.

We have a working prototype used for hundreds of domains and it has been running since August 2017 and has handled thousands of renewals without a single hiccup.

To go further, we need to make a small change to the way we route incoming requests.

How does Let's Encrypt work?

Let's Encrypt needs to validate the ownership of a domain before delivering a certificate. As does any public certificate authority.

For our Let's Encrypt integration, we are using the HTTP challenge to validate that we own the web server that a domain points to.

Here is how the HTTP challenge works, basically:

• The client asks for a certificate for a domain (with a CSR)
• Let's Encrypt responds with a challenge id and a token
• The client sets up this token to be sent when receving a request on http://domain.tld/.well-known/acme-challenge/<the challenge id>
• The client tells Let's Encrypt that it's ready
• Let's Encrypt makes the request to http://domain.tld/.well-known/acme-challenge/<the challenge id>
• If the challenge is validated, it will then reply to the client with the certificate

How does Clever Cloud implement this?

What we have been doing since last August is routing the /.well-known/acme-challenge to our Let's Encrypt integration service when a customer asks us to.

Sadly, this means that we have a bunch of rules in our reverse proxies to handle this. As the list of domains grow, it's becoming quite clear that this is simply not technically feasible. This huge list of rules is adding a lot of work to HAProxy's configuration parsing.

As we have hundreds of configuration changes per minute (batched together, but still), this has too much of an impact on the performance of our reverse proxies and the feature is not even released yet!

What changes

Starting today, all requests starting with the path /.well-known/acme-challenge will be sent to our Let's Encrypt integration.

This can be disabled on dedicated reverse proxies for our Premium customers only.

When will this feature be available in the console?

Right now, we only enable this on demand, domain per domain.

The goal, obviously, is to have an interface for this in the console and in clever-tools.

We still have ways to go, but the current target is by the end of this year.

Clever Cloud is designed to let you code and create wonderful applications able to enable a cool and interactive social life.

You want to create a Facebook app? To interact with the Foursquare API? Or just to manage some critical users data?

Today, all of those services require the use of SSL (https) to interact with their API. This can be sad if you only want a backend service or to make a test. Having a SSL certificate up & running can take a week, and it's complicated to buy.

Clever Cloud is a Comodo Reseller and decided to offer you a simple way to use security: every application on the Clever Cloud platform is able to claim a *.cleverapps.io domain name and to use SSL immediately!

Hope this feature let you test and run code from various API and services! We hope it will help many hackathons and Startup Weekend fellows!