[ Sécurité des transports ]
Publiez et faites pivoter les enregistrements TLSA sans interrompre la livraison SMTP
Planifiez le roulement TLSA à paramètres fixes avec prépublication, chevauchement tenant compte du cache, vérification de la flotte et limite de récupération avant de supprimer les anciennes associations.
Par l’équipe de recherche EmailAuth · 8 minutes de lecture
[ Points clés ]
- Identifiez si la modification remplace une clé, un certificat, une ancre de confiance ou des paramètres TLSA.
- Pour le basculement à paramètres fixes, pré-publiez les anciennes et les nouvelles associations au moins deux durées de vie avant le déploiement.
- Retirez les anciennes associations uniquement après avoir compris le service actif et les dépendances de restauration.
Sur cette page
[ Emporter ]
Coordonnez les opérateurs DNS et SMTP autour d'un chevauchement vérifié, puis déployez et retirez par étapes sans confondre un certificat enregistré avec une restauration sécurisée.
[ Par rôle ]
Qu'est-ce que cela signifie pour vous
Choisissez votre rôle pour les prochaines étapes pratiques.
Administrateur informatique/courrier
Vérifiez chaque étape de rollover
Une tâche de déploiement réussie ne prouve pas que chaque instance SMTP présente la clé prévue.
Prochaines étapes
- Capturez la ligne de base sécurisée et le tuple TLSA complet.
- Pré-publiez l’ensemble étendu et enregistrez le timing.
- Vérifiez chaque instance active avant de retirer les anciennes données.
RSSI / SecOps
Séparez les preuves publiques de la garde des clés
Le plan DNS a besoin d'associations, pas de clés privées.
Prochaines étapes
- Examinez explicitement les modifications d’utilisation et de paramètres.
- Conservez les enregistrements correspondant actuellement pour chaque combinaison publiée.
- Traitez la validation DNSSEC comme une porte indépendante.
Fondateur / Non technique
Coordonner la dépendance de maintenance
Les caches DNS et le déploiement échelonné des serveurs peuvent survivre à une fenêtre de maintenance.
Prochaines étapes
- Attribuez les propriétaires de publication et SMTP .
- Approuver un plan de chevauchement et de rétablissement justifié.
- Exigez des preuves avant l’étape finale de la retraite.
[ FAQ ]
Questions fréquemment posées
Chaque renouvellement de certificat modifie-t-il un enregistrement 3 1 1 ?
Non. Cette association sélectionne la clé publique, donc le renouvellement en utilisant la même clé peut la préserver. Vérifiez la clé réelle plutôt que de supposer que l’automatisation la réutilise.
À quel moment les nouvelles associations à paramètres fixes doivent-elles être publiées ?
RFC 7671 spécifie d'augmenter l'ancien ensemble d'au moins deux durées de vie, ou plus, avant de déployer la nouvelle chaîne. Conserver l'association actuelle pendant le chevauchement.
La réduction de la durée de vie peut-elle immédiatement raccourcir les anciennes données mises en cache ?
Non. Les copies déjà mises en cache sous la durée de vie précédente nécessitent leur propre considération temporelle. Enregistrez la publication réelle et l’historique du cache.
Puis-je publier uniquement les données futures sous une seule combinaison de paramètres ?
Les directives de l'éditeur nécessitent une association de correspondance actuelle pour chaque combinaison utilisation/sélecteur/type de correspondance publiée. Les enregistrements futurs ou retirés ne peuvent pas être les seuls pour cette combinaison.
Quand les associations obsolètes peuvent-elles être supprimées ?
Une fois la nouvelle chaîne déployée et vérifiée, l'ancienne association ne décrit plus de dépendance active. Vérifiez les exigences en matière de sauvegarde et de restauration avant la suppression.
La restauration de l'ancien certificat est-elle toujours une restauration sûre ?
Non. Certains clients peuvent avoir un nouvel ensemble TLSA uniquement mis en cache après le retrait. Évaluez les données publiées actuelles et l’historique du cache avant de restaurer le serveur.
Puis-je appliquer la même séquence lors d’un changement d’utilisation ou de sélecteur ?
Ne le supposez pas. Les transitions de paramètres nécessitent les directives et la révision de compatibilité correspondantes RFC 7671 , distinctes du basculement de clé à paramètres fixes.
Aucun échec TLS-RPT ne prouve-t-il que le basculement a réussi ?
Non. La déclaration est facultative, globale et différée. Conservez les preuves DNS et SMTP sécurisées et autorisées directes pour la flotte réelle.
[ Sources ]
Sources
- RFC 1035
Sections §3.2.1 Format · §3.3.13 Format SOA RDATA
- RFC 8460
Sections §3. Politique de rapport · §4.1 Délai du rapport · §4.3 Types de résultats · §5.2 Compression · §5.3 Transport des e-mails · §5.4 Transport HTTPS · §5.5 Nouvelle tentative de livraison · §5.6 Variations des métadonnées · §7. Considérations de sécurité
- RFC 7672
Sections §2.1 Considérations DNS · §2.2 Découverte TLS · §2.2.1 Résolution MX · §2.2.3 Recherche d'enregistrements TLSA · §3.1 Utilisations des certificats TLSA · §3.2 Correspondance des certificats · §4. Gestion des clés du serveur
- RFC 7671
Sections §6. Synchronisation du fournisseur de services et de l'éditeur TLSA · §7. Domaine de base TLSA et CNAME · §8. Exigences de l'éditeur TLSA · §8.1 Renouvellement de clé avec paramètres TLSA fixes · §8.3 Passage aux nouveaux paramètres TLSA
- RFC 6698
Sections §2.1 Format de fil TLSA RDATA · §3. Noms de domaine pour les associations de certificats TLSA
[ Glossaire ]
Glossaire
- Prépublication
- Publier les associations pour une future clé tout en préservant les associations actuelles avant de changer de service.
- Chevauchement des associations
- Un ensemble TLSA qui prend en charge le matériel de clé actuel et transitoire requis.
- Paramètres fixes
- Utilisation inchangée du certificat, combinaisons de sélecteur et de type correspondant lors d'un roulement de clé.
- Limite de restauration
- Le point auquel les nouvelles données publiées et mises en cache uniquement peuvent rendre dangereux le retour à l’ancienne clé du serveur sans coordination supplémentaire.
Provenance de l'entreprise
Pourquoi les principales institutions financières et gouvernements ont retiré leurs tableaux de bord de sécurité de messagerie.
Les plateformes traditionnelles d'authentification de courrier électronique vous vendent un tableau de bord et demandent à vos ingénieurs de faire le travail. Dans les environnements à enjeux élevés, la surveillance manuelle entraîne des retards dans l’application, des dérives de configuration et des domaines fantômes non surveillés.
EmailAuth est la plateforme agent de provenance des e-mails. Nos agents appliquent p=reject, gardez les expéditeurs tiers alignés et déplacez vos domaines au maximum RFC 9989 conformité, la nouvelle norme DMARC , avec une auditabilité humaine dans la boucle.
SaaS · Location dédiée · Air-gappé sur site · Chiffrement BYOK