Tee uusimisesta palvelun jatkuvuustehtävä
HTTPS-varmenteen uusiminen käyttäjälle MTA-STS käytäntöisäntä on valmis vain, kun oikea varmenne todella toimitetaan vaaditussa päätepisteessä ja vahvistava asiakas voi noutaa käytännön. Onnistuneen myöntämisen ilmoitus ei vahvista käyttöönottoa, luottamusketjun täydellisyyttä tai saatavuutta. Järjestä työ käynnissä olevan palvelun ympärille varmennetilauksen sijaan.
Tässä oppaassa ehdotetaan uusimisen valvontaa ja kuvitteellista virhearviointia. Se ei myönnä varmenteita, tarkasta yksityisiä avaimia, muokkaa isännöintiä tai muodosta yhteyttä asiakkaan verkkotunnukseen. Alkuperäinen varmenne ja HTTP-havainnot vaaditaan edelleen. Omistajien tulee sopia hyväksytystä käyttöönotto- ja palautusmenettelystä ennen kuin käyttäjä koskettaa palvelua.
Inventoi kaksi sertifikaattipintaa
Käytäntöisäntävarmenne todentaa nimen, kuten mta-sts.example.com HTTPS-haun aikana. Vastaanottavat SMTP palvelimet esittävät erilliset varmenteet MX isäntänimilleen. Näillä palveluilla voi olla eri omistajat, uusimisjärjestelmät ja vanhentumispäivät. Yhden uusiminen ei korjaa toista, vaikka molempia hallinnoisi sama isännöintipalveluntarjoaja. RFC 8461 kohdat 3.3 ja 4.2
Tallenna käytännön isäntänimi, vastuullinen tiimi, käyttöönottoalusta, nykyinen julkisen varmenteen sormenjälki, voimassaoloaika ja suunniteltu uusimismekanismi. Sisällytä kaikki osoitteet tai käyttötasot, jotka voivat vastata päätepisteeseen. Varmenteen notBefore ja notAfter rajaavat sen voimassaoloajan, kun taas polun validointi riippuu myös muista varmenteen rajoituksista ja luottamuksesta. Näennäisesti tuleva voimassaolopäivä ei yksinään ole onnistunut validointitulos. RFC 5280 kohdat 4.1.2.5 ja 6
Tarkista henkilöllisyys ja ketju ennen käyttöönottoa
Käytäntöisännän on esitettävä vanhentumaton varmenne, joka on voimassa sen vaaditulle DNS identiteetille ja ketjuttaa lähettäjän luottamaan juuriin. MTA. Isännöinnin delegointi a CNAME ei tee riittävää varmennetta palveluntarjoajan isäntänimelle. Säilytä alkuperäinen käytännön isäntänimi vahvistustesteissä ja dokumentoi, mikä julkinen ketju palvelimen odotetaan lähettävän. RFC 8461 kohdat 3.3 ja 8.2
Käytä varmenteen aiheen vaihtoehtoisia nimiä arvioidessasi aiottua palveluidentiteettiä. RFC 9525 on nykyinen yleinen palveluidentiteettispesifikaatio, ja se on vanhentunut RFC 6125 , jonka RFC 8461 lainaa. Pidä MTA-STS :n sovelluskohtaiset DNS-ID-säännöt eksplisiittisinä sen sijaan, että korvaat ne äänettömästi asiaankuulumattomilla sovelluksilla. Ihmisen luettavissa oleva yleinen nimi ei ole syy luopua isäntänimen yhteensopimattomuudesta. RFC 9525 kohdat 2 ja 6
Varaa riittävästi aikaa turvalliseen palautumiseen
Valitse sisäinen uusimisen määräaika, joka jättää aikaa epäonnistuneelle myöntämiselle, käyttöönottovirheille ja vahvistukselle. Asianmukainen marginaali riippuu sertifikaatin käyttöiästä ja operatiivisesta omistuksesta; tässä ei ole vahvistettu yleistä päivien lukumäärää. Määritä vastuuhenkilö ja varayhteyshenkilö. Ajoitettu työ ilman hälytyskohdetta tai omistajaa on vahvistamaton riippuvuus, ei täydellinen uusimisprosessi.
Säilytä varmenteiden käsittely hyväksytyssä salaisuuden hallintajärjestelmässä. Todistuspaketin tulee sisältää julkisen varmenteen tiedot ja vahvistustulos, ei yksityisiä avaimia tai tilin valtuustietoja. Määritä, mitä operaattori voi peruuttaa, kuinka virran voimassaolo tarkistetaan ja mitkä viat vaativat eskaloinnin. Vanhentuneen varmenteen palauttaminen, koska se oli eilen tunnettu kokoonpano, ei ole hyödyllinen palautussuunnitelma.
Testaa käyttöön otettu päätepiste varmennetiedoston sijaan
Valtuutetun käyttöönoton jälkeen ehdotetun tarkistuksen tulee tunnistaa tarkka isäntänimi, osoite, UTC-aika, havaittu ketju, nimen varmennustulos ja luottamustulos. Jos palvelusolmuja on useita, säilytä tosiasiallisesti tarkistettu laajuus. Operaattorin onnistunut paikallinen testi ei voi todistaa, että jokainen ulkoinen lähettäjä luottaa samaan juuriin tai saavuttaa saman solmun. Kirjaa nämä rajat muistiin sen sijaan, että muuttaisit yhden havainnon yleiseksi valmiudeksi.
Varmista sitten, että alkuperäinen tunnettu URL-osoite tuottaa suoran HTTP 200:n aiotulla käytännöllä. Varmennetyö voi vahingossa muuttaa virtuaalisen isännän valintaa, reititystä tai sovellusten käyttöoikeuksia. MTA-STS kieltää HTTP-uudelleenohjausten seuraamisen haun aikana, joten selaimen onnistuminen uudelleenohjauksen jälkeen on riittämätön. Kelvollinen TLS -yhteys ja käyttökelpoinen HTTP-vastaus ovat erilliset hyväksymisehdot. RFC 8461 kohdat 3.2–3.3
Tutki kuvitteellista osittaista käyttöönottoa
Harkitse kuvitteellista example.com , jonka käytännön isäntänimeä palvelee kaksi reunasolmua. Uusintajärjestelmä hankkii uuden varmenteen, mutta vain yksi solmu lataa sen uudelleen. Toinen jatkaa vanhentuneen varmenteen palvelemista. Päivitetyn solmun saavuttava testi läpäisee; toisen solmun saavuttava lähettäjä ei voi todentaa käytäntöä. Nämä havainnot ovat keksittyjä, eivätkä ne vahvista palveluntarjoajan todellista käyttäytymistä.
Ehdotettu tutkimus vertaa julkisia sormenjälkiä ja kelpoisuusvälejä palvelevissa solmuissa, mitä seuraa todennettu haku muuttumattomalla isäntänimellä. Se ei aloita varmenteiden tarkistusten höllentämisellä tai etsintätietueen poistamisella. Korjauksen omistaja suorittaa hyväksytyn käyttöönoton ja vahvistaa molemmat solmut. SMTP MX -varmenteet tarvitsevat edelleen oman vahvistuksensa, koska käytäntö-isäntäkorjaus ei kerro mitään niiden tilasta.
Ymmärrä välimuistin raja katkon aikana
Tukevan lähettäjän, jolla on kelvollinen, vanhentumaton välimuistikäytäntö, on jatkettava sen käyttöä, jos live-käytäntöä ei voida noutaa. Lähettäjä, jolla ei ole tällaista käytäntöä, jatkaa ikään kuin MTA-STS ei olisi ollut noudon epäonnistumisen jälkeen. Välimuistin käyttöikä tarjoaa siksi rajoitetun jatkuvuuden joillekin lähettäjille, ei oikeutta antaa HTTPS-varmenteen vanhentua. Eri lähettäjät voivat laillisesti miehittää eri tiloja saman katkon aikana. RFC 8461 kohta 3.3
Löytötunnus identifioi käytäntöesiintymän, ei varmenteen sarjanumeroa. Jos vain varmenne muuttuu ja käytäntöteksti pysyy samana, älä oleta, että uusiminen edellyttää uutta tunnusta. Jos myös käytäntö muuttuu, noudata body-before-ID -päivitysjärjestystä ja ota huomioon välimuistissa olevat käytännöt. Säilytä varmenteen käyttöönotto ja käytäntöjen tarkistus erikseen tarkistettavina muutoksina. RFC 8461 kohdat 3.1 ja 8.1
Säilytä todisteet seuraavaa uusimista varten
Tallenna hyväksytty käyttöönottotietue, julkiset ennen ja jälkeen -varmenteen tiedot, todennetut hakutulokset ja kaikki asiaankuuluvat TLS-RPT havainnot. Käytännön Web PKI -virhe kuuluu käytännön päätepisteen tutkimukseen; ilmoitettu SMTP -varmenteen vanheneminen koskee vastaanottavaa yhteyttä. Tarkista, mikä luokka todella on ilmoitettu. RFC 8460 kohta 4.3
Nykyinen RFC 8461 -virherekisteri sisältää raportoidut isojen kirjainten korjaukset vanhentuneiden vastaanotto-MTA-varmenteiden osalta; se ei salli vanhentuneita varmenteita. Täällä ei toimiteta alkuperäisiä uusimis- tai isännöintitodisteita. Lopullinen toimintaportti on edelleen käyttöön otetun palvelun aikaleimattu esittely, jonka omistaja on tarkistanut. RFC 8461 virhe