Maak van vernieuwing een taak voor servicecontinuïteit
Het vernieuwen van het HTTPS-certificaat voor een MTA-STS policy host is pas voltooid als het juiste certificaat daadwerkelijk op het vereiste eindpunt wordt aangeboden en een validerende client het beleid kan ophalen. Een succesvolle melding van uitgifte garandeert geen implementatie, volledigheid of beschikbaarheid van de vertrouwensketen. Organiseer het werk rond de actieve service in plaats van rond de certificaatvolgorde.
Deze gids stelt een vernieuwingscontrole en een fictieve mislukkingsbeoordeling voor. Het geeft geen certificaten uit, inspecteert geen privésleutels, wijzigt de hosting en maakt geen verbinding met een klantdomein. Originele certificaat- en HTTP-waarnemingen zijn nog steeds vereist. Eigenaren moeten overeenstemming bereiken over de goedgekeurde implementatie- en terugdraaiprocedure voordat een operator de service aanraakt.
Inventariseer de twee certificaatoppervlakken
Het policy-host-certificaat verifieert een naam zoals mta-sts.example.com tijdens het ophalen van HTTPS. Ontvangende SMTP servers presenteren afzonderlijke certificaten voor hun MX hostnamen. Deze services kunnen verschillende eigenaren, verlengingssystemen en vervaldata hebben. Het verlengen van de één lost de ander niet op, ook al worden beide beheerd door dezelfde hostingprovider. RFC 8461 paragrafen 3.3 en 4.2
Registreer de hostnaam van het beleid, het verantwoordelijke team, het implementatieplatform, de huidige vingerafdruk van het openbare certificaat, het geldigheidsinterval en het beoogde verlengingsmechanisme. Neem elk adres of elke weergavelaag op die voor het eindpunt kan antwoorden. NotBefore en notAfter van een certificaat bakenen de geldigheidsperiode af, terwijl padvalidatie ook afhangt van andere certificaatbeperkingen en vertrouwen. Alleen een ogenschijnlijk toekomstige vervaldatum is geen succesvol validatieresultaat. RFC 5280 paragrafen 4.1.2.5 en 6
Verifieer de identiteit en keten vóór implementatie
De beleidshost moet een niet-verlopen certificaat overleggen dat geldig is voor de vereiste DNS identiteit en gekoppeld is aan een root die wordt vertrouwd door de verzendende partij MTA. Hosting delegeren via een CNAME maakt een certificaat voor de hostnaam van de provider niet voldoende. Behoud de oorspronkelijke hostnaam van het beleid in validatietests en documenteer welke openbare keten de server naar verwachting zal verzenden. RFC 8461 paragrafen 3.3 en 8.2
Gebruik de alternatieve namen van het certificaat bij het beoordelen van de beoogde service-identiteit. RFC 9525 is de huidige algemene service-identiteitsspecificatie en verouderd RFC 6125 , die RFC 8461 citeert. Houd de applicatiespecifieke DNS-ID-regels van MTA-STS expliciet in plaats van stilzwijgend niet-gerelateerd applicatiegedrag te vervangen. Een voor mensen leesbare algemene naam is geen reden om af te zien van een niet-overeenkomende hostnaam. RFC 9525 secties 2 en 6
Plan voldoende tijd om veilig te herstellen
Kies een interne verlengingsdeadline die tijd overlaat voor mislukte uitgifte, implementatiefouten en verificatie. De juiste marge is afhankelijk van de levensduur van het certificaat en het operationele eigendom; hier wordt geen universeel aantal dagen vastgesteld. Wijs een verantwoordelijke persoon en een back-upcontact aan. Een geplande taak zonder waarschuwingsbestemming of eigenaar is een niet-geverifieerde afhankelijkheid en geen volledig verlengingsproces.
Houd de certificaatverwerking binnen het goedgekeurde systeem voor geheimbeheer. Het bewijspakket moet openbare certificaatgegevens en validatie-uitvoer bevatten, geen privésleutels of accountreferenties. Bepaal wat de operator mag terugdraaien, hoe de huidige geldigheid wordt gecontroleerd en welke fouten moeten worden geëscaleerd. Het herstellen van een verlopen certificaat omdat het de bekende configuratie van gisteren was, is geen nuttig herstelplan.
Test het geïmplementeerde eindpunt in plaats van het certificaatbestand
Na een geautoriseerde implementatie moet de voorgestelde controle de exacte hostnaam, het adres, de UTC-tijd, de waargenomen keten, het naamvalidatieresultaat en het vertrouwensresultaat identificeren. Als er meerdere serviceknooppunten bestaan, laat u het daadwerkelijk gecontroleerde bereik behouden. Een succesvolle lokale test van een operator kan niet bewijzen dat elke externe afzender dezelfde root vertrouwt of hetzelfde knooppunt bereikt. Leg die grenzen vast in plaats van één observatie om te zetten in universele gereedheid.
Controleer vervolgens of de oorspronkelijke bekende URL een directe HTTP 200 produceert met het beoogde beleid. Certificaatwerk kan per ongeluk de selectie van virtuele hosts, de routering of de toegangscontroles voor applicaties wijzigen. MTA-STS verbiedt het volgen van HTTP-omleidingen tijdens het ophalen, dus browsersucces na omleiding is onvoldoende. De geldige TLS verbinding en het bruikbare HTTP-antwoord zijn afzonderlijke acceptatievoorwaarden. RFC 8461 paragrafen 3.2–3.3
Onderzoek een fictieve gedeeltelijke implementatie
Neem het fictieve example.com , waarvan de beleidshostnaam wordt bediend door twee edge-knooppunten. Een vernieuwingssysteem verkrijgt een nieuw certificaat, maar slechts één knooppunt laadt het opnieuw. De andere blijft een verlopen certificaat aanbieden. Een test die het bijgewerkte knooppunt bereikt, is geslaagd; een afzender die het tweede knooppunt bereikt, kan het beleid niet verifiëren. Deze observaties zijn verzonnen en leggen niet het echte gedrag van een aanbieder vast.
Het voorgestelde onderzoek vergelijkt openbare vingerafdrukken en geldigheidsintervallen op de dienende knooppunten, gevolgd door geauthenticeerd ophalen op de ongewijzigde hostnaam. Het begint niet met het versoepelen van certificaatcontroles of het verwijderen van de ontdekkingsrecord. De eigenaar van het herstel voltooit de goedgekeurde implementatie en verifieert beide knooppunten. SMTP MX certificaten hebben nog steeds hun eigen validatie nodig omdat de policy-host-reparatie niets zegt over hun status.
Begrijp de cachegrens tijdens een storing
Een ondersteunende afzender met een geldig, nog niet verlopen cachebeleid moet dit blijven gebruiken als het live beleid niet kan worden opgehaald. Een afzender zonder een dergelijk beleid gaat door alsof MTA-STS afwezig was na een mislukte ophaalactie. De levensduur van de cache biedt daarom voor sommige afzenders een beperkt continuïteitsvoordeel en geen toestemming om het HTTPS-certificaat te laten verlopen. Verschillende afzenders kunnen tijdens dezelfde storing legitiem verschillende staten bezetten. RFC 8461 sectie 3.3
De detectie-ID identificeert het beleidsexemplaar, niet het serienummer van het certificaat. Als alleen het certificaat verandert en de polisinstantie identiek blijft, mag u er niet van uitgaan dat er een nieuw identiteitsbewijs nodig is om de verlenging effectief te maken. Als het beleid ook verandert, volgt u de updatevolgorde van de body-before-ID en houdt u rekening met het in de cache opgeslagen beleid. Bewaar de certificaatimplementatie en beleidsrevisie als afzonderlijk controleerbare wijzigingen. RFC 8461 paragrafen 3.1 en 8.1
Bewaar bewijsmateriaal voor de volgende verlenging
Bewaar de goedgekeurde implementatierecord, openbare voor-en-na-certificaatgegevens, geverifieerde ophaalresultaten en alle relevante gegevens TLS-RPT observaties. Een beleidsweb-PKI-fout behoort tot het beleidseindpuntonderzoek; een gemeld verlopen SMTP certificaat heeft betrekking op de ontvangende verbinding. Controleer welke categorie daadwerkelijk is gerapporteerd. RFC 8460 sectie 4.3
Het huidige RFC 8461 errata-register bevat een gerapporteerde hoofdlettercorrectie over verlopen ontvangende MTA-certificaten; het staat geen verlopen certificaten toe. Er wordt hier geen origineel verlengings- of hostingbewijs geleverd. De laatste operationele poort blijft een tijdstempeldemonstratie van de ingezette dienst, beoordeeld door de eigenaar. RFC 8461 errata