Ett gemensamt namn, två certifikat: tillåtelselista eller återkallelse?

Att utfärda ett nytt laptopcertifikat under samma gemensamma namn känns som en ersättning, och alla antar att det gamla är dött. Det är det inte. Föregångaren förblir ett giltigt certifikat signerat av samma myndighet, och varje kontroll som släpper in klienter efter namn kommer att fortsätta släppa in det. Det som skiljer en identitetskontroll från en autentiseringskontroll är serienumret, och det är där rättelsen hör hemma.

Börja med den namngivningspolicy som servern använder

Två kontroller blandas ihop: att släppa in en klient för att den påstår sig vara någon, och att ta ett specifikt certifikat ur drift. Den första är en namnkontroll, den andra är en återkallelsekontroll. De svarar på olika frågor, och en driftsättning kan ha den ena utan den andra.

Läs serverkonfigurationen och notera vilken identitetskälla som är i spel. username-as-common-name gör det autentiserade användarnamnet till det effektiva namnet för klientspecifika uppslag. Utan det används certifikatets subjekt-gemensamma namn. Vad svaret än är, skriv ned det innan du rör någon tillåtelselista.

De två vägarna ger en annan uppsättning tillåtna namn för samma certifikat. Att gissa här innebär att redigera fel fil och dra slutsatsen att kontrollen inte fungerar.

Kontrollera vad som faktiskt släpper in en klient

En client-config-dir med en matchande fil tillhandahåller klientspecifika alternativ; i sig är den ingen insläppsregel. Insläpp efter namn kräver ccd-exclusive, som avvisar klienter som saknar en matchande fil. Att slå på det i en aktiv driftsättning kopplar från alla vars namn saknar en fil, så räkna filerna innan du ändrar något.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

Antalet är kontrollen: jämför kataloglistningen med de identiteter du förväntar dig ska ansluta.

Bekräfta sedan att varje filnamn matchar den effektiva identiteten exakt, inklusive skiftläge och mellanslag. En fil för office-laptop gör ingenting för ett certifikat vars subjekt lyder Office-Laptop. Mellanslag i slutet gömmer sig också för en vanlig listning, och så förblir en fil som ser ut att finnas oläst.

Kontrollera den CRL som gatewayen laddar

En CRL namnger återkallade certifikat efter utfärdare och serienummer, och det är den detaljnivå som en namnkontroll saknar. Två certifikat kan dela ett gemensamt namn och skilja sig i serienummer, och bara en lista på serienivå skiljer dem.

Bekräfta den konfigurerade sökvägen, utfärdandedatumet och fältet för nästa uppdatering innan du litar på filen överhuvudtaget.

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

Jämför serienumret i CRL:en med serienumret på certifikatet du tänker behålla. Den jämförelsen är hela testet, och att göra den en gång med ögonen är värt mer än att lita på ett skript som ingen läst. Distribuera den uppdaterade CRL:en via den sökväg som gatewayen redan läser. En CRL i fel katalog genomdriver ingenting, och ingen klientlogg kommer att nämna den.

Ersätt, bevisa sedan båda utfallen

Utfärda ersättaren under samma gemensamma namn, registrera båda serienumren och återkalla först därefter det gamla. Den ordningen håller en fungerande identitet tillgänglig medan du förbereder ändringen.

Testa ersättaren först: den ska autentisera och nå allt som dess namn ger rätt till. Testa sedan det gamla certifikatet och bekräfta att det avvisas, eftersom en lyckad ersättning inte säger något om återkallelse. Om båda fortfarande ansluter läses inte återkallelseindata, eller så listades aldrig det gamla serienumret. Om ingen ansluter har du förstört insläppsregeln och inte autentiseringsuppgiften.

Sessioner som redan upprättats är en separat sak, eftersom återkallelse gäller nya autentiseringar om inte gatewayen också är konfigurerad att bryta aktiva anslutningar. Avgör om omedelbart borttagande krävs innan du lovar det till någon.

Vad en namnkontroll aldrig kan göra

En tillåtelselista svarar på om denna identitet får ansluta. Den kan inte säga vilket certifikat identiteten använde, och den kommer att släppa in en äldre autentiseringsuppgift så länge uppgiften förblir giltig och inte återkallad. Den luckan syns under en incident, när ersättaren utfärdades för månader sedan och föregångaren fortfarande fungerar.

Där kontroll på certifikatnivå krävs, använd en mekanism som namnger certifikatet: CRL-poster, eller en verifieringskrok som kontrollerar ett fingeravtryck som operatören underhåller. Båda kostar underhåll, och båda är ärliga om det objekt de undersöker. OpenVPN 2.6-handboken dokumenterar crl-verify och klientspecifikt insläpp som separata alternativ, just av den anledningen.

Skriv ned vilken kontroll som gör vilket jobb och testa sedan det negativa fallet. En återkallelse som du aldrig sett avvisa en anslutning är en konfiguration som du hoppas fungerar.