TLS-RPT Generator

So verwenden Sie diesen TLS-RPT-Generator

Schritt 1: Reporting-Ziele hinzufügen

Geben Sie ein, wo Sie TLS-Fehlerberichte erhalten möchten:

E-Mail (empfohlen zum Start)

mailto:tlsrpt@captaindns.com

HTTPS-Webhook (für Automatisierung)

https://tlsrpt.captaindns.com/v1/report

Sie können mehrere Ziele hinzufügen - Berichte gehen an alle.

Schritt 2: Generierten Eintrag kopieren

Der Generator erstellt einen gültigen RFC 8460-Eintrag:

v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Schritt 3: Im DNS veröffentlichen

Erstellen Sie einen TXT-Eintrag bei _smtp._tls.captaindns.com mit dem generierten Wert.

Beispiel für captaindns.com:

• Typ: TXT
• Host: _smtp._tls
• Wert: v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Schritt 4: Veröffentlichung verifizieren

Verwenden Sie unseren TLS-RPT Record Checker, um die korrekte Konfiguration zu bestätigen.

Was TLS-RPT wirklich meldet

TLS-RPT ist ein reines Beobachtungswerkzeug: Es verändert niemals das Verhalten eines Servers, sondern zeigt, was bei den eingehenden TLS-Verbindungen zu Ihren MX-Hosts tatsächlich passiert ist.

Die sendenden Betreiber melden Ihnen insbesondere:

• ein Downgrade oder Stripping von STARTTLS, bei dem die Sitzung auf Klartext zurückfällt
• ein abgelaufenes, nicht vertrauenswürdiges oder selbstsigniertes Zertifikat
• ein Zertifikat, dessen Hostname nicht zum erwarteten MX passt
• das Scheitern beim Abruf oder bei der Validierung einer MTA-STS-Policy
• einen DANE-Fehler: ungültiger TLSA-Eintrag oder gebrochene DNSSEC-Kette

TLS-RPT erzwingt keine Regel. Die Ablehnung der Zustellung einer Klartext-Nachricht kommt von MTA-STS oder DANE; TLS-RPT teilt Ihnen lediglich mit, wann und warum die Verschlüsselung fehlgeschlagen ist, damit Sie korrigieren können, bevor Sie in den Enforce-Modus wechseln.

TLS-RPT-Eintragsformat

Erforderliche Komponenten

Unterstützte URI-Schemata

mailto: - E-Mail-Zustellung

rua=mailto:sicherheitsteam@captaindns.com

Berichte kommen als komprimierte JSON-Anhänge.

https: - Webhook-Zustellung

rua=https://api.captaindns.com/tlsrpt/ingest

Berichte werden als JSON mit dem Header Content-Type: application/tlsrpt+gzip gepostet.

Mehrere Ziele

Mit Kommas trennen:

v=TLSRPTv1; rua=mailto:reports@captaindns.com,https://tlsrpt.captaindns.com/report

Berichte an eine Drittanbieter-Domain senden

Eine rua, die auf eine andere Domain als Ihre eigene zeigt, funktioniert genauso, ohne jeglichen Autorisierungseintrag auf der Empfängerseite.

Das ist ein wesentlicher Unterschied zu DMARC. DMARC verlangt einen _report._dmarc-Eintrag bei der Drittanbieter-Domain, bevor Cross-Domain-Berichte akzeptiert werden. RFC 8460 hat diesen Mechanismus bewusst verworfen (Abschnitt 7): Das Amplifikationsrisiko ist bei TLS-RPT geringer als bei DMARC, und das Vertrauen wird anders sichergestellt. mailto:-Berichte werden vom sendenden Betreiber per DKIM signiert, und https:-Berichte beruhen auf dem Besitz des DNS und des Zertifikats des Endpunkts.

v=TLSRPTv1; rua=mailto:reports@tlsrpt-service.com

Auf tlsrpt-service.com ist keine Aktion erforderlich, damit diese rua gültig ist.

Der Einfachheit halber genügt in den meisten Fällen eine Adresse auf Ihrer eigenen Domain:

v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

DNS-Anbieter-Beispiele

Cloudflare

1. Gehen Sie zu DNS-Einstellungen für Ihre Domain
2. Eintrag hinzufügen:
   • Typ: TXT
   • Name: _smtp._tls
   • Inhalt: Ihr generierter Eintragswert
   • TTL: Auto

AWS Route 53

1. Öffnen Sie die gehostete Zone für Ihre Domain
2. Eintrag erstellen:
   • Eintragsname: _smtp._tls
   • Eintragstyp: TXT
   • Wert: "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"
   • TTL: 3600

IONOS / OVH / Strato

1. Gehen Sie zu DNS-Einstellungen
2. Benutzerdefinierten Eintrag hinzufügen:
   • Hostname: _smtp._tls
   • Typ: TXT
   • TTL: 3600
   • Daten: Ihr generierter Eintragswert

TLS-RPT-Berichte verstehen

Ein TLS-RPT-Bericht ist ein aggregiertes, gzip-komprimiertes JSON-Dokument, das die TLS-Sitzungen eines Betreibers zu Ihrer Domain über einen Tag zusammenfasst.

Anatomie eines Berichts

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2024-01-15T00:00:00Z",
    "end-datetime": "2024-01-16T00:00:00Z"
  },
  "contact-info": "postmaster@google.com",
  "report-id": "2024011512345",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce", "mx: mail.captaindns.com", "max_age: 604800"],
      "policy-domain": "captaindns.com"
    },
    "summary": {
      "total-successful-session-count": 8432,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.1",
      "receiving-mx-hostname": "mail.captaindns.com",
      "failed-session-count": 3
    }]
  }]
}

Die Fehlertypen (result-type)

Das IANA-Register definiert 11 mögliche Werte für result-type:

Die Policy-Typen (policy-type)

Jede Sitzung wird einem der 3 policy-type zugeordnet:

Transport und Kadenz

Alle Berichte sind gzip-komprimiert. Je nach Schema Ihrer rua gibt es zwei Zustellkanäle:

• HTTPS: Der Bericht wird per POST mit dem Header Content-Type: application/tlsrpt+gzip (oder application/tlsrpt+json) gesendet. Der Endpunkt bestätigt den Empfang mit einem 2xx-Status.
• E-Mail: Die Nachricht ist ein multipart/report; report-type="tlsrpt" mit einem Anhang application/tlsrpt+gzip. Sie trägt die Header TLS-Report-Domain und TLS-Report-Submitter, einen Betreff der Form Report Domain: captaindns.com Submitter: google.com Report-ID: 2024011512345 und ist mit dem Selektor s=tlsrpt per DKIM signiert.

Kadenz: Jeder sendende Betreiber sendet einen aggregierten Bericht pro Tag, der das Fenster 00:00 bis 24:00 UTC abdeckt. Schlägt die Zustellung fehl, wird bis zu 24 Stunden lang erneut versucht.

Wer die Berichte sendet

Die großen Betreiber stellen TLS-RPT-Berichte aus: Google, Microsoft und Yahoo tun dies systematisch; Apple und Comcast werden ebenfalls genannt. Jeder Betreiber erstellt seinen eigenen unabhängigen Bericht, Sie können also mehrere pro Tag erhalten, einen pro Absender.

TLS-RPT mit MTA-STS und DANE

TLS-RPT ist die Beobachtungsschleife von MTA-STS und DANE. Diese Protokolle erzwingen die Verschlüsselung; TLS-RPT zeigt Ihnen die Wirkung dieser Durchsetzung, vor wie nach dem Produktivstart.

Empfohlene Bereitstellungsreihenfolge

1. TLS-RPT veröffentlichen und MTA-STS im mode: testing
2. Die Berichte 2 bis 4 Wochen lang analysieren
3. MTA-STS in den mode: enforce umstellen
4. Die Überwachung über TLS-RPT fortsetzen

Ohne TLS-RPT in den Enforce-Modus zu wechseln bedeutet, blind voranzugehen: Bricht eine Policy die Zustellbarkeit, erfahren Sie es nur über die Beschwerden der Nutzer.

Verwandte Tools

• MTA-STS-Policy generieren
• MTA-STS-Status prüfen
• TLS-RPT-Status prüfen
• DANE-TLSA-Einträge prüfen

Bewährte Praktiken und häufige Fallstricke

Bewährte Praktiken

• Richten Sie die rua auf ein dediziertes Postfach oder einen dedizierten Endpunkt, der das Volumen verarbeiten und das JSON parsen kann. Niemals ein menschliches Postfach: Die Berichte treffen täglich ein, als gzip-komprimiertes JSON, von jedem Betreiber.
• Nutzen Sie ein Aggregationstool, um diese Berichte in auswertbare Trends zu verwandeln, statt sie einzeln zu öffnen.

Zu vermeidende Fallstricke

• Zwei TXT-Einträge bei _smtp._tls machen die Konfiguration ungültig. Behalten Sie einen einzigen Eintrag mit einem einzigen Wert.
• Kodieren Sie die Zeichen ,, ! und ; per Prozent-Encoding, wenn sie in einer URI vorkommen (etwa in einer mailto: mit Parametern), sonst bricht das Parsen des Eintrags.

Konkrete Anwendungsfälle

Jedes der folgenden Szenarien spiegelt sich in einem genauen result-type in Ihren Berichten wider:

• Ein Backup-MX, der nie für TLS konfiguriert wurde: starttls-not-supported. Sie erkennen es, bevor ein Angreifer es ausnutzt.
• Das Zertifikat eines Partners ist abgelaufen: certificate-expired für die betroffenen Sitzungen.
• Ein MX präsentiert ein für den falschen Hostnamen ausgestelltes Zertifikat: certificate-host-mismatch.
• Ein aktives STARTTLS-Downgrade (Angriff im Netzwerk) lässt die verschlüsselten Sitzungen einbrechen: Spitze bei starttls-not-supported.
• Ihre eigene MTA-STS-Policy ist defekt oder nicht erreichbar: sts-policy-fetch-error oder sts-policy-invalid, bevor sie legitime Post blockiert.
• Ein falsch konfiguriertes DANE: tlsa-invalid (TLSA, das nach einer Zertifikatsrotation nicht mehr passt) oder dnssec-invalid (gebrochene DNSSEC-Kette).

Ergänzende Tools

Nützliche Ressourcen

• RFC 8460 - SMTP TLS Reporting (offizielle Spezifikation)
• RFC 8461 - MTA-STS (Begleitprotokoll)
• Google - TLS-Reporting konfigurieren
• Postfix - TLS-Dokumentation