Tilbagekaldt klient forbinder stadig: listen nåede aldrig frem

Tilbagekaldelse trænger aldrig ind i en kørende tunnel for at slette en session. Listen er et input til certifikatverifikation og slås op under den kontrolkanaludveksling, der begynder en TLS-session. Den ene kendsgerning forklarer begge overraskelser: en tilbagekaldt klient forbinder igen, fordi listen aldrig nåede frem til verifikatoren, og en eksisterende session overlever, fordi ingen verificerede noget igen.

En liste er et input, ikke en handling

Under sessionsopsætningen validerer serveren klientcertifikatet mod sine tillidsankre, og tilbagekaldelsesdirektivet tilføjer et listeslag til den beslutning. Kontrollen sker på serveren, så klienten kan ikke se, at dens certifikat er tilbagekaldt, og bliver ved med at tilbyde det samme. En profil, der stadig forbinder, beviser derfor kun, at en eller anden verifikator accepterede kæden, ikke at tilbagekaldelsen fejlede.

Listen er selv et signeret objekt med en udstedelsesdato og en næste opdateringsdato. En uvedkommende liste, en der er signeret af en anden myndighed, eller en hvis næste opdatering er passeret, er ikke en erstatning for den aktuelle, og om en forældet liste afvises eller stiltiende accepteres, afhænger af udrulningen.

Ny forbindelse kontra kørende session

Tilbagekaldelse vurderes, når en session etableres eller genforhandles, ikke mod datakanalen for hver pakke. En klient, der allerede er forbundet, har trafiknøgler, så den fortsætter med at slippe pakker igennem, efter at dens certifikat optræder på listen. Standardintervallet for genforhandling måles i timer, og derfor kan en opdateret liste træde i kraft for nye, mens en kørende tunnel bliver oppe.

Øjeblikkelig håndhævelse kræver en bevidst handling i stedet for kun listen. Genstart af tjenesten tvinger hver klient til at forbinde igen, mens afslutning af én session via administrationsgrænsefladen lader de andre være urørt. Vælg én for hver hændelse, og noter hvilken du brugte. De to muligheder har forskellig rækkevidde, og det er den egentlige beslutning.

Lever den fil, verifikatoren faktisk læser

Listen skal genereres ud fra myndighedens registrering og derefter kopieres til hver maskine, der verificerer certifikater. At generere den på CA-værten og aldrig installere den på serveren er den mest almindelige fejl, og det ser præcis ud som en ødelagt tilbagekaldelsesfunktion.

ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pem

To detaljer afgør, om filen faktisk læses. En relativ sti opløses mod konfigurationsmappen, så en kopi, der ligger i en operatørs hjemmemappe, findes måske aldrig. Og daemonen opgiver normalt privilegier efter opstart, så køretidskontoen skal have søgetilladelse på hver overordnet mappe og læsetilladelse på filen. Kontrollér begge med køretidskontoen i stedet for med root, ellers beviser testen det forkerte.

På systemd-værter kan en hærdet unit også skjule stien, med en skrivebeskyttet visning eller en beskyttet systemmappe. Inde i tjenesten kan det ikke skelnes fra en manglende fil, så kontrollér unitens begrænsninger, før du leder efter en tilladelsesfejl. Læs unitfilen, før du giver filens tilstand skylden.

Bekræft på serveren, ikke på klienten

Serverloggen navngiver, hvad der skete: åbning af listen, indlæsning af den eller mislykket verifikation med det tilbagekaldte serienummer. Klienten rapporterer kun en generisk handshake-fejl, og derfor er klientlogge et dårligt sted at lede efter en tilbagekaldelsesbeslutning.

Kontrollér med et friskt forsøg fra den tilbagekaldte profil, og stop så. En vellykket forbindelse fra den profil er signalet til at undersøge filstien og køretidskontoen, ikke til at antage, at listen var forkert. Behold det vellykkede forsøg som accepttest, og tæl ikke en genforbindelse, du ikke selv har set.

Hvad der ikke tilbagekalder noget

At slette profilen fra en bærbar computer, fjerne certifikatfilen fra klienten eller bede brugeren om at holde op med at forbinde ændrer intet på serveren. Certifikatet forbliver gyldigt, indtil myndigheden registrerer tilbagekaldelsen, og verifikatoren læser den resulterende liste.

Det er også derfor, kæden er værd at skrive ned: registrér tilbagekaldelsen, generér og signér listen, distribuér netop den fil, og bekræft, at tjenestekontoen kan læse den. Hvert led er kort, og mangler ét, fortsætter en tilbagekaldt klient muntert med at forbinde. En tjekliste med fire linjer slår en antagelse uden nogen.