[ Transportsikkerhed ]
Udgiv og roter TLSA-poster uden at bryde SMTP leveringen
Planlæg TLSA-rollover med faste parametre med præpublicering, cache-bevidst overlap, flådebekræftelse og en gendannelsesgrænse, før du fjerner gamle tilknytninger.
Af EmailAuth -forskningsteamet · 8 min læst
[Nøglepunkter]
- Identificer, om ændringen erstatter en nøgle, certifikat, tillidsanker eller TLSA-parametre.
- For rollover med faste parametre skal du forududgive gamle og nye tilknytninger mindst to TTL'er før implementering.
- Træk først gamle foreninger på pension efter aktiv service og tilbagerulningsafhængighed er forstået.
[ Takeaway ]
Koordiner DNS og SMTP operatører omkring et verificeret overlap, og implementer og træk derefter tilbage i etaper uden at forveksle et gemt certifikat med en sikker rollback.
[Efter rolle]
Hvad betyder det for dig
Vælg din rolle for praktiske næste trin.
IT / Mail Admin
Bekræft hvert rollover-trin
Et vellykket implementeringsjob beviser ikke, at hver SMTP instans præsenterer den tilsigtede nøgle.
Næste trin
- Fang den sikre baseline og den fulde TLSA-tuple.
- Forudgiv det udvidede sæt og optag timing.
- Bekræft hver aktiv forekomst, før du trækker gamle data tilbage.
CISO / SecOps
Hold offentligt bevis adskilt fra nøgleforvaring
DNS planen har brug for tilknytninger, ikke private nøgler.
Næste trin
- Gennemgå brug og parameterændringer eksplicit.
- Oprethold aktuelt matchende registreringer for hver offentliggjort kombination.
- Behandl DNSSEC -validering som en uafhængig gate.
Grundlægger / Ikke-teknisk
Koordiner vedligeholdelsesafhængigheden
DNS caches og forskudt serverimplementering kan overleve et vedligeholdelsesvindue.
Næste trin
- Tildel både publikations- og SMTP ejere.
- Godkend en begrundet overlapning og genopretningsplan.
- Kræv bevis før det endelige pensionstrin.
[ Ofte stillede spørgsmål ]
Ofte stillede spørgsmål
Ændrer hver certifikatfornyelse en 3 1 1 post?
Nej. Den tilknytning vælger den offentlige nøgle, så fornyelse med den samme nøgle kan bevare den. Bekræft den faktiske nøgle i stedet for at antage, at automatisering genbruger den.
Hvor tidligt skal nye foreninger med faste parametre offentliggøres?
RFC 7671 specificerer at udvide det gamle sæt med mindst to TTL'er eller længere, før den nye kæde implementeres. Bevar den nuværende tilknytning under overlapning.
Kan sænkning af TTL straks forkorte gamle cachelagrede data?
Nej. Kopier, der allerede er cachelagret under den tidligere TTL, kræver deres egen timing. Optag den faktiske udgivelse og cachehistorie.
Kan jeg kun offentliggøre fremtidige data under én parameterkombination?
Udgivervejledningen kræver en aktuelt matchende tilknytning for hver offentliggjort brug/vælger/match-type kombination. Fremtidige eller tilbagetrukne poster kan ikke være de eneste for denne kombination.
Hvornår kan forældede foreninger fjernes?
Efter at den nye kæde er implementeret og verificeret, og den gamle forening ikke længere beskriver en aktiv afhængighed. Gennemgå sikkerhedskopier og tilbagerulningskrav før fjernelse.
Er gendannelse af det gamle certifikat altid en sikker tilbagerulning?
Nej. Nogle klienter har muligvis et TLSA-sæt, der kun er nyt, i cache efter pensionering. Vurder aktuelle offentliggjorte data og cachehistorik, før du vender tilbage til serveren.
Kan jeg anvende den samme sekvens, når jeg ændrer brug eller vælger?
Antag det ikke. Parameterovergange kræver den tilsvarende RFC 7671 vejledning og kompatibilitetsgennemgang, adskilt fra nøgleskift med faste parametre.
Beviser ingen TLS-RPT fejl, at rollover lykkedes?
Nej. Rapportering er valgfri, samlet og forsinket. Behold direkte autoriseret sikker DNS- og SMTP -bevis for den faktiske flåde.
[ Kilder ]
Kilder
- RFC 1035
Afsnit §3.2.1 Format · §3.3.13 SOA RDATA-format
- RFC 8460
Afsnit §3. Rapporteringspolitik · §4.1 Rapporteringstidsramme · §4.3 Resultattyper · §5.2 Komprimering · §5.3 E-mailtransport · §5.4 HTTPS-transport · §5.5 Leveringsforsøg · §5.6 Metadataafvigelser · §7. Sikkerhedshensyn
- RFC 7672
Afsnit §2.1 DNS overvejelser · §2.2 TLS Discovery · §2.2.1 MX -opløsning · §2.2.3 TLSA Record Lookup · §3.1 TLSA-certifikatanvendelser · §3.2 Certifikatmatching · §4. Servernøglestyring
- RFC 7671
Afsnit §6. Tjenesteudbyder og TLSA Publisher Synchronization · §7. TLSA-basedomæne og CNAME'er · §8. TLSA Publisher-krav · §8.1 Nøgleoverførsel med faste TLSA-parametre · §8.3 Skift til nye TLSA-parametre
- RFC 6698
Afsnit §2.1 TLSA RDATA trådformat · §3. Domænenavne til TLSA-certifikatforeninger
[ Ordliste ]
Ordliste
- Forudgivelse
- Udgivelse af tilknytninger til en fremtidig nøgle, samtidig med at de nuværende tilknytninger bevares, før tjenesten skiftes.
- Sammenslutningen overlapper hinanden
- Et TLSA-sæt, der understøtter det nødvendige nuværende og overgangsnøglemateriale.
- Faste parametre
- Uændret certifikatbrug, vælger og matchende type kombinationer under en nøglerollover.
- Rollback grænse
- Det punkt, hvor offentliggjorte og cachelagrede data, der kun er nye, kan gøre en tilbagevenden til den gamle servernøgle usikker uden yderligere koordinering.
Virksomhedens herkomst
Hvorfor top finansielle institutioner og regeringer pensionerede deres e-mailsikkerhedsdashboards.
Traditionelle e-mail-godkendelsesplatforme sælger dig et dashboard og beder dine ingeniører om at gøre arbejdet. I miljøer med høj indsats betyder manuel overvågning forsinket håndhævelse, konfigurationsdrift og uovervågede skyggedomæner.
EmailAuth er den agentiske e-mail-herkomstplatform. Vores agenter håndhæver p=reject, hold tredjepartsafsendere på linje og flyt dine domæner til fuld RFC 9989 compliance, den nye DMARC standard, med menneskelig auditabilitet.
SaaS · Dedikeret lejemål · Air-gapped on-prem · BYOK-kryptering