TLS-RPT Generator

Comment utiliser ce générateur TLS-RPT

Étape 1 : Ajouter les destinations des rapports

Indiquez où vous souhaitez recevoir les rapports d'échec TLS :

Email (recommandé pour commencer)

mailto:tlsrpt@captaindns.com

Webhook HTTPS (pour l'automatisation)

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

Vous pouvez ajouter plusieurs destinations : les rapports sont envoyés à toutes.

Étape 2 : Copier l'enregistrement généré

Le générateur crée un enregistrement RFC 8460 valide :

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

Étape 3 : Publier dans le DNS

Créez un enregistrement TXT à _smtp._tls.captaindns.com avec la valeur générée.

Exemple pour captaindns.com :

• Type : TXT
• Hôte : _smtp._tls
• Valeur : v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Étape 4 : Vérifier la publication

Utilisez notre Inspecteur TLS-RPT pour confirmer que la configuration est correcte.

Ce que TLS-RPT rapporte vraiment

TLS-RPT est un outil d'observabilité pur : il ne modifie jamais le comportement d'un serveur, il révèle ce qui s'est réellement passé lors des connexions TLS entrantes vers vos MX.

Les opérateurs expéditeurs vous signalent notamment :

• un downgrade ou un stripping de STARTTLS, où la session retombe en clair
• un certificat expiré, non fiable ou auto-signé
• un certificat dont le hostname ne correspond pas au MX attendu
• l'échec de récupération ou de validation d'une politique MTA-STS
• un échec DANE : enregistrement TLSA invalide ou chaîne DNSSEC cassée

TLS-RPT n'applique aucune règle. Le refus de délivrer un message en clair vient de MTA-STS ou de DANE ; TLS-RPT se contente de vous dire quand et pourquoi le chiffrement a échoué, pour que vous puissiez corriger avant de passer en enforce.

Format d'enregistrement TLS-RPT

Composants requis

Schémas d'URI pris en charge

mailto: - Livraison par email

rua=mailto:equipe-securite@captaindns.com

Les rapports arrivent en pièces jointes JSON compressées.

https: - Livraison webhook

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

Les rapports sont envoyés en POST, au format JSON, avec l'en-tête Content-Type: application/tlsrpt+gzip

Plusieurs destinations

Séparez-les par des virgules :

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

Envoyer les rapports vers un domaine tiers

Un rua qui pointe vers un autre domaine que le vôtre fonctionne tel quel, sans aucun enregistrement d'autorisation côté destinataire.

C'est une différence majeure avec DMARC. DMARC exige un enregistrement _report._dmarc chez le domaine tiers avant d'accepter des rapports cross-domain. La RFC 8460 a délibérément écarté ce mécanisme (section 7) : le risque d'amplification par TLS-RPT est plus faible qu'en DMARC, et la confiance est assurée autrement. Les rapports mailto: sont signés DKIM par l'opérateur émetteur, et les rapports https: reposent sur la possession du DNS et du certificat de l'endpoint.

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

Aucune action n'est requise sur tlsrpt-service.com pour que ce rua soit valide.

Pour rester simple, une adresse sur votre propre domaine suffit dans la plupart des cas :

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

Exemples par fournisseur DNS

Cloudflare

1. Allez dans les paramètres DNS de votre domaine
2. Ajoutez un enregistrement :
   • Type : TXT
   • Nom : _smtp._tls
   • Contenu : Votre valeur d'enregistrement générée
   • TTL : Auto

AWS Route 53

1. Ouvrez la zone hébergée pour votre domaine
2. Créez un enregistrement :
   • Nom de l'enregistrement : _smtp._tls
   • Type d'enregistrement : TXT
   • Valeur : "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"
   • TTL : 3600

OVH / Google Domains

1. Allez dans la zone DNS
2. Ajoutez une entrée :
   • Sous-domaine : _smtp._tls
   • Type : TXT
   • Cible : Votre valeur d'enregistrement générée
   • TTL : 3600

Comprendre les rapports TLS-RPT

Un rapport TLS-RPT est un document JSON agrégé, compressé en gzip, qui résume les sessions TLS d'un opérateur vers votre domaine sur une journée.

Anatomie d'un rapport

{
  "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
    }]
  }]
}

Les types d'échec (result-type)

Le registre IANA définit 11 valeurs possibles pour result-type :

Les types de politique (policy-type)

Chaque session est rattachée à l'un des 3 policy-type :

Transport et cadence

Tous les rapports sont compressés en gzip. Deux canaux de livraison existent, selon le schéma de votre rua :

• HTTPS : le rapport est envoyé en POST avec l'en-tête Content-Type: application/tlsrpt+gzip (ou application/tlsrpt+json). L'endpoint confirme la réception par un statut 2xx.
• Email : le message est un multipart/report; report-type="tlsrpt" avec une pièce jointe application/tlsrpt+gzip. Il porte les en-têtes TLS-Report-Domain et TLS-Report-Submitter, un sujet de la forme Report Domain: captaindns.com Submitter: google.com Report-ID: 2024011512345, et il est signé DKIM avec le sélecteur s=tlsrpt.

Cadence : chaque opérateur émetteur envoie un rapport agrégé par jour, couvrant la fenêtre 00:00 à 24:00 UTC. En cas d'échec de livraison, il réessaie jusqu'à 24 heures.

Qui envoie les rapports

Les grands opérateurs émettent des rapports TLS-RPT : Google, Microsoft et Yahoo le font systématiquement ; Apple et Comcast sont aussi rapportés. Chaque opérateur produit son propre rapport indépendant, vous pouvez donc en recevoir plusieurs par jour, un par expéditeur.

TLS-RPT avec MTA-STS et DANE

TLS-RPT est la boucle d'observabilité de MTA-STS et de DANE. Ces protocoles appliquent le chiffrement ; TLS-RPT vous montre l'effet de cette application, avant comme après le passage en production.

Ordre de déploiement recommandé

1. Publier TLS-RPT, et MTA-STS en mode: testing
2. Analyser les rapports pendant 2 à 4 semaines
3. Passer MTA-STS en mode: enforce
4. Continuer la surveillance via TLS-RPT

Passer en enforce sans TLS-RPT revient à avancer à l'aveugle : si une politique casse la délivrabilité, vous ne l'apprendrez que par les plaintes des utilisateurs.

Outils liés

• Générer une politique MTA-STS
• Vérifier le statut MTA-STS
• Vérifier le statut TLS-RPT
• Vérifier les enregistrements DANE TLSA

Bonnes pratiques et pièges courants

Bonnes pratiques

• Pointez le rua vers une boîte ou un endpoint dédié, capable d'absorber le volume et de parser le JSON. Jamais une boîte humaine : les rapports arrivent chaque jour, en JSON gzippé, depuis chaque opérateur.
• Utilisez un outil d'agrégation pour transformer ces rapports en tendances exploitables plutôt que de les ouvrir un par un.

Pièges à éviter

• Deux enregistrements TXT à _smtp._tls rendent la configuration invalide. Gardez un seul enregistrement avec une seule valeur.
• Percent-encodez les caractères ,, ! et ; quand ils apparaissent dans une URI (par exemple dans un mailto: avec paramètres), sinon le parsing de l'enregistrement casse.

Cas d'usage concrets

Chaque scénario ci-dessous se traduit par un result-type précis dans vos rapports :

• Un MX de secours jamais configuré pour TLS : starttls-not-supported. Vous le repérez avant qu'un attaquant n'en profite.
• Le certificat d'un partenaire a expiré : certificate-expired sur les sessions qui le concernent.
• Un MX présente un certificat émis pour le mauvais hostname : certificate-host-mismatch.
• Un downgrade actif de STARTTLS (attaque sur le réseau) fait chuter les sessions chiffrées : pic de starttls-not-supported.
• Votre propre politique MTA-STS est cassée ou injoignable : sts-policy-fetch-error ou sts-policy-invalid, avant qu'elle ne bloque du courrier légitime.
• Un DANE mal configuré : tlsa-invalid (TLSA qui ne correspond plus après une rotation de certificat) ou dnssec-invalid (chaîne DNSSEC cassée).

Outils complémentaires

Ressources utiles

• RFC 8460 - SMTP TLS Reporting (spécification officielle)
• RFC 8461 - MTA-STS (protocole compagnon)
• Google - Configurer TLS reporting
• Postfix - Documentation TLS