OpenVPN username-as-common-name: varför din CN-kontroll är tom

Du lägger till ett client-connect-skript som avvisar varje anslutning där common_name skiljer sig från username, och det ser ut som en bindning mellan ett certifikat och ett konto. På en server som kör username-as-common-name har den jämförelsen redan förlorat sin betydelse när skriptet körs. Båda värdena är samma sträng, så testet passerar för ett certifikat som utfärdats till någon helt annan.

Kontrollen är inte fel för att skriptet är dåligt skrivet. Den är fel för att värdet den läser ersattes tidigare i samma anslutning.

Vad jämförelsen verkar bevisa

Certifikatautentisering och lösenordsautentisering är separata bevis, och en server kan kräva båda utan att kräva att de tillhör samma person. Gapet är verkligt: ett giltigt enhetscertifikat plus vilket giltigt konto som helst är ett annat påstående än det certifikatet plus ett enda namngivet konto. Ett skript som jämför common_name med username läses som den saknade länken mellan de två. Det skulle det vara om common_name fortfarande betydde det certifikatet sa.

Om det är så beror på ett serveralternativ, och det alternativet slås vanligtvis på av en orelaterad anledning, till exempel att konfigurationsfilerna per användare ska vara lättare att namnge.

Vad username-as-common-name gör med namnet

Med username-as-common-name aktiverat ersätter OpenVPN certifikatets vanliga namn med det autentiserade användarnamnet när användarnamnet och lösenordet har verifierats. Verifieringskroken som körs under den kontrollen tar fortfarande emot certifikatets vanliga namn, eftersom ersättningen ännu inte har skett. Allt efteråt, inklusive client-connect, ser användarnamnet. Därför får den senare återkallelsen en identitet två gånger och kan inte jämföra den med certifikatet som presenterades.

Följ en illustrativ anslutning: ett certifikat utfärdat för bob-device, en lyckad kataloginloggning som alice och alternativet aktiverat. Verifieringsfasen kan fortfarande se två olika strängar. Anslutningsfasen ser alice och alice.

Det exemplet visar varför jämförelsen är tom. Det visar inte att anslutningen annars skulle accepteras, eftersom certifikatvalidering och lösenordsverifiering fortfarande körs för sig själva.

Placera bindningen där båda identiteterna fortfarande finns

Regeln måste upprätthållas i en fas som ser certifikatets identitet och kontot samtidigt, vilket i praktiken betyder verifieringskroken för användarnamn och lösenord eller en plugin som laddas där. En plugin som stöds och som redan utför lösenordsverifiering är vanligtvis rätt plats att lägga till en parningsregel på, eftersom att ersätta den med en namnjämförelse skulle ta bort lösenordskontrollen helt.

Definiera mappningen innan du skriver kod, eftersom likhet sällan är den verkliga policyn. Ett certifikat identifierar ofta en enhet medan inloggningen identifierar en person, och en enhet kan lagligt betjäna flera personer. Lagra relationen i en form där du kontrollerar utfärdandet, och bestäm vad som händer vid namnbyte, vid nyutfärdande och med domänkvalificerade namn. Att göra om till små bokstäver eller ta bort ett domänprefix utan att förstå katalogen kan slå samman två konton som skulle hållas åtskilda.

Kom ihåg att alternativet också ändrar vilken konfiguration per klient som gäller, eftersom client-config-dir nycklas på det vanliga namnet.

Testa parningen med två giltiga inloggningsuppgifter

Börja med paret som din policy tillåter och bekräfta att det ansluter. Presentera sedan samma giltiga certifikat med ett annat men i övrigt giltigt konto: det försöket måste misslyckas, och det måste misslyckas på grund av parningsregeln och inte på grund av ett felaktigt inskrivet lösenord. Ett fel lösenord bevisar att lösenordskontrollen fungerar och säger ingenting om regeln mellan certifikat och konto.

Kontrollera också banorna med saknat certifikat och ogiltigt certifikat, och bekräfta vilken identitet servern använder för inställningar per klient. Om det enda sättet att få jämförelsen att fungera är att stänga av username-as-common-name, prissätt den ändringen först, eftersom den flyttar varje klients konfigurationssökning tillbaka till certifikatets namn.