Peruutit varmenteen, loit uuden luettelon, ja vanha profiili nostaa yhä tunnelin. Itse peruutus ei ole rikki: CRL on allekirjoitettu ilmoitus siitä, että sarjanumero ei ole enää voimassa, ja se muuttaa pääsyä vasta, kun TLS:n päättävä komponentti lataa sen, oikealle myöntäjälle, ennen kuin se tekee hyväksyntäpäätöksen. Juuri siellä useimmat näistä tapauksista ovat, ja siksi peruutus ja hylkäys ovat kaksi eri tosiasiaa.

Käy alla olevat viisi tarkistusta järjestyksessä läpi ja pysähdy ensimmäiseen, joka ei pidä, koska jokainen myöhempi olettaa aiempien olevan tosia.

Tarkista, mikä komponentti tekee hyväksyntäpäätöksen

Nimeä prosessi, joka validoi asiakasvarmenteen, koska vain se prosessi voi valvoa luetteloa. OpenVPN-palvelimella se on daemon itse, konfiguroitu crl-verify-asetuksella. ocservissä se on rivi crl tiedostossa ocserv.conf. strongSwanissa syötteet ovat ladatut CRL:t yhdessä strictcrlpolicy-asetuksen kanssa. TLS:n päättävä välityspalvelin tai laite VPN:n edessä voi myös olla todellinen vahvistaja, ja jos se on, sen takana oleva daemon ei koskaan näe asiakasvarmennetta.

WireGuard kuuluu toiseen luokkaan. Sillä ei ole varmenteita eikä peruutusluetteloa; peer hyväksytään julkisella avaimellaan konfiguraatiossa, joten pääsyn lopettaminen tarkoittaa kyseisen avaimen poistamista. Jos etsit CRL:ää vain WireGuardilla toteutetusta asennuksesta, sitä mekanismia ei ole siellä.

Varo myös asiakaspuolen ansaa. Asiakas, joka kieltäytyy yhdistämästä, koska ei pidä palvelimen varmenteesta, valvoo palvelimen ketjua eikä peruuta omia tunnistetietojaan. Käyttäjävarmenne peruutetaan vain siellä, missä kyseinen käyttäjävarmenne validoidaan, ja se on lähes aina palvelinpuoli.

Tarkista, mille myöntäjälle luettelo allekirjoitettiin

CRL on rajattu yhteen myöntävään CA:han. Juuri- ja välittäjä-CA:n kanssa lehtivarmenteet tulevat välittäjältä, joten merkityksellinen luettelo on välittäjän CRL; juuren luettelo ei kerro noista lehdistä mitään. Väärään tiedostoon osoitettu vahvistaja jäsentää sen iloisesti, ei löydä vastaavaa merkintää ja hyväksyy kaiken.

Vahvista paritus ennen kuin kosket daemoniin. Varmenteen myöntäjän on vastattava luettelon subjectia:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Kun molemmat tulevat samalta CA:lta, varmenteelle tulostettu sarjanumero on arvo, jonka on esiinnyttävä luettelossa. Jos ne eivät täsmää, sinulla on väärä CRL tai sen väärä kopio.

Voimassaolo kuuluu samaan tarkistukseen. Menneisyydessä oleva nextUpdate vanhentaa luettelon, ja suljetusti epäonnistuva vahvistaja hylkää silloin jokaisen asiakkaan vain peruutetun sijaan.

Tarkista, että sarjanumero on daemonin lataamassa kopiossa

Peruutus kirjoittaa merkinnän CA:n tietokantaan, ja uudelleenluonti kirjoittaa uuden tiedoston. Kumpikaan toimenpide ei saavuta käynnissä olevaa daemonia, joka latasi vanhan kopion käynnistyksen yhteydessä. Tulosta luettelo ja etsi sarjanumero:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Tarkista sitten, miten toteutuksesi ottaa tiedoston vastaan. OpenVPN lukee crl-verify-asetukselle annetun polun kerran käynnistyksen yhteydessä, joten uusi luettelo vaatii uudelleenkäynnistyksen tai uudelleenkäynnistyssignaalin; sama vaihtoehto hakemistoon osoitettuna luetaan uudelleen joka yhteydellä, ja siksi hakemistotila on olemassa. strongSwanin on ladattava tunnistetietonsa uudelleen, esimerkiksi komennolla swanctl --load-creds. Se, että tiedosto levyllä on oikein, ja se, että vahvistaja käyttää sitä, ovat kaksi eri tosiasiaa.

Tarkista puuttuvan tai vanhentuneen luettelon käytäntö

Tämä on päätös, jota monet käyttöönotot eivät koskaan tee eksplisiittisesti, ja se ratkaisee, suojaako peruutus sinua vai lukitseeko se kaikki ulos. Fail-closed tarkoittaa, että ilman käyttökelpoista peruutustietoa syntyy hylkäys; fail-open tarkoittaa, että vahvistaja jatkaa ilman sitä. strongSwan tarjoaa valinnan muodossa strictcrlpolicy. OpenVPN crl-verify-asetuksella kieltäytyy käynnistymästä tiedostolla, jota se ei voi lukea tai jäsentää, ja vanhentunut luettelo näkyy TLS-vahvistusvirheenä vanhentuneesta CRL:stä eikä hiljaisena hyväksyntänä.

State of the revocation dataFail-closed resultFail-open result
List missing or unreadableVerification fails, so expect an outageEvery client connects, including the revoked one
List past nextUpdateValidation errors until a fresh list is deployedOld status is trusted indefinitely
Revoked serial present in the loaded listHandshake rejected for that certificateHandshake rejected for that certificate

Minkä suunnan valitsetkin, automaatio on tärkeämpää kuin valinta: työ, joka luo CRL:n uudelleen ennen nextUpdate, ja hälytys, kun käyttöön otettu kopio vanhenee, estävät kumpaakin käytäntöä muuttumasta incidentiksi. OCSP-pohjainen verkkotarkistus siirtää tuoreuden vastaajalle, mutta sama sääntö pätee, koska vahvistaja, jota ei ole konfiguroitu tarkistamaan vastausta, ei muuta mitään.

Tarkista aktiivinen istunto ja sitten avaimen kopiot

Peruutus arvioidaan varmenteen validoinnin aikana, joka tapahtuu yhdistettäessä ja uudelleenneuvoteltaessa. Vakiintunut istunto jatkuu, kunnes se neuvottelee uudelleen, ja OpenVPN:n oletusarvo on kerran tunnissa reneg-sec 3600-asetuksella. Jos henkilön on päästävä verkosta heti, lopeta istunto luettelon julkaisemisen lisäksi ja vahvista sitten, että uudelleenyhdistäminen hylätään.

Erottele tunnistetiedot niiden kopioista. Profiilin poistaminen yhdeltä kannettavalta ei estä toista saman yksityisen avaimen kopiota todenmasta; peruutus on se, mikä tekee jokaisesta kopiosta hyödyttömän, ja vasta kun aiemmat tarkistukset pitävät. Anna vaihtolaitteelle oma varmenne, jotta toinen voidaan peruuttaa koskematta toiseen.

Ennen kuin kutsut sitä valmiiksi: validoiva komponentti on tunnistettu, luettelon myöntäjä vastaa lehden myöntäjää, peruutettu sarjanumero on kopiossa, jonka daemon todella latasi, puuttuvien tai vanhentuneiden luetteloiden käytäntö on tarkoituksellinen ja valvottu, ja aktiivinen istunto lopetettiin odottamisen sijaan. Kaiken tämän taustalla olevat formaatit määritellään RFC 5280.

Aiheeseen liittyvät artikkelit