About Let’s Encrypt

aboutletsencrypt 1

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.

Blog

À lire également

UP Program: Clever Cloud announces its fifth startup selection

With this new batch, Clever Cloud welcomes four startups to the UP Program: Sentibee, Pictaderm, Legaia and Cockpit Agriculture.
Company

Sōzu 2.0 — turning a reverse proxy into a programmable edge

Sōzu is the reverse proxy that sits in front of every application running on Clever Cloud. After eighteen months of work — first the HTTP/2 multiplexer, built on our existing kawa pivot, then almost every other layer of the proxy, and finally a long run in production on the cleverapps.io load balancers — Sōzu 2.0 is out.
Engineering

K3s vs K8s: What Are the Differences and Which One Should You Choose in 2026?

Kubernetes has become the standard for container orchestration. But depending on your infrastructure constraints (limited resources, edge computing, IoT, or large-scale enterprise clusters), the distribution you choose can radically change the operational experience. K3s and K8s (upstream Kubernetes) address different needs, even though both share the same CNCF-certified foundation.
Engineering Features