Samma filnamn ca.crt, annat certifikat: vad som ska jämföras

Två profiler levererar båda en fil som heter ca.crt, den ena tunneln kommer upp och den andra misslyckas med ett kedjefel. Att öppna de två filerna sida vid sida avgör det sällan, och att stänga av verifieringen avgör det i fel riktning. Frågan felet egentligen ställer är snävare: vilket certifikat läser varje process in som sitt förtroendeankare, och är de två samma objekt? Svara på det först och resten av diagnostiken får en riktning. Filnamnet är en förpackningsetikett, och sökvägen som står i profilen är inte heller auktoritativ, så allt beror på vad processen faktiskt läser.

Hitta certifikatet som klienten faktiskt läser in

OpenVPN accepterar auktoriteten i två former, och formen avgör vilka byte som spelar roll. En profil kan peka på en extern fil med ca eller bädda in certifikatet i ett <ca>-block i själva profilen. När båda finns vinner det inbäddade blocket, och filen bredvid profilen öppnas aldrig.

Läs den misslyckade profilen och ta reda på vilken form den använder innan du jämför något. En kopia hämtad från en grannkatalog, eller från paketet den andra profilen kom ifrån, säger ingenting om vad den här processen litar på. Samma sak gäller sökvägen i konfigurationen: den löses relativt platsen där klienten startades, vilket inte alltid är katalogen du tittar på. Läs profilen, inte mappen.

Certifikat identifieras av sitt innehåll: den offentliga nyckeln, subjektet och utfärdaren, giltighetsfönstret och signaturen över allt detta. Två filer med identiska byte är samma certifikat oavsett vad de heter, och två filer med samma namn kan vara orelaterade auktoriteter. Namnet är en förpackningsetikett, inte en identitet.

Ta fingeravtryck på båda kopiorna med openssl

Ett fingeravtryck är en hash över certifikatets DER-kodning, den form signaturen täcker, så radslut och rubriktext kan inte påverka det. Beräkna det för varje fil och du har två kolonseparerade hexsträngar som antingen stämmer eller inte. Inget annat i certifikatet behöver läsas för att svara på jämförelsefrågan.

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

Det är frestande att peka openssl mot själva profilen, men det läser det första certifikatblocket som förekommer i filen, och en profil har vanligtvis <cert> före <ca>. Extrahera auktoritetsblocket och ta sedan fingeravtryck på den extraherade filen, för det är kopian klienten faktiskt kommer att använda.

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

Identiska fingeravtryck betyder att förtroendematerialet är detsamma och att kedjefelet har en annan orsak, vilket är en annan undersökning. Olika fingeravtryck betyder olika certifikat, och det är där nästa avsnitt börjar.

Läs en avvikelse innan du antar en attack

Olika fingeravtryck betyder olika certifikat och inget mer. En nyutfärdning, en rotation, en omdöpt auktoritet eller ett inaktuellt paket ger alla olika filer med helt legitima historiker. Vilken som hör till utrullningen är en fråga för operatören eller utrullningsprotokollet, inte för filens ändringstid. Arkiv kopierar tidsstämplar, så en nyare fil är inte automatiskt rätt ankare.

En rot som signerar sig själv är normal, så att hitta en är inte bevis på ett problem. Verifierarens uppgift är att bygga en väg från serverns certifikat till ankaret den fick, och ett kedjefel betyder oftast att den vägen inte kunde slutföras.

Kontrollera om den misslyckade profilens ankare är en auktoritet som utrullningen fortfarande utfärdar från. Om fingeravtrycket inte matchar något i utrullningsprotokollet är profilen helt enkelt inaktuell, och ingen justering på klientsidan kommer att åtgärda det.

Reparera förtroendet utan att stänga av verifieringen

Den kortsiktiga lösningen är att stänga av verifieringen eller lägga till varje certifikat i kedjan som ankare. Båda får meddelandet att försvinna, och båda ändrar vilka servrar klienten kommer att acceptera från och med då. Slå på verifieringen igen, installera det avsedda ankaret och testa igen.

Om kedjan nu byggs men ett annat fel dyker upp är det framsteg: namnverifiering, giltighetsdatum och återkallelse är separata kontroller med separata meddelanden. Behåll fingeravtrycksparet och den ursprungliga feltexten tillsammans i ärendet, så att nästa person ser vilket ankare som laddades och vilket som förväntades. Ett fingeravtryckspar är litet nog att klistras in i en överlämningsanteckning, och nästa förekomst tar då fem minuter i stället för en eftermiddag.

Skaffa rätt auktoritet via samma autentiserade kanal som levererade profilen. Att dra ett certifikat från servern för att dess subjekt ser bekant ut är en annan handling, och den vidgar tyst det klienten kommer att lita på.