Gør fornyelse til en servicekontinuitetsopgave
Fornyelse af HTTPS-certifikatet for en MTA-STS politikværten er kun komplet, når det korrekte certifikat rent faktisk serveres ved det påkrævede slutpunkt, og en validerende klient kan hente politikken. En vellykket udstedelsesmeddelelse fastslår ikke implementering, tillidskædens fuldstændighed eller tilgængelighed. Organiser arbejdet omkring den kørende tjeneste i stedet for certifikatordren.
Denne vejledning foreslår en fornyelseskontrol og en fiktiv fejlgennemgang. Den udsteder ikke certifikater, inspicerer private nøgler, ændrer hosting eller opretter forbindelse til et kundedomæne. Originalt certifikat og HTTP-observationer er stadig påkrævet. Ejere bør blive enige om den godkendte implementerings- og tilbagerulningsprocedure, før en operatør rører tjenesten.
Inventar de to certifikatoverflader
Politik-værtscertifikatet godkender et navn såsom mta-sts.example.com under HTTPS-hentning. Modtagende SMTP servere præsenterer separate certifikater for deres MX værtsnavne. Disse tjenester kan have forskellige ejere, fornyelsessystemer og udløbsdatoer. At forny den ene løser ikke den anden, selv når begge administreres af den samme hostingudbyder. RFC 8461 afsnit 3.3 og 4.2
Registrer politikkens værtsnavn, ansvarligt team, implementeringsplatform, nuværende offentligt certifikats fingeraftryk, gyldighedsinterval og tilsigtet fornyelsesmekanisme. Inkluder alle adresser eller serveringsniveauer, der kan svare til slutpunktet. Et certifikats notBefore og notAfter afgrænser dets gyldighedsperiode, mens stivalidering også afhænger af andre certifikatbegrænsninger og tillid. En tilsyneladende fremtidig udløbsdato alene er ikke et vellykket valideringsresultat. RFC 5280 afsnit 4.1.2.5 og 6
Bekræft identitet og kæde før implementering
Politikværten skal fremvise et ikke-udløbet certifikat, der er gyldigt for dens påkrævede DNS identitet og kæde til en rod, som afsenderen har tillid til MTA. Uddelegering af hosting gennem en CNAME gør ikke et certifikat for udbyderens værtsnavn tilstrækkeligt. Bevar det oprindelige politikværtsnavn i valideringstests og dokumenter, hvilken offentlig kæde serveren forventes at sende. RFC 8461 afsnit 3.3 og 8.2
Brug certifikatets emne alternative navne, når du vurderer den påtænkte tjenesteidentitet. RFC 9525 er den nuværende generelle service-identitetsspecifikation og forælder RFC 6125 , som RFC 8461 citerer. Hold MTA-STS 's applikationsspecifikke DNS-ID regler eksplicitte i stedet for i det stille at erstatte ikke-relateret applikationsadfærd. Et almindeligt navn, der kan læses af mennesker, er ikke en grund til at give afkald på et hostnavn-uoverensstemmelse. RFC 9525 afsnit 2 og 6
Planlæg nok tid til at komme sig sikkert
Vælg en intern fornyelsesfrist, der giver tid til mislykket udstedelse, implementeringsfejl og verifikation. Den passende margin afhænger af certifikatets levetid og operationelle ejerskab; der er ikke etableret et universelt antal dage her. Tildel en ansvarlig person og en backup-kontakt. Et planlagt job uden en advarselsdestination eller en ejer er en ubekræftet afhængighed, ikke en komplet fornyelsesproces.
Hold certifikathåndtering inde i det godkendte hemmelige-styringssystem. Bevispakken skal indeholde offentlige certifikatdetaljer og valideringsoutput, ikke private nøgler eller kontolegitimationsoplysninger. Definer, hvad operatøren må rulle tilbage, hvordan den aktuelle gyldighed vil blive kontrolleret, og hvilke fejl der kræver eskalering. Gendannelse af et udløbet certifikat, fordi det var gårsdagens kendte konfiguration, er ikke en nyttig genopretningsplan.
Test det implementerede slutpunkt i stedet for certifikatfilen
Efter en autoriseret implementering skal den foreslåede kontrol identificere det nøjagtige værtsnavn, adresse, UTC-tid, observeret kæde, resultat af navnevalidering og tillidsresultat. Hvis der findes flere betjeningsknuder, behold det faktisk kontrollerede omfang. En operatørs vellykkede lokale test kan ikke bevise, at hver ekstern afsender har tillid til den samme rod eller når den samme node. Registrer disse grænser i stedet for at konvertere en observation til universel parathed.
Bekræft derefter, at den originale velkendte URL producerer en direkte HTTP 200 med den tilsigtede politik. Certifikatarbejde kan ved et uheld ændre valg af virtuel vært, routing eller applikationsadgangskontrol. MTA-STS forbyder at følge HTTP-omdirigeringer under hentning, så en browsersucces efter omdirigering er utilstrækkelig. Den gyldige TLS -forbindelse og brugbare HTTP-svar er forskellige acceptbetingelser. RFC 8461 afsnit 3.2-3.3
Undersøg en fiktiv delvis implementering
Overvej fiktive example.com , hvis politik-værtsnavn betjenes af to kantnoder. Et fornyelsessystem får et nyt certifikat, men kun én node genindlæser det. Den anden fortsætter med at tjene et udløbet certifikat. En test, der når frem til den opdaterede node, består; en afsender, der når den anden node, kan ikke godkende politikken. Disse observationer er opfundet og fastslår ikke nogen reel udbyders adfærd.
Den foreslåede undersøgelse sammenligner offentlige fingeraftryk og gyldighedsintervaller ved betjeningsknuderne, efterfulgt af autentificeret hentning ved det uændrede værtsnavn. Det begynder ikke med at lempe certifikattjek eller sletning af opdagelsesposten. Udbedringsejeren vil fuldføre den godkendte implementering og verificere begge noder. SMTP MX certifikater har stadig brug for deres egen validering, fordi policy-host-reparationen ikke siger noget om deres tilstand.
Forstå cachegrænsen under et udfald
En understøttende afsender med en gyldig, uudløbet cachelagret politik skal fortsætte med at bruge den, hvis live-politikken ikke kan hentes. En afsender uden en sådan politik fortsætter, som om MTA-STS var fraværende efter hentningsfejl. Cache-levetid giver derfor en begrænset kontinuitetsfordel for nogle afsendere, ikke tilladelse til at lade HTTPS-certifikatet udløbe. Forskellige afsendere kan lovligt besætte forskellige stater under samme afbrydelse. RFC 8461 afsnit 3.3
Opdagelses-id'et identificerer politikforekomsten, ikke certifikatets serienummer. Hvis det kun er certifikatet, der ændres, og politikkens organ forbliver identisk, skal du ikke antage, at der kræves et nyt id for at gøre fornyelsen effektiv. Hvis politikken også ændres, skal du følge opdateringsrækkefølgen for body-before-ID og tage højde for cachelagrede politikker. Behold certifikatimplementering og politikrevision som ændringer, der kan gennemgås separat. RFC 8461 afsnit 3.1 og 8.1
Behold beviser til næste fornyelse
Gem den godkendte implementeringspost, offentlige før-og-efter-certifikatoplysninger, godkendte henteresultater og alle relevante TLS-RPT observationer. En politikweb-PKI-fejl hører til undersøgelsen af politikendepunkter; et rapporteret SMTP certifikatudløb vedrører den modtagende forbindelse. Tjek hvilken kategori der rent faktisk blev rapporteret. RFC 8460 afsnit 4.3
Det nuværende RFC 8461 errata-register inkluderer en rapporteret rettelse af store bogstaver om udløbne modtage-MTA-certifikater; det tillader ikke udløbne certifikater. Ingen originale fornyelses- eller hostingbeviser leveres her. Den endelige operationelle gate forbliver en tidsstemplet demonstration af den installerede tjeneste, gennemgået af dens ejer. RFC 8461 fejl