Lehtivarmenne voimassa, ketju vanhentunut: lue syvyys

Tarkistat palvelimen varmenteen, näet kellossa vielä kuukausia, ja asiakas silti hylkää yhteyden vanhenemisviestillä. Lukemasi päivämäärä kuuluu lehdelle, ja valitus voi koskea jotain syvempää polussa. Varmennus kulkee ketjua pitkin, ja mikä tahansa varmenteista, jonka tämä kulku valitsee, voi epäonnistua omassa voimassaoloikkunassaan. Lue, mikä epäonnistui, ennen kuin uudistat mitään.

Syvyys nimeää varmenteen, joka epäonnistui

OpenSSL-diagnostiikassa syvyys 0 on kohdevarmenne ja syvyys 1 sen allekirjoittanut myöntäjä, ja suuremmat luvut jatkuvat kohti luottamusanchor-pistettä. Syvyydessä 1 raportoitua vanhenemista ei kumoa lehdellä oleva ajantasainen notAfter, joten näkyvän varmenteen uudelleentarkistus ei koskaan selitä virhettä.

Kirjaa epäonnistuneen varmenteen sormenjälki sen subjektin kanssa, koska eri varmenteet voivat kantaa samaa CA-nimeä. Ristiallekirjoitus tuottaa juuri tämän tilanteen: sama viranomainen esiintyy useammin kuin kerran eri voimassaolopäivillä, ja varmistaja valitsi sen, jota et odottanut. Tuttu tunniste ei ole identifioija, ja sormenjälki on se, mikä erottaa kaksi samaa nimeä jakavaa kohdetta.

Kiinnitä huomiota myös tuotteisiin, joilla on useampi kuin yksi varmenteroooli. OpenVPN Access Serverissä verkkokäyttöliittymiä suojaavat varmenteet ovat erillisiä VPN-yhteyksiin käytetyistä, joten admin-sivun avaava selain ei todista mitään tunnelin polusta.

Luottamussyötteet eivät ole sama asia kuin ketjuehdokkaat

Anna varmistajalle kaksi syötettä erikseen ja nimenomaisesti. Luottamustiedosto sisältää hyväksymäsi anchor-pisteet; epäluotettu nippu sisältää polun rakentamiseen tarjotut välivarmenteet. Niiden sekoittaminen on se, miten ihmiset vahingossa ylentävät välivarmenteen juureksi ja ihmettelevät sitten, miksi sama virhe seuraa heitä koneiden välillä.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Oletuspolun ja -varaston poistaminen käytöstä valinnalla -no-CApath -no-CAstore pitää testin rehellisenä: tulos riippuu silloin nimeämistäsi tiedostoista, ei siitä, mitä työasema sattuu luottamaan. OpenSSL:n varmennusviite dokumentoi nämä valinnat ja niiden tuottaman diagnostiikan.

-show_chain tulostaa rakennetun ketjun, kun varmennus onnistuu, mikä on hyödyllistä sen vahvistamiseen, että polku on tarkoittamasi. Kun se epäonnistuu, säilytä raportoitu syvyys ja subjekti; nämä kaksi kenttää kertovat seuraavalle lukijalle, mitä varmennetta tarkastella.

Sitä tämä ei tee: se ei toista jokaisen asiakkaan käytäntöä. Pin, käyttötarkoituksen rajoitus tai asiakaskohtainen identiteettitarkistus elää asiakkaassa, ei tässä komennossa. Ne ovat asetuksia, jotka on tarkastettava, kun varmennus onnistuu palvelimella ja yhteys epäonnistuu silti. Pidä kaksi diagnoosia erillään, tai uudistat terveen varmenteen jahdatessasi pinning-virhettä.

Mitä tarkistus todistaa ja mitä se jättää pois

Tämä on polun ja käyttötarkoituksen tarkistus antamaasi luottamustiedostoa vastaan. HTTPS-nimitarkistukseen lisää odotettu isäntänimi sopivalla valinnalla; VPN-yhteyteen pidä asiakkaan määritetyt identiteettitarkistukset ja käytä luottamusmateriaalia, jota kyseinen asiakas todella lukee.

Se, mitä palvelin lähettää, on joukko ehdokkaita, ei polku, jonka asiakkaasi lopulta rakentaa. Paikallinen luottamus ja kirjaston rakennussäännöt muovaavat molemmat tulosta, minkä vuoksi sama vastaus voi varmistua yhdellä koneella ja epäonnistua toisella. Vertaa epäonnistuvan asiakkaan ylläpidettyä luottamusvarastoa ja TLS-toteutusta toimivan asiakkaan vastaaviin ennen kuin oletat samanlaista arviointia. Ero siinä selittää monet raportit „vain tämä kannettava epäonnistuu“.

Nähdäksesi jokaisen varmenteen ikkunan yhden kerrallaan sijaan tulosta ne joukkona:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Tuo toinen komento luettelee subjektit ja myöntäjät dekoodaamatta jokaista tiedostoa käsin, ja näin huomaat välivarmenteen, jonka päivämäärä on mennyt ohi lehden näyttäessä yhä kunnolliselta.

Korjaa polku heikentämättä varmennusta

Kun toimitetaan vanhentunut välivarmenne tai vanhentunut ristiallekirjoitettu varmenne, hanki myöntäjän tällä hetkellä tuettu ketju ja ota se käyttöön palvelun dokumentoidulla varmennetyönkululla. Kun asiakkaalta puuttuu aiottu ylläpidetty anchor, päivitä sen hallittu luottamuskokoonpano tai asiakasohjelmisto. Vastusta pikaratkaisua merkitä jokainen nipun varmenne juureksi vain vaientaaksesi viestin.

Juuren käsittely ansaitsee huomautuksen, koska tiivistelmät usein liioittelevat sitä. RFC 5280 kohtelee anchor-pistettä syötteenä, joka on tulevan polun ulkopuolella, kun taas OpenSSL dokumentoi voimassaolotarkistukset, jotka sisältävät sen juuri-CA-varmenteen. Molemmat väitteet pitävät paikkansa niiden omissa järjestelmissä; yhden kirjaston juuren vanhenemiskäyttäytymisen yleistäminen kaikkiin asiakkaisiin tuottaa itsevarmoja vääriä vastauksia.

Muutoksen jälkeen pakota tuore todennus asianomaisella asiakkaalla ja vahvista, että tietty vanhenemisviesti on poissa. Uudista lehti vain, jos lehti itse on sopimaton. Aikatarkistusten poistaminen käytöstä tai historiallisen ristivarmenteen palauttaminen ei tuota voimassa olevaa nykyistä polkua; se vain viivästyttää seuraavaa epäonnistumista.