Cloudflare SSL for SaaS: $0 Custom Domains Guide

Tragödie der manuellen B2B-Multi-Tenant-SaaS-Infrastruktur: Benutzerdefinierte Kundendomains und SSL-Ausstellung

Beim Betrieb von B2B-Enterprise-SaaS-Anwendungen wie Notion, Shopify, Vercel, Framer oder Typeform explodiert die Nachfrage von Kunden (Tenants), ihre eigenen Marken-Domains (app.customer-company.com) mit unserer SaaS-Plattform zu verbinden.

Die dafür gewöhnlich genutzte Cluster-Architektur aus AWS NGINX Reverse Proxy + Certbot (Let’s Encrypt) + AWS ACM führt jedoch bei jedem Anstieg der Kundenanzahl auf 100 oder 1.000 zu einer schwerwiegenden Infrastruktur-Verwaltungshölle und einer Kostenexplosion.

1. NGINX-Konfigurationsdateien und Speicher-Explosion: Mit jeder zusätzlichen benutzerdefinierten Kundendomain wächst der Block server { listen 443; server_name app.customer.com; ... } unendlich an, was den Speicher des NGINX-Prozesses nichtlinear aufbläht.
2. Certbot Let’s Encrypt 90-Tage-Ablauf-Ausfälle bei der Neuausstellung: Bei der Erneuerung von SSL-Zertifikaten für 1.000 Domains kommt es aufgrund von Rate-Limit-Überschreitungen oder DNS-Validierungsfehlern zu Notfällen in der Echtzeitüberwachung, da auf Kundendomains die Sicherheitswarnung NET::ERR_CERT_DATE_INVALID erscheint.
3. Rechnungen für AWS Load Balancer & NGINX EC2 Server: Monatliche Kosten von $300 bis $1.500 für Zielgruppen-Gebühren von Load Balancern (ALB) zur Verarbeitung von SSL-Handshakes und Serverkosten für EC2-Lastverteilungscluster.

[Kosten- und manuelle Verwaltungs-Tragödie benutzerdefinierter B2B-Multi-Tenant-SaaS-Domains]
Kundendomain (app.customer.com) -> AWS NGINX Certbot-Cluster ($650/Monat Verwaltungskosten) -> SSL-Ablauf-Ausfälle
                                     * Manuelle Bearbeitung von NGINX-Dateien & Überwachung der 90-Tage-Erneuerung erforderlich!

Die Edge-Architektur, die diese manuelle Infrastruktur-Fehlerquelle im Zeitraum 2025/2026 vollständig beseitigt hat, ist die Pipeline aus Cloudflare Custom Hostnames (SSL for SaaS) & Workers Fallback Origin.

Sobald der Kunde einen CNAME-Record seiner eigenen Domain auf unseren Fallback-Origin-Worker (fallback.my-saas.com) richtet, stellt die Cloudflare-API innerhalb von 5 Sekunden automatisch Let’s Encrypt / Google Trust Services TLS-Zertifikate an der Edge aus und bedient die Anfragen mit $0 SSL-Verwaltungsgebühren perfekt.

In diesem Leitfaden behandeln wir im Detail die Mechanismen von Cloudflare SSL for SaaS, den Aufbau des Fallback-Origin-Workers, die automatische Ausstellung über die Custom Hostnames REST API, die dynamische Mandantenbindung (Tenant-Binding) mittels custom_metadata sowie umfassende Benchmarks.

Cloudflare Custom Hostnames (SSL for SaaS) Hybrid-Architektur

Kunden müssen lediglich eine einzige CNAME-Zeile hinzufügen; Cloudflare Edge-Knoten übernehmen den TLS-Handshake und das Tenant-Routing vollständig automatisch.

+-----------------------------------------------------------------------------------+
| Cloudflare Custom Hostnames (SSL for SaaS) Multi-Tenant-Routing-Pipeline          |
+-----------------------------------------------------------------------------------+

[Kundendomain: app.customer-company.com (CNAME -> fallback.my-saas.com)]
                                       |
                                       v
[Cloudflare Edge SNI / SSL-Handshake (Dynamische 5s-Ausstellung abgeschlossen)]
                                       |
                    [Fallback Origin Worker Edge-Laufzeit]
                                       |
       +-------------------------------+-------------------------------+
       |                                                               |
 (A) customHostnameMetadata Erkennung                          (B) Tenant-DB-Abfrage in 0.1 ms
   - tenant_id: "tenant_corp_992"                                - Kundenspezifisches Theme bereitstellen
   - custom_domain: "app.customer-company.com"                   - Datentrennung und Routing
       |                                                               |
       +-------------------------------+-------------------------------+
                                       |
                                       v
                [$0 SSL-Verwaltungskosten & 100% automatisierte SaaS-Antwort]

1. Deklaration des Fallback-Origin-Workers: Registrieren Sie einen einzelnen Edge-Origin, sodass alle Anfragen von benutzerdefinierten Kundendomains bei unserem fallback.my-saas.com-Worker zusammenlaufen.
2. Dynamische Ausstellung über die Custom Hostnames API: Sobald der Kunde eine Domain im Web-Dashboard eingibt, stellt die Cloudflare-API direkt an der Edge innerhalb von 5 Sekunden ein neues Let’s Encrypt / Google Trust Services Zertifikat aus.
3. customHostnameMetadata Edge-Erkennung: Spezifische Tenant-Kennungen (tenant_id, custom_theme) pro Kundendomain werden zum Zeitpunkt des Cloudflare TLS-Handshakes in den Worker injiziert (c.req.raw.cf?.customHostnameMetadata), wodurch eine 0ms-Multi-Tenant-Verzweigung ohne NGINX-Neustart erreicht wird.

Schritt 1: Implementierung des APIs für die dynamische Registrierung benutzerdefinierter Hostnames (src/custom_domain_service.ts)

Implementieren Sie eine Route, die beim Registrieren einer Domain im Dashboard unserer SaaS-App die Cloudflare REST API aufruft, um automatisch ein SSL-Zertifikat sowie die CNAME-Validierung zu beantragen.

// src/custom_domain_service.ts
import { Hono } from "hono";

type Env = {
  Bindings: {
    CF_ZONE_ID: string;
    CF_API_TOKEN: string;
    FALLBACK_ORIGIN: string; // z. B. fallback.my-saas.com
  };
};

const app = new Hono<Env>();

// 1. Neuregistrierung der Kundendomain und automatische Beantragung des SSL-Zertifikats in 5s
app.post("/api/v1/domains/register", async (c) => {
  const { customDomain, tenantId, theme } = await c.req.json<{
    customDomain: string;
    tenantId: string;
    theme: string;
  }>();

  const zoneId = c.env.CF_ZONE_ID;
  const apiToken = c.env.CF_API_TOKEN;

  // Aufruf der Cloudflare Custom Hostnames REST API
  const response = await fetch(
    `https://api.cloudflare.com/client/v4/zones/${zoneId}/custom_hostnames`,
    {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${apiToken}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        hostname: customDomain,
        ssl: {
          method: "http", // Automatische HTTP- / CNAME-Authentifizierung
          type: "dv",     // Domain Validated (Let's Encrypt / Google Trust)
          settings: {
            min_tls_version: "1.2",
            http2: "on",
          },
        },
        // 2025/2026-Kernstück: Dynamische Tenant-Metadaten, die automatisch in den Edge-Worker injiziert werden
        custom_metadata: {
          tenant_id: tenantId,
          theme_mode: theme,
          created_at: new Date().toISOString(),
        },
      }),
    }
  );

  const result = await response.json();
  if (!response.ok) {
    return c.json({ error: "Failed to register custom hostname", details: result }, 400);
  }

  // 2. CNAME-Anleitung für den Kunden bereitstellen
  return c.json({
    success: true,
    customDomain: customDomain,
    cnameTarget: c.env.FALLBACK_ORIGIN,
    status: result.result.status, // pending_validation -> active
    verificationTxt: result.result.ownership_verification?.text_name,
  });
});

export default app;

Schritt 2: Fallback-Origin-Worker & Edge-Tenant-Erkennung (src/index.ts)

Erfassen Sie alle eingehenden HTTP/HTTPS-Anfragen an Kundendomains direkt an der Edge, lesen Sie customHostnameMetadata aus und stellen Sie maßgeschneiderte Dienste pro Mandant bereit.

src/index.ts

// src/index.ts
import { Hono } from "hono";
import customDomainApp from "./custom_domain_service";

type CustomMetadata = {
  tenant_id?: string;
  theme_mode?: string;
  created_at?: string;
};

const app = new Hono();

// Anbindung der API-Routen für die Domain-Registrierungsverwaltung
app.route("/", customDomainApp);

// Einstiegspunkt für Kundendomains (Fallback Origin Worker)
app.get("*", async (c) => {
  const url = new URL(c.req.url);
  const hostname = url.hostname;

  // 1. Empfang der beim TLS-Handshake vom Cloudflare Edge-Knoten injizierten benutzerdefinierten Metadaten
  const cfProps = c.req.raw.cf as unknown as {
    customHostnameMetadata?: CustomMetadata;
  };

  const metadata = cfProps?.customHostnameMetadata;
  const tenantId = metadata?.tenant_id || "default_public";
  const themeMode = metadata?.theme_mode || "light";

  // 2. 0s Suche im separaten Tenant-DB-Index! Sofortige Nutzung der Tenant-ID aus den Metadaten
  return c.html(`
    <!DOCTYPE html>
    <html lang="de">
    <head>
      <meta charset="UTF-8">
      <title>${hostname} - Multi-Tenant Enterprise SaaS</title>
      <style>
        body {
          background-color: ${themeMode === "dark" ? "#121212" : "#ffffff"};
          color: ${themeMode === "dark" ? "#ffffff" : "#000000"};
          font-family: system-ui, sans-serif;
          padding: 3rem;
        }
        .badge {
          background: #6366f1;
          color: white;
          padding: 0.25rem 0.75rem;
          border-radius: 9999px;
          font-size: 0.875rem;
        }
      </style>
    </head>
    <body>
      <span class="badge">SSL for SaaS Active</span>
      <h1>Willkommen bei ${hostname}!</h1>
      <p>Verknüpfte Tenant-ID: <strong>${tenantId}</strong></p>
      <p>Die dynamische Erstellung des SSL-Zertifikats an der Cloudflare-Edge ist abgeschlossen und wird mit $0 Gebühren perfekt bedient.</p>
    </body>
    </html>
  `);
});

export default app;

Schritt 3: 0-Sekunden-CNAME-Validierung und Webhook zur Zertifikatsstatus-Aktualisierung

Dies ist die Architektur eines Polling-/Webhook-Dienstes, der prüft, ob sich der Status nach Abschluss des DNS-CNAME-Setups durch den Kunden auf active geändert hat.

// Endpunkt zur Abfrage des Zertifikatsstatus
app.get("/api/v1/domains/status/:hostnameId", async (c) => {
  const hostnameId = c.req.param("hostnameId");
  const zoneId = c.env.CF_ZONE_ID;
  const apiToken = c.env.CF_API_TOKEN;

  const response = await fetch(
    `https://api.cloudflare.com/client/v4/zones/${zoneId}/custom_hostnames/${hostnameId}`,
    {
      headers: {
        "Authorization": `Bearer ${apiToken}`,
      },
    }
  );

  const result = await response.json();
  return c.json(result);
});

Benchmark: AWS NGINX Certbot-Cluster vs. Cloudflare SSL for SaaS

Dies ist ein Wartungs- und Kostenvergleichsbericht basierend auf einem Multi-Tenant-SaaS-Szenario mit 1.000 benutzerdefinierten Kundendomains.

Kosten- & Betriebseffizienzvergleich nach Plattform

Fazit: Das Ende komplexer B2B-Multi-Tenant-SaaS-Infrastrukturen

Quälen Sie sich nicht länger damit, manuell Domain-Konfigurationscode in NGINX-Serverdateien einzufügen und Certbot-Erneuerungsfehler zu beheben, nur um eine einzige benutzerdefinierte Domain-Anfrage eines Kunden zu bearbeiten.

Die Architektur von Cloudflare Custom Hostnames (SSL for SaaS) bietet folgenden überragenden Mehrwert:

1. $0 SSL-Infrastrukturkosten für benutzerdefinierte Domains: Reduziert monatliche Wartungskosten von NGINX-Clustern und ALB Load Balancern in Höhe von hunderten Dollar auf $0.
2. Neue TLS-Zertifikatsausstellung in 5 Sekunden: Sobald der Kunde auf den CNAME-Record verweist, erstellt der Edge-Knoten innerhalb von 5 Sekunden ein sicheres SSL-Zertifikat.
3. 0ms-Tenant-Verzweigung über customHostnameMetadata: Bedient kundenspezifische Dienste ohne DB-Abfrage in 0,1 ms unter Verwendung der beim TLS-Handshake an der Edge injizierten Tenant-ID.
4. 0 SSL-Ablauf-Ausfälle: Erneuert Zertifikate vollautomatisch auf Edge-Ebene und eliminiert Certbot Rate-Limit-Störungen bei 90-Tage-Ablaufzyklen zu 100%.

Implementieren Sie noch heute die Cloudflare SSL for SaaS & Workers Architektur in Ihr B2B-SaaS-Projekt und bauen Sie eine zu 100% automatisierte Multi-Tenant-Infrastruktur auf.

Ähnlicher Beitrag: Lesen Sie auch unseren Edge-Routing-Leitfaden unter Cloudflare Workers Assets & Dynamic Edge Routing: Ersetzen Sie Vercel für $0.