Transport Layer Security (TLS)

Every revenexx endpoint is HTTPS-only on TLS 1.2 or 1.3. Certificates for your domains are issued and renewed automatically.

Every revenexx endpoint is HTTPS-only. There is no plaintext HTTP endpoint to call, nothing to enable, and no certificate for you to install — use https:// and you are done.

This page is what to expect if you have to answer a security review, and what to check when a handshake fails.

What is accepted

Protocol versionsTLS 1.2 and TLS 1.3
RejectedTLS 1.1, TLS 1.0, SSLv3 and below — the connection is refused, not downgraded
Key exchangeECDHE, so every session has forward secrecy
CiphersAEAD suites only (AES-GCM, ChaCha20-Poly1305)
Certificate authorityLet's Encrypt

TLS 1.3 is negotiated with any client that offers it. TLS 1.2 remains accepted for clients that cannot do 1.3 — an older Java or .NET runtime, an embedded HTTP stack in an ERP. If your client fails to connect at all, the version it offers is the first thing to check: anything below 1.2 will not be served.

TLS sits above the transport layer, not at it. It runs on top of an established TCP connection and encrypts the application data carried over it — which is why a TLS problem shows up as a failed handshake rather than a failed connection, and why the hostname you request matters (the certificate is selected by SNI).

Where the handshake terminates

Which machine completes the handshake depends on the hostname, and it follows the edge topology:

  • A domain you have pointed at the edge — your storefront, your /cdn/ asset paths — terminates at the nearest point of presence. The handshake completes close to the client, which is where most of the latency saving comes from.
  • api.revenexx.com terminates at the origin in Germany.

Either way the traffic is encrypted end to end from the client's perspective, and the leg from a point of presence to the origin is itself encrypted.

Responses from the edge carry HSTS (Strict-Transport-Security) with a long max-age. Once a browser has seen it, that browser will not attempt plaintext HTTP to your domain again.

Certificates for your domains

Certificates are issued from Let's Encrypt automatically, once a domain you added in Cockpit verifies, and renewed automatically well before expiry. You do not request, install, or rotate anything.

Two things about your zone are worth knowing, because they are the only ways this fails:

  • The ACME challenge must be reachable. Issuance and renewal use an HTTP-01 challenge over port 80 on your domain. If something in front of your domain blocks or redirects /.well-known/acme-challenge/, renewal fails — silently, until the certificate expires. Do not put a catch-all HTTP→HTTPS redirect in front of a revenexx-served domain at some other layer.
  • Pre-existing CAA records must permit Let's Encrypt. revenexx does not ask you to add a CAA record, but if your zone already publishes one — some registrars add them by default — it must allow letsencrypt.org, or issuance fails after the domain has otherwise verified correctly. A zone with no CAA records at all permits any authority, so there is nothing to do.

If a customer has a certificate they are required to use — an EV certificate, or one from an authority their security policy mandates — it can be uploaded instead. The automatic path is the default and the one to prefer.

The record to create, the verification flow, and the CAA example are in Domains.

Related

Was this page helpful?