[ Transportbeveiliging ]

Verlopen of niet-vertrouwde certificaten in SMTP TLS rapporten

Onderscheid het verlopen van het falen van de vertrouwensketen, behoud het gerapporteerde eindpunt en valideer het certificaat dat daadwerkelijk wordt gebruikt na verlenging.

Door het EmailAuth -onderzoeksteam · 4 minuten lezen

[ Kernpunten ]

  • Verlopen en niet-vertrouwd zijn verschillende categorieën met verschillende mogelijke reparaties.
  • Inspecteer het certificaat dat elke betrokken luisteraar daadwerkelijk presenteert.
  • Vergelijk observaties onder het juiste STS- of DANE vertrouwensmodel.
Op deze pagina

Onderscheid het verlopen van het falen van de vertrouwensketen, behoud het gerapporteerde eindpunt en valideer het certificaat dat daadwerkelijk wordt gebruikt na verlenging.

Lees de resultaatcategorie nauwkeurig

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

certificaat verlopen betekent dat de melder een verlopen certificaat heeft waargenomen. certificaat-niet-vertrouwd omvat verschillende omstandigheden, waaronder onbekende certificeringsinstanties, ketenfouten en naambeperkingen. De foutredencode kan de diagnose beperken, maar is door de verslaggever verstrekte tekst en geen universeel parsercontract. Label niet elk certificaat-niet-vertrouwd rapport als een ontbrekend tussenproduct zonder bewijs. Begin met de beleidscontext en het gerapporteerde ontvangende eindpunt, zodat een SMTP -certificaatprobleem niet wordt verward met sts-webpki-invalid op een MTA-STS HTTPS-beleidshost.

Controleer het certificaat dat de afzender heeft bereikt

Een certificaatbeheerder die een vernieuwd certificaat toont, stelt niet vast dat elke SMTP listener dit bedient. Registreer serienummer of vingerafdruk, geldigheidsinterval, keten en testtijdstempel van de daadwerkelijk geautoriseerde eindpuntcontrole. Vergelijk deze waarden voor de ontvangstroutes die door rapporten worden geïmpliceerd. Een verouderd proces, een vergeten back-uphost of een onvolledige implementatie van de load-balancer kunnen oude certificaten actief laten. Controleer de kloknauwkeurigheid als de geldigheidsgrenzen inconsistent lijken, maar verander de klok niet en vertrouw niet op opslag alleen maar om een ​​mislukte test te laten slagen.

Reproduceer een vernieuwingsoverlappingsprobleem

De synthetische oefening definieert een oud certificaat geldig tot t=100 en een nieuw certificaat geldig van t=90 tot t=200. Op t=110, faalt een luisteraar die nog steeds het oude certificaat levert, voor de geldigheidscontrole van het model, terwijl een luisteraar die het nieuwe certificaat bedient, wel slaagt. Dit reproduceert het implementatieverschil zonder een echt certificaat te genereren. Het bewijst geen ketenvertrouwen, naammatching, intrekkingsgedrag of de grensconventies van de implementatie. Deze hebben een echte TLS validator en gecontroleerd eindpuntbewijs nodig.

Onderzoek vertrouwen zonder het te omzeilen

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

Leg het blad vast en serveer de tussenketen, en vergelijk vervolgens de reden van de verslaggever met een onderhouden testomgeving. Een uitgever die door één lokale machine wordt vertrouwd, wordt mogelijk niet geaccepteerd door de betreffende afzender. Ontbrekende tussenproducten, een onverwacht zelfondertekend certificaat en een beleidsspecifieke beperking zijn verschillende reparaties. Documenteer het geselecteerde validatiemodel. SMTP DANE met DANE-EE-gebruik heeft een andere vertrouwenssemantiek dan Web PKI, dus een STS-achtige conclusie over openbare certificeringsinstanties kan niet zomaar op iedereen worden toegepast TLSA rapport.

Sluit de lus op het gebied van implementatie en rapportage

Referenties: RFC 8460 §4.1.

Pas de goedgekeurde verlenging of ketencorrectie toe op elke betrokken luisteraar, verifieer het herlaadgedrag en bewaar het bewijs van het gepresenteerde certificaat na de wijziging. Vergelijk rapporten waarvan de observatieperioden na de reparatie vallen en houd rekening met aggregatievertragingen. Plan vernieuwingsmonitoring met voldoende doorlooptijd voor eigendom en uitrol, en controleer afzonderlijk of het nieuwe certificaat daadwerkelijk wordt geïmplementeerd. Verlaag niet automatisch een afdwingend transportbeleid om certificaatfouten te verbergen. In deze gids worden alleen gecontroleerde laboratoriumtests vastgelegd; het vernieuwt geen productiecertificaten, wijzigt geen productievertrouwenswinkels en demonstreert geen productieherstel.

Historisch bewijsmateriaal en huidige controles bewaard

De onderstaande transportwaarnemingen zijn op 7 november 2026 vastgelegd en voor deze beoordeling geïnspecteerd, en niet opnieuw uitgevoerd als netwerktests. De nieuwe offline modelcontroles worden apart vastgelegd.

De bewaarde loopback-opname bevat een certificaat dat is ondertekend door de vertrouwde laboratorium-CA waarvan de geldigheid vóór de test is geëindigd; het mislukt met verificatiecode 10, certificaat is verlopen. Een afzonderlijk zelfondertekend blad mislukt met verificatiecode 18, zelfondertekend certificaat. De geldige controle slaagt met dezelfde verwachte hostnaam. Handshake-bewijs met tijdstempel en openbare certificaten worden bewaard, waardoor verval- en vertrouwensfouten afzonderlijk kunnen worden geïnspecteerd. Privésleutels zijn tijdelijk en worden verwijderd. De daadwerkelijke uitrol van de servicevernieuwing en de verificatie van de implementatie door alle luisteraars blijven buiten dit lab. De historische transportrunner vereist Python met cryptografie en loopback-sockets. De uitkomsten zijn begrensd laboratoriumbewijs, en niet de huidige servicegezondheid of productie-interoperabiliteit.

Primaire bronbasis

De velddefinities en rapportagelimieten komen uit RFC 8460 , SMTP TLS -rapportage, secties 3 en 4. Raadpleeg waar STS-validatie wordt besproken RFC 8461. De operationele aanbevelingen onderscheiden zich van protocolvereisten.

[ Afhaalmaaltijden ]

Vergelijk observaties onder het juiste STS- of DANE vertrouwensmodel.

[ Per rol ]

Wat dit voor jou betekent

Kies jouw rol voor praktische vervolgstappen.

IT/Mailbeheerder

Inspecteer elke bediende keten

Reproduceer de genoemde voorwaarde voordat u een configuratiewijziging aanbrengt.

Volgende stappen

  1. Leg het daadwerkelijk afgegeven certificaat vast.
  2. Vergelijk geldigheidsvensters en tussenliggende ketens.
  3. Controleer of elk getroffen proces het nieuwe certificaat opnieuw heeft geladen.

CISO / SecOps

Houd vertrouwensmodellen expliciet

Houd beveiligingsconclusies in verhouding tot authentiek bewijsmateriaal.

Volgende stappen

  1. Onderzoek vertrouwensfouten zonder de validatie uit te schakelen.
  2. Onderscheid Web PKI van DANE-EE-vertrouwen.
  3. Behoud vingerafdrukken van vóór en na het eindpunt.

Oprichter / Niet-technisch

Eigen vernieuwing en inzet

Maak het resultaat bruikbaar voor de persoon die verantwoordelijk is voor de continuïteit van de dienstverlening.

Volgende stappen

  1. Volg de implementatie en verlenging van certificaten.
  2. Doorlooptijd van het verstrijken van het fonds en een verantwoordelijke responder.
  3. Neem back-uplisteners op in het verlengingseigendom.

[ Veelgestelde vragen ]

Veelgestelde vragen

Betekent certificaat-niet-vertrouwd dat het is verlopen?

Niet noodzakelijkerwijs. Het omvat meerdere vertrouwens- en ketenfouten.

RFC 8460 §4.3.1

Bewijst succesvolle verlenging implementatie?

Nee. Een luisteraar kan het vorige certificaat blijven aanbieden.

Wat moet het eindpuntbewijs omvatten?

De gepresenteerde certificaatidentiteit, geldigheidsinterval, keten, route en tijdstempel.

Wat test het lokale armatuur?

Het nieuwe offline armatuur modelleert geldigheidsperioden. Afzonderlijk, de behouden loopback-opname van 7 november, verlopen documenten en vertrouwensfouten; Voor deze beoordeling is er geen netwerktest opnieuw uitgevoerd.

Moet certificaatvalidatie worden omzeild?

Nee. Een bypass kan geen conforme productieaansluiting aantonen.

Kunnen verschillende afzenders verschillende vertrouwensresultaten hebben?

Ja. Validatiecontext en truststores kunnen verschillen.

RFC 8461 §4.2

Zijn DANE-EE en publieke CA-validatie identiek?

Nee. Hun vertrouwensmodellen verschillen.

RFC 7672 §3.1.1

Wanneer moet een reparatie in rapporten verschijnen?

Na de relevante post-reparatiesessies worden deze verzameld en afgeleverd.

RFC 8460 §4.1

[ Bronnen ]

Bronnen

  1. RFC 7672

    Secties §3.1.1

  2. RFC 8460

    Secties §4.1 · §4.3.1 · §4.3.2

  3. RFC 8461

    Secties §4.2

[ Glossarium ]

Glossarium

Gepresenteerd certificaat
Het certificaat dat daadwerkelijk door de geteste TLS listener is geleverd, in plaats van een vernieuwingsartefact dat elders is opgeslagen.
Vertrouwen anker
Een root-CA die wordt vertrouwd in de verzendende MTA-validatiecontext voor STS-certificaatverificatie.

RFC 8461 §4.2

DANE-EE
TLSA-gebruik 3 verifieert het eindentiteitscertificaat via de door DNSSEC beschermde associatie, met een andere naam en vervalsemantiek dan STS.

RFC 7672 §3.1.1

Herkomst onderneming

Waarom top financiële instellingen en overheden hebben hun e-mailbeveiligingsdashboards stopgezet.

Traditionele platforms voor e-mailauthenticatie verkopen u een dashboard en vragen uw technici om het werk te doen. In omgevingen waar veel op het spel staat, betekent handmatig toezicht vertraagde handhaving, configuratieafwijking en niet-gecontroleerde schaduwdomeinen.

EmailAuth is het agentische e-mailherkomstplatform. Onze agenten handhaven p=reject, houd externe afzenders op één lijn en verplaats uw domeinen naar vol RFC 9989 compliance, de nieuwe DMARC standaard, met 'human-in-the-loop'-auditeerbaarheid.

Regeringen Grote ondernemingen Tier-1 financiële instellingen

SaaS · Toegewijde huur · Air-gapped on-premise · BYOK-encryptie

Kennisbank