[ Transportsikkerhet ]
Publiser og roter TLSA-poster uten å bryte SMTP leveringen
Planlegg TLSA-rullover med faste parametere med forhåndspublisering, hurtigbufferbevisst overlapping, flåteverifisering og en gjenopprettingsgrense før du fjerner gamle assosiasjoner.
Av EmailAuth -forskningsteamet · 8 min lesing
[Nøkkelpunkter]
- Identifiser om endringen erstatter en nøkkel, sertifikat, tillitsanker eller TLSA-parametere.
- For overgang med faste parametere, forhåndspublisere gamle og nye tilknytninger minst to TTL-er før distribusjon.
- Trekke opp gamle foreninger først etter at aktive service- og tilbakeføringsavhengigheter er forstått.
[ Takeaway ]
Koordiner DNS og SMTP operatører rundt en bekreftet overlapping, distribuer og trekk deretter ut i etapper uten å forveksle et lagret sertifikat med en sikker tilbakeføring.
[Etter rolle]
Hva dette betyr for deg
Velg din rolle for praktiske neste trinn.
IT / Mail Admin
Bekreft hvert rulletrinn
En vellykket distribusjonsjobb beviser ikke at hver SMTP forekomst presenterer den tiltenkte nøkkelen.
Neste trinn
- Fang den sikre grunnlinjen og hele TLSA-tuppelen.
- Forhåndspubliser det utvidede settet og ta opp timing.
- Bekreft hver aktive forekomst før du trekker tilbake gamle data.
CISO / SecOps
Hold offentlige bevis atskilt fra nøkkelforvaring
DNS planen trenger assosiasjoner, ikke private nøkler.
Neste trinn
- Gjennomgå bruk og parameterendringer eksplisitt.
- Oppretthold samsvarende poster for hver publiserte kombinasjon.
- Behandle DNSSEC validering som en uavhengig port.
Grunnlegger / Ikke-teknisk
Koordinere vedlikeholdsavhengigheten
DNS cacher og forskjøvet serverdistribusjon kan overleve et vedlikeholdsvindu.
Neste trinn
- Tildel både publikasjons- og SMTP eiere.
- Godkjenne en begrunnet overlapping og gjenopprettingsplan.
- Krev bevis før det endelige pensjoneringstrinnet.
[ Vanlige spørsmål ]
Ofte stilte spørsmål
Endrer hver sertifikatfornyelse en 3 1 1-post?
Nei. Den tilknytningen velger den offentlige nøkkelen, så fornyelse med samme nøkkel kan bevare den. Bekreft den faktiske nøkkelen i stedet for å anta at automatisering gjenbruker den.
Hvor tidlig bør nye assosiasjoner med faste parametere publiseres?
RFC 7671 spesifiserer å utvide det gamle settet med minst to TTL-er, eller lenger, før den nye kjeden distribueres. Bevar gjeldende tilknytning under overlapping.
Kan senking av TTL umiddelbart forkorte gamle hurtigbufrede data?
Nei. Kopier som allerede er bufret under forrige TTL, trenger sine egne tidsberegninger. Ta opp den faktiske publiseringen og cachehistorikken.
Kan jeg bare publisere fremtidige data under én parameterkombinasjon?
Utgiverveiledningen krever en samsvarende tilknytning for hver publiserte kombinasjon av bruk/velger/samsvarstype. Fremtidige eller pensjonerte poster kan ikke være de eneste for den kombinasjonen.
Når kan foreldede assosiasjoner fjernes?
Etter at den nye kjeden er distribuert og verifisert og den gamle foreningen ikke lenger beskriver en aktiv avhengighet. Gjennomgå sikkerhetskopier og tilbakestillingskrav før fjerning.
Er det alltid en trygg tilbakeføring å gjenopprette det gamle sertifikatet?
Nei. Noen klienter kan ha et TLSA-sett som kun er nytt, bufret etter pensjonering. Vurder gjeldende publiserte data og hurtigbufferhistorikk før du tilbakestiller serveren.
Kan jeg bruke samme sekvens når jeg endrer bruk eller velger?
Ikke anta det. Parameteroverganger krever korresponderende RFC 7671 veiledning og kompatibilitetsgjennomgang, atskilt fra nøkkeloverføring med faste parametere.
Beviser ingen TLS-RPT feil at rolloveringen var vellykket?
Nei. Rapportering er valgfri, samlet og forsinket. Behold direkte autorisert sikker DNS- og SMTP bevis for den faktiske flåten.
[ Kilder ]
Kilder
- RFC 1035
Seksjoner §3.2.1 Format · §3.3.13 SOA RDATA-format
- RFC 8460
Seksjoner §3. Rapporteringspolicy · §4.1 Tidsramme for rapportering · §4.3 Resultattyper · §5.2 Komprimering · §5.3 E-posttransport · §5.4 HTTPS-transport · §5.5 Forsøk på nytt levering · §5.6 Metadataavvik · §7. Sikkerhetshensyn
- RFC 7672
Seksjoner §2.1 DNS hensyn · §2.2 TLS Discovery · §2.2.1 MX -oppløsning · §2.2.3 TLSA Record Lookup · §3.1 TLSA-sertifikatbruk · §3.2 Sertifikatmatching · §4. Servernøkkeladministrasjon
- RFC 7671
Seksjoner §6. Tjenesteleverandør og TLSA Publisher Synchronization · §7. TLSA-basedomene og CNAME-er · §8. TLSA Publisher-krav · §8.1 Nøkkelovergang med faste TLSA-parametre · §8.3 Bytte til nye TLSA-parametre
- RFC 6698
Seksjoner §2.1 TLSA RDATA Wire Format · §3. Domenenavn for TLSA-sertifikatforeninger
[ Ordliste ]
Ordliste
- Forpublisering
- Publisere assosiasjoner for en fremtidig nøkkel samtidig som de nåværende assosiasjonene bevares før du bytter tjeneste.
- Assosiasjonsoverlapping
- Et TLSA-sett som støtter det nødvendige gjeldende og overgangsnøkkelmaterialet.
- Faste parametere
- Uendret sertifikatbruk, velger og matchende type kombinasjoner under en nøkkelvelling.
- Tilbakerullingsgrense
- Punktet der publiserte og hurtigbufrede data kan gjøre en retur til den gamle servernøkkelen usikker uten ytterligere koordinering.
Enterprise herkomst
Hvorfor topp finansinstitusjoner og regjeringer pensjonert e-postsikkerhetsdashboardene deres.
Tradisjonelle e-postautentiseringsplattformer selger deg et dashbord og ber ingeniørene dine gjøre jobben. I miljøer med høy innsats betyr manuell overvåking forsinket håndheving, konfigurasjonsdrift og uovervåkede skyggedomener.
EmailAuth er den agentiske e-postopprinnelsesplattformen. Våre agenter håndhever p=reject, hold tredjepartssendere på linje og flytt domenene dine til fulle RFC 9989 compliance, den nye DMARC standarden, med menneskelig-in-the-loop reviderbarhet.
SaaS · Dedikert leieforhold · Air-gaped on-prem · BYOK-kryptering