Gjør fornyelse til en tjenestekontinuitetsoppgave
Fornyelse av HTTPS-sertifikatet for en MTA-STS policyverten er fullført bare når det riktige sertifikatet faktisk blir servert ved det nødvendige endepunktet og en validerende klient kan hente policyen. Et vellykket utstedelsesvarsel fastslår ikke distribusjon, fullstendighet eller tilgjengelighet av tillitskjeden. Organiser arbeidet rundt den kjørende tjenesten i stedet for sertifikatbestillingen.
Denne veiledningen foreslår en fornyelseskontroll og en fiktiv feilgjennomgang. Den utsteder ikke sertifikater, inspiserer private nøkler, endrer hosting eller kobler til et kundedomene. Originalt sertifikat og HTTP-observasjoner er fortsatt nødvendig. Eiere bør bli enige om den godkjente distribusjons- og tilbakestillingsprosedyren før en operatør berører tjenesten.
Inventar de to sertifikatflatene
Policy-host-sertifikatet autentiserer et navn som mta-sts.example.com under HTTPS-henting. Mottakende SMTP servere presenterer separate sertifikater for deres MX -vertsnavn. Disse tjenestene kan ha forskjellige eiere, fornyelsessystemer og utløpsdatoer. Å fornye det ene løser ikke det andre, selv når begge administreres av samme vertsleverandør. RFC 8461 avsnitt 3.3 og 4.2
Registrer vertsnavnet for policyen, ansvarlig team, distribusjonsplattform, gjeldende fingeravtrykk for offentlig sertifikat, gyldighetsintervall og tiltenkt fornyelsesmekanisme. Inkluder hver adresse eller serveringsnivå som kan svare for endepunktet. Et sertifikats notBefore og notAfter avgrenser gyldighetsperioden, mens stivalidering også avhenger av andre sertifikatbegrensninger og tillit. En tilsynelatende fremtidig utløpsdato alene er ikke et vellykket valideringsresultat. RFC 5280 avsnitt 4.1.2.5 og 6
Bekreft identitet og kjede før distribusjon
Policyverten må presentere et ikke-utløpt sertifikat som er gyldig for dens nødvendige DNS identitet og lenking til en rot som er klarert av avsenderen MTA. Delegere vertskap gjennom en CNAME gjør ikke et sertifikat for leverandørens vertsnavn tilstrekkelig. Behold det opprinnelige policyvertsnavnet i valideringstester og dokumenter hvilken offentlig kjede serveren forventes å sende. RFC 8461 avsnitt 3.3 og 8.2
Bruk sertifikatets emnealternativnavn ved vurdering av tiltenkt tjenesteidentitet. RFC 9525 er den gjeldende generelle tjenesteidentitetsspesifikasjonen og forelder RFC 6125 , som RFC 8461 siterer. Hold MTA-STS applikasjonsspesifikke DNS-ID-regler eksplisitte i stedet for å erstatte urelatert applikasjonsatferd i det stille. Et vanlig navn som kan leses av mennesker, er ikke en grunn til å frafalle et vertsnavn som ikke samsvarer. RFC 9525 seksjoner 2 og 6
Planlegg nok tid til å komme seg trygt
Velg en intern fornyelsesfrist som gir tid til mislykket utstedelse, distribusjonsfeil og verifisering. Den passende marginen avhenger av sertifikatets levetid og operativt eierskap; det er ikke etablert noe universelt antall dager her. Tildel en ansvarlig person og en reservekontakt. En planlagt jobb uten en varseldestinasjon eller en eier er en ubekreftet avhengighet, ikke en fullstendig fornyelsesprosess.
Hold sertifikathåndteringen inne i det godkjente hemmelige styringssystemet. Bevispakken skal inneholde offentlige sertifikatdetaljer og valideringsutdata, ikke private nøkler eller kontolegitimasjon. Definer hva operatøren kan rulle tilbake, hvordan gjeldende gyldighet skal kontrolleres og hvilke feil som krever eskalering. Å gjenopprette et utløpt sertifikat fordi det var gårsdagens kjente konfigurasjon er ikke en nyttig gjenopprettingsplan.
Test det distribuerte endepunktet i stedet for sertifikatfilen
Etter en autorisert distribusjon skal den foreslåtte kontrollen identifisere det eksakte vertsnavnet, adressen, UTC-tid, observert kjede, navnevalideringsresultat og tillitsresultat. Der det finnes flere visningsnoder, behold omfanget som faktisk er sjekket. En operatørs vellykkede lokale test kan ikke bevise at hver ekstern sender stoler på den samme roten eller når den samme noden. Registrer disse grensene i stedet for å konvertere en observasjon til universell beredskap.
Bekreft deretter at den opprinnelige velkjente URL-en produserer en direkte HTTP 200 med den tiltenkte policyen. Sertifikatarbeid kan ved et uhell endre valg av virtuell vert, ruting eller applikasjonstilgangskontroller. MTA-STS forbyr å følge HTTP-omdirigeringer under henting, så en nettlesersuksess etter omdirigering er utilstrekkelig. Den gyldige TLS tilkoblingen og brukbare HTTP-svaret er distinkte akseptbetingelser. RFC 8461 avsnitt 3.2–3.3
Undersøk en fiktiv delvis distribusjon
Tenk på fiktiv example.com , hvis policy-vertsnavn betjenes av to kantnoder. Et fornyelsessystem får et nytt sertifikat, men bare én node laster det på nytt. Den andre fortsetter å betjene et utløpt sertifikat. En test som når den oppdaterte noden består; en avsender som når den andre noden kan ikke autentisere policyen. Disse observasjonene er oppfunnet og etablerer ikke noen reell leverandørs atferd.
Den foreslåtte undersøkelsen sammenligner offentlige fingeravtrykk og gyldighetsintervaller ved serveringsnodene, etterfulgt av autentisert henting ved det uendrede vertsnavnet. Det begynner ikke med å slappe av sertifikatkontroller eller slette oppdagelsesposten. Utbedringseieren ville fullføre den godkjente distribusjonen og bekrefte begge nodene. SMTP MX sertifikater trenger fortsatt sin egen validering fordi policy-vert-reparasjonen ikke sier noe om tilstanden deres.
Forstå cache-grensen under et strømbrudd
En støttende avsender med en gyldig, uutløpt bufret policy må fortsette å bruke den hvis den aktive policyen ikke kan hentes. En avsender uten en slik policy fortsetter som om MTA-STS var fraværende etter hentingsfeil. Cache-levetid gir derfor en begrenset kontinuitetsfordel for enkelte avsendere, ikke tillatelse til å la HTTPS-sertifikatet utløpe. Ulike avsendere kan legitimt okkupere forskjellige stater under samme strømbrudd. RFC 8461 avsnitt 3.3
Oppdagelses-IDen identifiserer policyforekomsten, ikke sertifikatets serienummer. Hvis bare sertifikatet endres og policyen forblir identisk, ikke anta at en ny ID er nødvendig for å gjøre fornyelsen effektiv. Hvis policyen også endres, følg oppdateringsrekkefølgen for body-before-ID og ta hensyn til bufrede retningslinjer. Behold sertifikatdistribusjon og revisjon av retningslinjer som separat gjennomgåbare endringer. RFC 8461 avsnitt 3.1 og 8.1
Ta vare på bevis for neste fornyelse
Lagre den godkjente distribusjonsposten, offentlige før-og-etter-sertifikatdetaljer, autentiserte henteresultater og eventuelle relevante TLS-RPT observasjoner. En policy Web PKI-feil tilhører policyendepunktundersøkelsen; et rapportert SMTP sertifikat-utløp gjelder mottakstilkoblingen. Sjekk hvilken kategori som faktisk ble rapportert. RFC 8460 avsnitt 4.3
Det gjeldende RFC 8461 errata-registeret inkluderer en rapportert korrigering av store bokstaver om utløpte mottaks-MTA-sertifikater; den tillater ikke utløpte sertifikater. Ingen original fornyelse eller vertsbevis leveres her. Den endelige operasjonsporten forblir en tidsstemplet demonstrasjon av den utplasserte tjenesten, gjennomgått av eieren. RFC 8461 feil