Was ist das HTTPS-Protokoll und wie funktioniert es

HTTPS (HyperText Transfer Protocol Secure) ist die verschlüsselte Version von HTTP und kombiniert das Standard-Webübertragungsprotokoll mit TLS (Transport Layer Security), um einen authentifizierten, verschlüsselten Kanal zwischen einem Client-Browser und einem Webserver zu schaffen. Jedes Byte an Daten, das über HTTPS übertragen wird, ist kryptografisch geschützt, was bedeutet, dass weder passive Lauscher noch aktive Man-in-the-Middle-Angreifer die Nutzdaten während der Übertragung lesen oder unbemerkt verändern können.

In der Praxis: Wenn ein Browser eine Verbindung zu https://example.com herstellt, führt er zunächst einen TLS-Handshake durch, der die Identität des Servers über ein signiertes Zertifikat authentifiziert, eine Cipher Suite aushandelt und symmetrische Sitzungsschlüssel ableitet – alles bevor ein einziges Byte an Anwendungsdaten ausgetauscht wird. Erst nachdem dieser Handshake erfolgreich abgeschlossen ist, wird die HTTP-Anfrage vollständig verschlüsselt über die Leitung übertragen.

HTTP vs. HTTPS: Ein direkter Vergleich

Der TLS-Handshake im Detail

Das Verständnis des Handshakes ist die Grundlage für die Diagnose von Zertifikatsfehlern, die Optimierung der Serverleistung und die Härtung von Sicherheitskonfigurationen. Der Prozess unterscheidet sich leicht zwischen TLS 1.2 und TLS 1.3 – und der Unterschied ist operativ relevant.

TLS 1.2 Handshake (Legacy)

1. ClientHello — Der Browser sendet unterstützte Cipher Suites, die TLS-Version und einen zufälligen Nonce (client_random).
2. ServerHello — Der Server wählt eine Cipher Suite aus und sendet seinen eigenen Nonce (server_random).
3. Certificate — Der Server übermittelt seine X.509-Zertifikatskette, damit der Browser sie gegen seinen vertrauenswürdigen CA-Speicher validieren kann.
4. ServerKeyExchange — Bei ephemerem Diffie-Hellman (ECDHE) sendet der Server seine DH-Parameter, signiert mit seinem privaten Schlüssel.
5. ClientKeyExchange — Der Browser generiert ein Pre-Master-Secret, verschlüsselt es mit dem öffentlichen Schlüssel des Servers (RSA) oder berechnet ein gemeinsames DH-Secret (ECDHE) und sendet es.
6. ChangeCipherSpec / Finished — Beide Seiten leiten Sitzungsschlüssel aus client_random, server_random und dem Pre-Master-Secret ab und bestätigen dies mit einer Finished-Nachricht.

Gesamte Round Trips vor der Datenübertragung: 2 RTT.

TLS 1.3 Handshake (Aktueller Standard)

TLS 1.3, standardisiert in RFC 8446, eliminiert mehrere veraltete Mechanismen und reduziert die Latenz erheblich:

1. ClientHello — Der Browser enthält sofort seinen Key Share (ECDHE-Public-Value) zusammen mit den unterstützten Cipher Suites. Ein RSA-Schlüsselaustausch ist nicht zulässig.
2. ServerHello + EncryptedExtensions + Certificate + CertificateVerify + Finished — Der Server antwortet in einem einzigen Durchlauf und verschlüsselt bereits Extensions und sein Zertifikat mit einem abgeleiteten Handshake-Schlüssel.
3. Client Finished — Der Browser verifiziert das Serverzertifikat und sendet seine Finished-Nachricht. Anwendungsdaten können unmittelbar danach fließen.

Gesamte Round Trips vor der Datenübertragung: 1 RTT. Mit 0-RTT-Wiederaufnahme (Session Tickets) können wiederkehrende Besucher bereits beim ersten Paket Daten senden – obwohl dies Replay-Angriff-Überlegungen einführt, die eine sorgfältige serverseitige Behandlung erfordern.

Wesentliche TLS 1.3-Verbesserungen gegenüber 1.2:

• RSA-Schlüsselaustausch entfernt (kein Forward-Secrecy-Risiko)
• MD5, SHA-1, RC4, DES, 3DES entfernt
• Obligatorische Forward Secrecy über ECDHE
• Verschlüsselte Zertifikatsübertragung (reduziert Metadaten-Lecks)
• Schnellerer Handshake reduziert die Seitenladezeit bei Verbindungen mit hoher Latenz messbar

Zertifikatstypen und was sie tatsächlich schützen

Nicht alle SSL/TLS-Zertifikate sind gleichwertig. Die Wahl des falschen Typs ist ein häufiger operativer Fehler.

Domain Validation (DV)

Wird innerhalb von Minuten durch automatisierte Systeme ausgestellt (z. B. Let’s Encrypt). Beweist, dass der Zertifikatsinhaber die DNS- oder den Webserver der Domain kontrolliert. Bietet vollständige Verschlüsselung, aber keinerlei Identitätsverifizierung der Organisation hinter der Domain. Geeignet für Blogs, persönliche Projekte und interne Tools.

Organization Validation (OV)

Die CA überprüft manuell die rechtliche Existenz der Organisation. Das Zertifikat enthält den Firmennamen. Geeignet für Unternehmenswebsites und SaaS-Plattformen, bei denen Markenvertrauen wichtig ist.

Extended Validation (EV)

Der strengste Prüfprozess. Historisch wurde in Browsern eine grüne Adressleiste mit dem Firmennamen angezeigt; moderne Browser haben diese visuelle Unterscheidung reduziert, aber EV-Zertifikate enthalten weiterhin verifizierte Informationen zur juristischen Person im Zertifikat selbst. Geeignet für Finanzinstitute und hochwertigen E-Commerce.

Wildcard-Zertifikate

Ein einzelnes Zertifikat deckt eine Domain und alle ihre Subdomains der ersten Ebene ab (*.example.com). Wichtiger Vorbehalt: Ein Wildcard deckt keine Subdomains der zweiten Ebene ab (*.sub.example.com erfordert ein separates Wildcard). Die Kompromittierung eines Wildcard-Private-Keys legt alle Subdomains gleichzeitig offen – ein erheblicher Schadensradius.

Multi-Domain (SAN)-Zertifikate

Subject Alternative Names (SANs) ermöglichen es einem einzelnen Zertifikat, mehrere verschiedene Domains abzudecken (example.com, example.net, shop.example.org). Ideal für Hosting-Umgebungen, die mehrere Domains von einem Server aus verwalten.

Warum HTTPS im Jahr 2025 unverzichtbar ist

Verschlüsselung sensibler Daten

Ohne TLS durchquert jedes Paket zwischen einem Benutzer und Ihrem Server potenziell feindliche Netzwerkinfrastruktur – öffentliche WLAN-Zugangspunkte, transparente ISP-Proxys und BGP-gekaperte Routen. Anmeldedaten, Sitzungstoken, Zahlungsdaten und Formulareingaben sind alle im Klartext und können trivial mit Tools wie Wireshark abgefangen werden. HTTPS eliminiert diese Angriffsfläche vollständig.

Authentifizierte Serveridentität

Die Zertifikatskette des Vertrauens verhindert, dass DNS-Spoofing- und ARP-Poisoning-Angriffe Benutzer unbemerkt auf einen betrügerischen Server umleiten. Wenn ein Browser ein Zertifikat validiert, bestätigt er drei Dinge: Das Zertifikat wurde von einer CA in seinem vertrauenswürdigen Speicher signiert, der Domainname stimmt mit den CN- oder SAN-Feldern des Zertifikats überein, und das Zertifikat ist weder abgelaufen noch widerrufen (geprüft über OCSP oder CRL).

Datenintegrität durch AEAD-Ciphers

Moderne TLS-Cipher-Suites verwenden Authenticated Encryption with Associated Data (AEAD) – insbesondere AES-256-GCM oder ChaCha20-Poly1305. Diese bieten sowohl Vertraulichkeit als auch Integrität in einem einzigen Vorgang. Jeder Bit-Flip oder Injektionsversuch während der Übertragung führt dazu, dass die MAC-Verifizierung fehlschlägt und die Verbindung sofort beendet wird. Dies verhindert Content-Injection-Angriffe, bei denen ISPs oder böswillige Vermittler Werbung, Tracking-Skripte oder Malware in HTTP-Antworten einschleusen.

SEO und Rankingsignale

Google bestätigte HTTPS 2014 als Rankingsignal und hat dessen Gewicht seitdem schrittweise erhöht. Über den direkten Rankingfaktor hinaus erhöht Chromes Warnung „Nicht sicher” auf HTTP-Seiten die Absprungrate messbar – ein Verhaltenssignal, das Rankings indirekt unterdrückt. HTTP/2 und HTTP/3 (QUIC), die erhebliche Leistungsverbesserungen bieten, erfordern TLS in allen gängigen Browser-Implementierungen. Schnellere Seiten ranken besser; HTTPS ist die Voraussetzung dafür.

HSTS und Preloading

HTTP Strict Transport Security (Strict-Transport-Security-Header) weist Browser an, alle HTTP-Verbindungen zu einer Domain für einen bestimmten max-age-Zeitraum abzulehnen, noch bevor eine Weiterleitung erfolgt. Durch die Einreichung Ihrer Domain in die HSTS-Preload-Liste wird dieses Verhalten in Browser-Binärdateien fest kodiert, wodurch das Sicherheitslücken-Fenster beim ersten Besuch vollständig eliminiert wird.

HTTPS implementieren: Eine produktionsreife Anleitung

Schritt 1: Ein SSL/TLS-Zertifikat erhalten

Let’s Encrypt (kostenlos, automatisiert) ist die Standardwahl für die meisten Deployments. Certbot ist der Referenz-ACME-Client:

sudo apt update && sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com -d www.example.com

Für Apache:

sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d example.com -d www.example.com

Certbot modifiziert automatisch Ihre Virtual-Host-Konfiguration und richtet einen Cron-Job oder systemd-Timer für die Erneuerung ein. Let’s-Encrypt-Zertifikate laufen nach 90 Tagen ab; die automatische Erneuerung läuft standardmäßig alle 60 Tage.

Um die Erneuerung ohne Änderungen zu testen:

sudo certbot renew --dry-run

Für Produktionsumgebungen, die OV- oder EV-Zertifikate benötigen, kaufen Sie diese bei einer kommerziellen CA (DigiCert, Sectigo, GlobalSign) und folgen Sie deren manuellem Ausstellungsprozess. AlexHosts SSL-Zertifikate-Seite bietet eine Übersicht der verfügbaren Optionen, einschließlich DV- und kommerzieller Zertifikate.

Schritt 2: Das Zertifikat auf Ihrem Webserver installieren und konfigurieren

Nginx-Beispiel (/etc/nginx/sites-available/example.com):

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    root /var/www/example.com;
    index index.php index.html;
}

Apache-Beispiel (/etc/apache2/sites-available/example.com-ssl.conf):

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite HIGH:!aNULL:!MD5
    SSLHonorCipherOrder off

    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</VirtualHost>

Schritt 3: HTTPS mit einer permanenten 301-Weiterleitung erzwingen

Nginx — einen separaten Server-Block hinzufügen:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Apache — in .htaccess oder dem HTTP-Virtual-Host:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Verwenden Sie 301 (permanent) anstelle von 302 (temporär). Eine 302-Weiterleitung überträgt keine Link-Equity und aktualisiert keine Browser-Caches, was bedeutet, dass Benutzer bei jeder neuen Sitzung weiterhin HTTP aufrufen werden.

Schritt 4: Mixed Content beheben

Mixed Content tritt auf, wenn eine HTTPS-Seite Unterressourcen (Bilder, Skripte, Stylesheets, iFrames) über HTTP lädt. Browser blockieren oder warnen bei Mixed Content, was die Seitenfunktionalität beeinträchtigt und die Sicherheitsgarantien von HTTPS aufhebt.

Erkennung: Öffnen Sie Chrome DevTools (F12), gehen Sie zum Tab „Konsole” und suchen Sie nach Mixed Content-Warnungen. Alternativ können Sie den SSL Labs Mixed Content Checker oder das why-no-padlock.com-Tool verwenden.

Lösungsstrategien:

• Fest kodierte http://-URLs in Ihrer CMS-Datenbank mit einem Suchen-und-Ersetzen-Tool aktualisieren (z. B. wp-cli search-replace 'http://example.com' 'https://example.com' für WordPress)
• Den Content-Security-Policy: upgrade-insecure-requests-Header als vorübergehende Maßnahme setzen, während Sie die Quellen beheben
• Einbettungen von Drittanbietern prüfen – wenn ein Anbieter HTTPS nicht unterstützt, ersetzen oder entfernen Sie die Einbettung

Schritt 5: Ihre Konfiguration validieren

# Test certificate chain and expiry
openssl s_client -connect example.com:443 -servername example.com < /dev/null

# Check TLS protocol versions and cipher suites
nmap --script ssl-enum-ciphers -p 443 example.com

Für ein umfassendes externes Audit reichen Sie Ihre Domain beim SSL Labs Server Test ein. Eine A+-Bewertung erfordert:

• Nur TLS 1.2 und 1.3 (TLS 1.0 und 1.1 deaktiviert)
• Keine schwachen Cipher Suites (RC4, 3DES, Export-Ciphers)
• HSTS-Header mit max-age >= 180 Tage
• Keine Probleme mit der Zertifikatskette (Zwischenzertifikate enthalten)
• OCSP-Stapling aktiviert

Häufige Fallstricke und Sonderfälle

Unvollständige Zertifikatskette ist das häufigste Produktionsproblem. Wenn Sie nur das Leaf-Zertifikat ohne das Zwischen-CA-Zertifikat installieren, werden die meisten Desktop-Browser die Kette trotzdem auflösen (sie cachen Zwischenzertifikate), aber mobile Browser, API-Clients und curl werden mit SSL_ERROR_RX_RECORD_TOO_LONG oder unable to get local issuer certificate fehlschlagen. Verwenden Sie immer fullchain.pem (Let’s Encrypt) oder verketten Sie Leaf + Intermediate für andere CAs.

OCSP-Stapling reduziert die Handshake-Latenz und verbessert die Privatsphäre, indem der Server die OCSP-Antwort zwischenspeichert und bereitstellt, anstatt den Browser zu zwingen, den OCSP-Responder der CA zu kontaktieren. Ohne Stapling löst jeder TLS-Handshake eine HTTP-Anfrage an Dritte aus, was bei kalten Verbindungen 50–200 ms Latenz hinzufügt. Aktivieren Sie es in Nginx mit ssl_stapling on; ssl_stapling_verify on;.

Sicherheit des privaten Schlüssels wird häufig vernachlässigt. Die Private-Key-Datei sollte root gehören, nur vom Webserver-Prozess lesbar sein und mit chmod 600-Berechtigungen gespeichert werden. Übertragen Sie niemals private Schlüssel in die Versionskontrolle. Verwenden Sie auf gemeinsam genutzter Infrastruktur Hardware-Sicherheitsmodule (HSMs) oder Secrets-Management-Systeme (HashiCorp Vault, AWS Secrets Manager) für die Schlüsselspeicherung.

Widerruf von Wildcard-Zertifikaten hat eine überproportionale Auswirkung. Wenn ein Wildcard-Private-Key kompromittiert und das Zertifikat widerrufen wird, verlieren alle Subdomains gleichzeitig HTTPS. Für hochsicherheitskritische Umgebungen bevorzugen Sie pro-Subdomain-Zertifikate, die über ACME DNS-01-Challenges automatisiert werden.

TLS-Terminierung am Load Balancer ist eine gängige Architektur, bei der TLS am Edge (Load Balancer, CDN, Reverse Proxy) entschlüsselt wird und der Datenverkehr intern unverschlüsselt fließt. Dies ist nur akzeptabel, wenn das interne Netzwerk vollständig vertrauenswürdig und isoliert ist. Für regulierte Umgebungen (PCI-DSS, HIPAA) ist End-to-End-Verschlüsselung – erneute Verschlüsselung des Datenverkehrs zwischen Load Balancer und Backend-Servern – erforderlich.

HTTPS auf der AlexHost-Infrastruktur

In einer VPS-Hosting-Umgebung haben Sie vollen Root-Zugriff, um Certbot zu installieren, Nginx oder Apache direkt zu konfigurieren und die oben beschriebenen gehärteten TLS-Einstellungen zu implementieren. Dies ist der empfohlene Weg für Produktions-Workloads, die benutzerdefinierte Cipher Suites, HSTS-Preloading und OCSP-Stapling erfordern.

Für Benutzer von Shared Web Hosting sind Let’s-Encrypt-Zertifikate in der Regel über das Control Panel mit Ein-Klick-Installation verfügbar, die Zertifikatsausstellung und -erneuerung automatisch ohne SSH-Zugriff übernimmt.

Wenn Sie mehrere Domains verwalten oder einen Reseller-Betrieb führen, bietet VPS mit cPanel eine grafische Oberfläche für das SSL-Management über alle gehosteten Domains hinweg, einschließlich AutoSSL für die automatische Let’s-Encrypt-Bereitstellung.

Für E-Commerce-Deployments, die Zahlungsdaten verarbeiten, bietet die Kombination von HTTPS mit einem kommerziellen OV- oder EV-Zertifikat von SSL-Zertifikate die organisatorische Identitätsverifizierung, die DV-Zertifikate nicht bieten können – relevant für PCI-DSS-Compliance-Audits.

Wenn Ihre Infrastruktur transaktionale oder Marketing-E-Mails umfasst, beachten Sie, dass HTTPS und SMTP/IMAP TLS separate Belange sind. Die Absicherung Ihrer Webpräsenz sichert nicht automatisch Ihre Mail-Infrastruktur; dafür ist eine separate TLS-Konfiguration auf Ihrem E-Mail-Hosting-Stack erforderlich.

Entscheidungsmatrix und technische Checkliste

Verwenden Sie diese Checkliste, bevor Sie eine HTTPS-Migration als abgeschlossen markieren:

Zertifikat

• [ ] Zertifikat von einer vertrauenswürdigen CA ausgestellt (mit openssl verify überprüfen)
• [ ] Vollständige Zertifikatskette installiert (Leaf + Zwischenzertifikate)
• [ ] Zertifikat deckt alle bereitgestellten Domains/Subdomains ab (SANs prüfen)
• [ ] Ablaufüberwachung konfiguriert (Benachrichtigung bei 30 Tagen und 7 Tagen)
• [ ] Automatische Erneuerung mit --dry-run getestet

Serverkonfiguration

• [ ] TLS 1.0 und 1.1 explizit deaktiviert
• [ ] TLS 1.3 aktiviert
• [ ] Schwache Cipher Suites entfernt (RC4, 3DES, NULL, EXPORT)
• [ ] OCSP-Stapling aktiviert und verifiziert
• [ ] ssl_session_tickets off (verhindert Probleme bei der Rotation von Session-Ticket-Schlüsseln)

Anwendungsschicht

• [ ] Alle internen Links verwenden relative URLs oder https://
• [ ] Keine Mixed-Content-Warnungen in der Browser-Konsole
• [ ] Content-Security-Policy: upgrade-insecure-requests-Header gesetzt
• [ ] 301-Weiterleitungen von HTTP zu HTTPS für alle Hostnamen

Sicherheits-Header

• [ ] Strict-Transport-Security-Header mit max-age >= 31536000
• [ ] includeSubDomains-Direktive hinzugefügt (nach Überprüfung, dass alle Subdomains HTTPS unterstützen)
• [ ] Domain in die HSTS-Preload-Liste eingetragen (optional, aber empfohlen)

Validierung

• [ ] SSL Labs Server Test gibt A oder A+ zurück
• [ ] openssl s_client bestätigt korrekte Zertifikatskette
• [ ] Erneuerungs-Cron/systemd-Timer als aktiv bestätigt

FAQ

Schützt HTTPS vor allen Arten von Cyberangriffen?

Nein. HTTPS verschlüsselt die Transportschicht und authentifiziert den Server, schützt jedoch nicht vor Schwachstellen auf Anwendungsebene (SQL-Injection, XSS, CSRF), kompromittiertem serverseitigem Code oder Angriffen auf das Gerät des authentifizierten Benutzers. Eine Phishing-Site kann ein gültiges DV-Zertifikat erhalten und ein Schlosssymbol anzeigen – HTTPS bestätigt, dass die Verbindung verschlüsselt ist, nicht dass die Site vertrauenswürdig ist.

Welche Auswirkungen hat die Aktivierung von HTTPS auf die Leistung?

Mit TLS 1.3 und HTTP/2 ist der Overhead auf moderner Hardware vernachlässigbar. Der TLS-Handshake fügt bei der ersten Verbindung einen zusätzlichen Round Trip hinzu (null bei der Wiederaufnahme mit Session Tickets oder 0-RTT). AES-NI-Hardwarebeschleunigung, die seit 2010 auf praktisch allen Server-CPUs verfügbar ist, verarbeitet die symmetrische Verschlüsselung mit Leitungsgeschwindigkeit. In der Praxis laden HTTPS-Sites oft schneller als HTTP-Äquivalente, weil HTTP/2-Multiplexing und Header-Komprimierung – die in Browsern TLS erfordern – die Handshake-Kosten überwiegen.

Was passiert, wenn ein SSL/TLS-Zertifikat abläuft?

Browser zeigen sofort eine ganzseitige Warnung an, die den Zugriff auf die Site blockiert. API-Clients und mobile Apps schlagen in der Regel mit einem harten Fehler statt einer Warnung fehl. Suchmaschinen-Crawler können die Site weiterhin indexieren, werden den Zertifikatsfehler jedoch kennzeichnen. Die automatische Erneuerung über Certbot oder ACME verhindert das Ablaufen; die kritische operative Anforderung ist sicherzustellen, dass der Erneuerungs-Cron-Job oder systemd-Timer läuft und dass Erneuerungsbenachrichtigungen konfiguriert sind.

Was ist der Unterschied zwischen TLS und SSL?

SSL (Secure Sockets Layer) ist das Vorgängerprotokoll, wobei die Versionen 2.0 und 3.0 beide inzwischen veraltet und durch RFC 7568 aufgrund kritischer Schwachstellen (POODLE, DROWN) verboten sind. TLS (Transport Layer Security) ist der Nachfolger, wobei TLS 1.2 (RFC 5246) und TLS 1.3 (RFC 8446) die einzigen als sicher geltenden Versionen sind. Der Begriff „SSL-Zertifikat” hält sich umgangssprachlich, aber das tatsächlich verwendete Protokoll auf jedem modernen Server ist TLS. Die Konfiguration eines Servers zur Erlaubnis von SSLv3 ist eine Fehlkonfiguration, kein Kompatibilitätsmerkmal.

Kann ich HTTPS für eine Domain verwenden, die ich nicht besitze?

Nein. Zertifizierungsstellen validieren die Domain-Kontrolle vor der Ausstellung. Das ACME-Protokoll (verwendet von Let’s Encrypt) erfordert, dass Sie entweder eine bestimmte Datei unter einem bekannten HTTP-Pfad platzieren (HTTP-01-Challenge) oder einen bestimmten DNS-TXT-Eintrag erstellen (DNS-01-Challenge), um die Kontrolle nachzuweisen. Ohne das Bestehen einer dieser Challenges wird kein Zertifikat für eine Domain ausgestellt, die Sie nicht kontrollieren.