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.

What's a Webhook though?

A webhook in web development is a method of augmenting or altering the behavior of a web page, or web application, with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the originating website or application.

Neat! How do you do that?

Coming soon