[ Transportsikkerhet ]

Utløpte eller ikke-klarerte sertifikater i SMTP TLS rapporter

Skille utløp fra svikt i tillitskjeden, bevar det rapporterte endepunktet og valider sertifikatet som faktisk ble levert etter fornyelse.

Av EmailAuth -forskningsteamet · 4 min lesing

[Nøkkelpunkter]

  • Utløpt og uklarert er forskjellige kategorier med forskjellige mulige reparasjoner.
  • Inspiser sertifikatet hver berørt lytter faktisk presenterer.
  • Sammenlign observasjoner under riktig STS- eller DANE tillitsmodell.
På denne siden

Skille utløp fra svikt i tillitskjeden, bevar det rapporterte endepunktet og valider sertifikatet som faktisk ble levert etter fornyelse.

Les resultatkategorien nøyaktig

Referanser: RFC 8460 §4.3.1, RFC 8460 §4.3.2.

sertifikat-utløpt betyr at reporteren observerte et utløpt sertifikat. sertifikat-ikke-klarert dekker flere forhold, inkludert ukjente sertifiseringsinstanser, kjedefeil og navnebegrensninger. Feil-årsak-koden kan begrense diagnosen, men er reporter-levert tekst, ikke en universell parser-kontrakt. Ikke merk hver sertifikat-ikke-klarert rapport som et manglende mellomprodukt uten bevis. Start med policykonteksten og rapporterte mottakende endepunkt slik at et SMTP sertifikatproblem ikke forveksles med sts-webpki-invalid på en MTA-STS HTTPS-policyvert.

Sjekk sertifikatet som nådde avsenderen

En sertifikatbehandling som viser et fornyet sertifikat, fastslår ikke at hver SMTP lytter serverer det. Registrer serie- eller fingeravtrykk, gyldighetsintervall, kjede og testtidsstempel fra den faktiske autoriserte endepunktkontrollen. Sammenlign disse verdiene på tvers av mottaksrutene som er involvert i rapporter. En foreldet prosess, glemt sikkerhetskopivert eller ufullstendig distribusjon av lastbalanser kan la gamle sertifikater være aktive. Gjennomgå klokkenøyaktigheten når gyldighetsgrensene virker inkonsekvente, men ikke bytt klokker eller trustbutikker bare for å få et mislykket testbestått.

Gjengi et fornyelsesoverlappingsproblem

Den syntetiske øvelsen definerer et gammelt sertifikat som er gyldig til t=100 og et nytt gyldig fra t=90 til t=200. Ved t=110, mislykkes en lytter som fortsatt betjener det gamle sertifikatet modellens gyldighetsvindusjekk, mens en lytter som betjener det nye sertifikatet består det. Dette reproduserer distribusjonsforskjellen uten å generere et reelt sertifikat. Det beviser ikke kjedetillit, navnetilpasning, tilbakekallingsadferd eller implementeringens grensekonvensjoner. De trenger en ekte TLS validator og kontrollert endepunktbevis.

Undersøk tillit uten å omgå den

Referanser: RFC 8461 §4.2, RFC 7672 §3.1.1.

Fang bladet og servert mellomkjede, og sammenlign deretter reporterens årsak med et vedlikeholdt testmiljø. En utsteder som er klarert av én lokal maskin, blir kanskje ikke akseptert av den berørte avsenderen. Manglende mellomprodukter, et uventet selvsignert sertifikat og en policyspesifikk begrensning er forskjellige reparasjoner. Dokumenter den valgte valideringsmodellen. SMTP DANE med DANE-EE bruk har en annen tillitssemantikk fra Web PKI, så en STS-stil konklusjon om offentlige sertifiseringsmyndigheter kan ikke bare brukes på alle TLSA rapportere.

Lukk sløyfen for distribusjon og rapportering

Referanser: RFC 8460 §4.1.

Bruk den godkjente fornyelsen eller kjedekorreksjonen på hver berørte lytter, bekreft reload-atferd og behold bevis for det presenterte sertifikatet etter endringen. Sammenlign rapporter hvis observasjonsperioder faller etter reparasjonen og ta hensyn til aggregeringsforsinkelser. Planlegg fornyelsesovervåking med nok ledetid for eierskap og utrulling, og overvåk separat om det nye sertifikatet faktisk er distribuert. Ikke senk automatisk en håndhevende transportpolicy for å skjule sertifikatfeil. Denne veiledningen registrerer kun kontrollerte laboratorietester; den fornyer ikke produksjonssertifikater, endrer produksjonstillatelseslagre eller demonstrerer produksjonsgjenoppretting.

Beholdt historisk bevis og nåværende kontroller

Transportobservasjonene nedenfor ble fanget 7. november 2026 og inspisert, ikke gjentatt som nettverkstester, for denne gjennomgangen. De nye offline-modellkontrollene registreres separat.

Den beholdte loopback-registreringen inkluderer et sertifikat signert av den klarerte laboratorie-CA hvis gyldighet ble avsluttet før testen; det mislykkes med bekreftelseskode 10, sertifikatet har utløpt. Et eget selvsignert blad mislykkes med bekreftelseskode 18, selvsignert sertifikat. Den gyldige kontrollen lykkes med det samme forventede vertsnavnet. Tidsstemplede håndtrykkbevis og offentlige sertifikater beholdes, slik at utløps- og tillitssvikt kan inspiseres separat. Private nøkler er midlertidige og fjernet. Faktisk utrulling av tjenestefornyelse og verifisering av distribusjon av alle lyttere forblir utenfor denne laboratoriet. Den historiske transportløperen krever Python med kryptografi og loopback-sockets. Resultatene er begrenset laboratoriebevis, ikke gjeldende tjenestehelse eller produksjonsinteroperabilitet.

Primærkildegrunnlag

Feltdefinisjonene og rapporteringsgrensene kommer fra RFC 8460 , SMTP TLS -rapportering, avsnitt 3 og 4. Hvor STS-validering er diskutert, konsulter RFC 8461. Driftsanbefalingene skilles fra protokollkrav.

[ Takeaway ]

Sammenlign observasjoner under riktig STS- eller DANE tillitsmodell.

[Etter rolle]

Hva dette betyr for deg

Velg din rolle for praktiske neste trinn.

IT / Mail Admin

Inspiser hver servert kjede

Gjengi den navngitte tilstanden før du gjør en konfigurasjonsendring.

Neste trinn

  1. Ta opp sertifikatet som faktisk ble levert.
  2. Sammenlign gyldighetsvinduer og mellomliggende kjeder.
  3. Bekreft at hver berørte prosess lastet det nye sertifikatet på nytt.

CISO / SecOps

Hold tillitsmodeller eksplisitte

Hold sikkerhetskonklusjonene proporsjonale med autentiserte bevis.

Neste trinn

  1. Undersøk tillitsfeil uten å deaktivere validering.
  2. Skille Web PKI fra DANE-EE trust.
  3. Bevar før-og-etter-endepunkt-fingeravtrykk.

Grunnlegger / Ikke-teknisk

Egen fornyelse og utplassering

Gjør resultatet nyttig for den som er ansvarlig for tjenestekontinuitet.

Neste trinn

  1. Spor sertifikatdistribusjon samt fornyelse.
  2. Ledetid for fondets utløp og en ansvarlig responder.
  3. Inkluder reservelyttere i fornyelse av eierskap.

[ Vanlige spørsmål ]

Ofte stilte spørsmål

Betyr sertifikat-ikke-klarert utløpt?

Ikke nødvendigvis. Den dekker flere tillits- og kjedesvikt.

RFC 8460 §4.3.1

Beviser vellykket fornyelse distribusjon?

Nei. En lytter kan fortsette å betjene det forrige sertifikatet.

Hva bør endepunktbevis inkludere?

Presentert sertifikatidentitet, gyldighetsintervall, kjede, rute og tidsstempel.

Hva tester den lokale armaturen?

Gyldighetsvinduene for de nye offline armaturene. Separat, de beholdte 7. november loopback-fangstdokumenter utløper og tillitssvikt; ingen nettverkstest ble kjørt på nytt for denne anmeldelsen.

Bør sertifikatvalidering omgås?

Nei. En bypass kan ikke demonstrere en kompatibel produksjonsforbindelse.

Kan ulike avsendere ha ulike tillitsutfall?

Ja. Valideringskontekst og tillitsbutikker kan variere.

RFC 8461 §4.2

Er DANE-EE og offentlig CA-validering identiske?

Nei. Deres tillitsmodeller er forskjellige.

RFC 7672 §3.1.1

Når skal en reparasjon vises i rapporter?

Etter at relevante etterreparasjonsøkter samles og leveres.

RFC 8460 §4.1

[ Kilder ]

Kilder

  1. RFC 7672

    Seksjoner §3.1.1

  2. RFC 8460

    Seksjoner §4.1 · §4.3.1 · §4.3.2

  3. RFC 8461

    Seksjoner §4.2

[ Ordliste ]

Ordliste

Fremlagt sertifikat
Sertifikatet leveres faktisk av den testede TLS lytteren, i stedet for en fornyelsesartefakt lagret andre steder.
Stol på anker
En rot-CA klarert i den avsendende MTA-valideringskonteksten for STS-sertifikatverifisering.

RFC 8461 §4.2

DANKE-EE
TLSA-bruk 3 autentiserer endeenhetssertifikatet gjennom den DNSSEC-beskyttede tilknytningen, med forskjellig navn og utløpssemantikk fra STS.

RFC 7672 §3.1.1

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.

Regjeringer Store bedrifter Tier-1 finansinstitusjoner

SaaS · Dedikert leieforhold · Air-gaped on-prem · BYOK-kryptering

Kunnskapsbase