Att installera ett eget certifikat på en VPN-slutpunkt känns som att lägga till skydd, eftersom certifikat och kryptering dyker upp tillsammans överallt. I praktiken ändrar det två saker: vilken identitet slutpunkten visar, och vilken utgivare motparten är beredd att lita på. Ingen av dem paketerar om dina data en gång till. Om det egentliga behovet är en andra skyddad kanal behöver du en andra kanal med egna slutpunkter, inte ännu ett certifikat.

Tre åtskilda uppgifter i en TLS 1.3-handskakning

RFC 8446 håller dessa saker åtskilda, och just den åtskillnaden är hela svaret. Certificate-meddelandet bär slutpunktens certifikatkedja. CertificateVerify bevisar innehav av motsvarande privata nyckel och binder handskakningens transkript. Record-lagret skyddar trafiken med de förhandlade trafiknycklarna.

Byt certifikatet och de två första punkterna ändras. Record-skyddet körs inte två gånger och blir inte starkare för att utgivaren nu är privat.

Vad en privat CA egentligen köper

Den köper ett kontrollerat identitetssystem: du bestämmer vem som får utfärdat, du bestämmer vilka utgivare motparter accepterar, och du kan återkalla enligt ditt eget schema. Det är verkligen användbart när du driver båda ändarna.

Den för också med sig skyldigheter. Förtroende måste fördelas medvetet, motpartskontrollen måste vara påslagen, och någon måste äga livscykeln för inloggningsuppgifterna. En privat CA är ingen genväg förbi någon av dessa tre.

När en andra kanal är rätt svar

Anta att ett program öppnar verifierad HTTPS till sin egen tjänst medan paketen också går genom en VPN. Den designen har två gränser med möjligen olika slutpunkter, och det är så en andra skyddad kanal ser ut.

Skillnaden spelar roll vid gatewayen. Om programmets TLS-session avslutas vid VPN-gatewayen i stället för vid programmet, finns inte det skydd du trodde dig ha bortom tunneln. Skriv ner vem som avslutar varje kanal innan du hävdar egenskapen.

Fråga vad installationen ändrar

En begäran om att installera ett certifikat kan betyda tre olika saker. Den kan ändra klientens egen identitet, ett programspecifikt förtroendeankare eller förtroende på plattformsnivå för allt på enheten. Dessa är inte likvärdiga, och bara den sista påverkar orelaterad programvara.

Fråga vilken av de tre som avses, och sedan vad den ska åstadkomma. Om svaret är mer kryptering riktar sig förslaget mot fel mekanism.

Skriv ner gränserna

För varje kanal, notera slutpunkterna, den identitet varje sida verifierar och vad operatören i mitten kan se. Notera sedan felbeteendet: vad som händer när verifieringen misslyckas, och vad som händer när kanalen avvisas.

Två rader på en sida avgör vanligtvis en diskussion som en certifikatrotation inte kan avgöra.

Avgör med tre frågor

Är problemet vem slutpunkten utger sig för att vara, eller vad som händer med data? Måste skyddet fortsätta förbi VPN-gatewayen till ett visst program? Och kan du namnge de två slutpunkter som skulle avsluta en andra kanal?

Om den första frågan är den rätta, rätta till identitet och förtroende. Om det är den andra eller tredje, designa den andra kanalen och låt certifikatet vara där det hör hemma.

Relaterade artiklar