[ Transportsikkerhed ]

Udløbne eller ikke-pålidelige certifikater i SMTP TLS rapporter

Skelne udløb fra tillidskædefejl, bevar det rapporterede slutpunkt og valider det certifikat, der rent faktisk vises efter fornyelse.

Af EmailAuth -forskningsteamet · 4 min læst

[Nøglepunkter]

  • Udløbet og ikke-pålidt er forskellige kategorier med forskellige mulige reparationer.
  • Undersøg det certifikat, som hver berørt lytter faktisk fremviser.
  • Sammenlign observationer under den korrekte STS- eller DANE tillidsmodel.
På denne side

Skelne udløb fra tillidskædefejl, bevar det rapporterede slutpunkt og valider det certifikat, der rent faktisk vises efter fornyelse.

Læs resultatkategorien præcist

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

certifikat udløbet betyder, at indberetteren har observeret et udløbet certifikat. certifikat-ikke-tillid dækker flere forhold, herunder ukendte certificeringsmyndigheder, kædefejl og navnebegrænsninger. Fejlårsagskoden kan indsnævre diagnosen, men er tekst leveret af reporter, ikke en universel parserkontrakt. Mærk ikke alle certifikater, der ikke er tillid til, som et manglende mellemprodukt uden bevis. Start med politikkonteksten og rapporterede modtagende slutpunkt, så et SMTP -certifikatproblem ikke forveksles med sts-webpki-invalid på en MTA-STS HTTPS-politikvært.

Tjek det certifikat, der nåede afsenderen

En certifikatadministrator, der viser et fornyet certifikat, fastslår ikke, at alle SMTP lyttere betjener det. Registrer serie- eller fingeraftryk, gyldighedsinterval, kæde og testtidsstempel fra det faktiske autoriserede slutpunktstjek. Sammenlign disse værdier på tværs af de modtagende ruter, der er impliceret af rapporter. En forældet proces, glemt backup-vært eller ufuldstændig load-balancer-implementering kan efterlade gamle certifikater aktive. Gennemgå urnøjagtigheden, når gyldighedsgrænserne forekommer inkonsekvente, men skift ikke ure eller trust-butikker blot for at bestå en mislykket prøve.

Genskab et fornyelsesoverlapningsproblem

Den syntetiske øvelse definerer et gammelt certifikat gyldigt indtil t=100 og et nyt gyldigt fra t=90 indtil t=200. Ved t=110, der stadig betjener det gamle certifikat, modellens validitetsvinduekontrol, mens en lytter, der betjener det nye certifikat, består det. Dette reproducerer distinktionen uden at generere et rigtigt certifikat. Det beviser ikke kædetillid, navnematchning, tilbagekaldelsesadfærd eller implementeringens grænsekonventioner. De har brug for en ægte TLS validator og kontrolleret slutpunktsbevis.

Undersøg tillid uden at omgå den

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

Fang bladet og serveret mellemkæde, og sammenlign derefter reporterens årsag med et vedligeholdt testmiljø. En udsteder, som én lokal maskine har tillid til, accepteres muligvis ikke af den berørte afsender. Manglende mellemprodukter, et uventet selvsigneret certifikat og en politikspecifik begrænsning er forskellige reparationer. Dokumenter den valgte valideringsmodel. SMTP DANE med DANE-EE brug har en anden tillidssemantik fra Web PKI, så en STS-lignende konklusion om offentlige certificeringsmyndigheder kan ikke blot anvendes på alle TLSA rapport.

Luk sløjfen om implementering og rapportering

Referencer: RFC 8460 §4.1.

Anvend den godkendte fornyelse eller kædekorrektion på hver berørt lytter, bekræft genindlæsningsadfærd og behold bevis for det præsenterede certifikat efter ændringen. Sammenlign rapporter, hvis observationsperioder falder efter reparationen, og tag hensyn til aggregeringsforsinkelser. Planlæg fornyelsesovervågning med nok gennemløbstid til ejerskab og udrulning, og overvåg separat, om det nye certifikat rent faktisk implementeres. Sænk ikke automatisk en håndhævende transportpolitik for at skjule certifikatfejl. Denne vejledning registrerer kun kontrollerede laboratorietests; det fornyer ikke produktionscertifikater, ændrer produktionstillidsbutikker eller demonstrerer produktionsgenopretning.

Beholdt historiske beviser og aktuelle kontroller

Transportobservationerne nedenfor blev fanget den 7. november 2026 og inspiceret, ikke genudført som netværkstest, til denne gennemgang. De nye offline-modeltjek registreres separat.

Den bibeholdte loopback-opsamling inkluderer et certifikat, der er underskrevet af den betroede laboratorie-CA, hvis gyldighed sluttede før testen; det mislykkes med verifikationskode 10, certifikatet er udløbet. Et separat selvsigneret blad mislykkes med verifikationskode 18, selvsigneret certifikat. Den gyldige kontrol lykkes med det samme forventede værtsnavn. Tidsstemplede håndtryksbeviser og offentlige certifikater bevares, så udløb og tillidssvigt kan inspiceres separat. Private nøgler er midlertidige og fjernes. Faktisk udrulning af tjenestefornyelse og verifikation af implementering af alle lyttere forbliver uden for dette laboratorium. Den historiske transportløber kræver Python med kryptografi og loopback sockets. Dets resultater er afgrænset laboratoriebevis, ikke aktuel servicesundhed eller produktionsinteroperabilitet.

Primær kildegrundlag

Feltdefinitionerne og rapporteringsgrænserne kommer fra RFC 8460 , SMTP TLS -rapportering, afsnit 3 og 4. Hvor STS-validering diskuteres, konsulteres RFC 8461. De operationelle anbefalinger er adskilt fra protokolkrav.

[ Takeaway ]

Sammenlign observationer under den korrekte STS- eller DANE tillidsmodel.

[Efter rolle]

Hvad betyder det for dig

Vælg din rolle for praktiske næste trin.

IT / Mail Admin

Undersøg hver serveret kæde

Genskab den navngivne tilstand, før du foretager en konfigurationsændring.

Næste trin

  1. Fang det certifikat, der rent faktisk blev serveret.
  2. Sammenlign gyldighedsvinduer og mellemliggende kæder.
  3. Bekræft, at hver berørte proces genindlæste det nye certifikat.

CISO / SecOps

Hold tillidsmodeller eksplicitte

Hold sikkerhedskonklusioner proportionale med autentificerede beviser.

Næste trin

  1. Undersøg tillidsfejl uden at deaktivere validering.
  2. Adskille Web PKI fra DANE-EE trust.
  3. Bevar før-og-efter-endepunkts fingeraftryk.

Grundlægger / Ikke-teknisk

Egen fornyelse og ibrugtagning

Gør resultatet nyttigt for den person, der er ansvarlig for servicekontinuitet.

Næste trin

  1. Spor certifikatimplementering samt fornyelse.
  2. Gennemløbstid for fondens udløb og en ansvarlig responder.
  3. Inkluder backuplyttere i fornyelse af ejerskab.

[ Ofte stillede spørgsmål ]

Ofte stillede spørgsmål

Betyder certifikatet, der ikke er tillid til, udløbet?

Ikke nødvendigvis. Det dækker over flere tillids- og kædesvigt.

RFC 8460 §4.3.1

Beviser vellykket fornyelse implementering?

Nej. En lytter kan fortsætte med at betjene det tidligere certifikat.

Hvad skal endepunktsbevis omfatte?

Den præsenterede certifikatidentitet, gyldighedsinterval, kæde, rute og tidsstempel.

Hvad tester det lokale armatur?

De nye offline armaturers gyldighedsvinduer. Separat udløber de bibeholdte loopback-fangstdokumenter den 7. november og tillidsfejl; ingen netværkstest blev kørt igen for denne anmeldelse.

Skal certifikatvalidering omgås?

Nej. En bypass kan ikke påvise en kompatibel produktionsforbindelse.

Kan forskellige afsendere have forskellige tillidsresultater?

Ja. Valideringskontekst og tillidsbutikker kan variere.

RFC 8461 §4.2

Er DANE-EE og offentlig CA-validering identiske?

Nej. Deres tillidsmodeller er forskellige.

RFC 7672 §3.1.1

Hvornår skal en reparation fremgå af rapporter?

Efter relevante post-reparations sessioner aggregeres og leveres.

RFC 8460 §4.1

[ Kilder ]

Kilder

  1. RFC 7672

    Afsnit §3.1.1

  2. RFC 8460

    Afsnit §4.1 · §4.3.1 · §4.3.2

  3. RFC 8461

    Afsnit §4.2

[ Ordliste ]

Ordliste

Forevist certifikat
Certifikatet faktisk leveret af den testede TLS lytter, snarere end en fornyelsesartefakt, der er gemt andetsteds.
Tillid til anker
En rod-CA har tillid til den afsendende MTA-valideringskontekst til STS-certifikatbekræftelse.

RFC 8461 §4.2

DANKER-EE
TLSA-brug 3 autentificerer slutenhedscertifikatet gennem den DNSSEC-beskyttede tilknytning med en anden navne- og udløbssemantik fra STS.

RFC 7672 §3.1.1

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.

regeringer Store virksomheder Tier-1 finansielle institutioner

SaaS · Dedikeret lejemål · Air-gapped on-prem · BYOK-kryptering

Vidensbase