ConfigurationHTTPS and certificates

HTTPS and certificates

DevLyft issues a TLS certificate for every hostname you route to a deploy, automatically, as soon as that hostname's CNAME points at DevLyft.

How certificates are issued#

You don't upload or request certificates. When you attach a route and publish its CNAME, DevLyft issues a certificate for that hostname:

  1. You attach a route

    The hostname is added to a deploy through Routes → Attach route. See Routes and path prefixes.

  2. You publish the CNAME

    The hostname points at its cname_target on edge.devlyft.io.

  3. DevLyft answers the challenge

    Certificates are issued with the ACME HTTP-01 challenge: the certificate authority requests a file on your hostname, and DevLyft's edge answers it. That proves you control the name.

  4. The hostname serves HTTPS

    Usually within minutes of the CNAME going live.

Until the CNAME resolves to DevLyft, the hostname won't serve HTTPS. The challenge can't be answered until your DNS points at us, so the certificate can't be issued before then.

What blocks issuance#

The CNAME isn't published yet
dig +short app.example.com returns nothing. Publish the record and wait for it to propagate. Check the target matches cname_target exactly.
Cloudflare proxy is on
A Proxied (orange cloud) record lets Cloudflare answer the challenge request itself, so it never reaches DevLyft. Set the record to DNS only (grey cloud). See Custom domains.
An apex that doesn't resolve
An apex domain (example.com) can't hold a plain CNAME. If you use ALIAS, ANAME or CNAME flattening, make sure it follows more than one hop: dig +short example.com should return an IP address.
A wildcard hostname
HTTP-01 can't issue wildcard certificates, which is why routes reject *.example.com.

Check a hostname#

Shell
# DNS: should print your cname_target, then an IP address
dig +short app.example.com

# TLS: should print the certificate's subject and issuer
curl -svI https://app.example.com 2>&1 | grep -E 'subject:|issuer:'

Stability#

A hostname's CNAME target is derived from the hostname alone. It isn't tied to a deploy, cluster, machine or region, so moving a deploy between clusters, rebuilding it or replacing the machine underneath doesn't touch your DNS, and the hostname keeps working.