Varför ny import av ett Client VPN-certifikat kräver en ny slutpunkt

En Client VPN-anslutning bryts, certifikatet i ACM byts ut och ingenting ändras. Certifikatobjektet var aldrig det slutpunkten använde. En slutpunkt sparar vid skapandet en koppling till ett certifikat, tillsammans med klient-CA:n den ska validera mot, autentiseringstypen, subnäten och auktoriseringsreglerna, och ingen av dessa kopplingar har ett ändringsanrop som accepterar ett ersättningscertifikat. Att byta ut byten bakom ett ARN är en ändring av certifikatet, inte av slutpunkten som fångade det.

Slutpunkten sparar referenser, inte certifikat

Mekanismen förtjänar en exakt formulering eftersom den förklarar hela felet. create-client-vpn-endpoint tar ett ARN för ett servercertifikat och ett ARN för en klientrotcertifikatkedja, och den resulterande slutpunkten behåller dessa referenser plus autentiseringsalternativen som fasta egenskaper. API:t erbjuder ingen operation som byter ut servercertifikatet på en befintlig slutpunkt.

Du kan bekräfta kopplingen utan att gissa. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 skriver ut certifikatets ARN, klientrotkedjans ARN, autentiseringstypen, klientens CIDR och de associerade subnäten, vilket är hela uppsättningen egenskaper du skulle behöva återskapa. Kör den före och efter en ny import och utdata rör sig inte. Det är beviset för att den nya importen aldrig skulle hjälpa.

Varför en ny import inte kan nå slutpunkten

En ny import skriver en ny certifikatkropp under ett befintligt ARN. Det är en legitim operation när ett certifikat närmar sig utgång, och ACM accepterar den så länge den privata nyckeln matchar och kedjan validerar. Det den inte gör är att köra valideringen från slutpunktens skapande igen, så kopplingen och materialet bakom den förblir som det var när slutpunkten byggdes.

Det är också därför symtomet läses som ett nätverksfel. TLS-handskakningen misslyckas eller återställs innan auktoriseringen ens utvärderas, så säkerhetsgrupper, rutter och auktoriseringsregler ser alla oskyldiga ut, och det är de.

Kedjan är en del av klientcertifikatet

Den andra halvan av felet ligger i klientcertifikatet, och den är lättare att avfärda. Ett klientcertifikat måste importeras med kedjan som utfärdade det, även om importformuläret visar fältet som valfritt. Utan kedjan kan slutpunkten inte bygga en väg från klientcertifikatet till klientrot-CA:n som den konfigurerades med, och anslutningen slutar i en mjuk återställning som låter som en brandvägg som tappar paket. openssl verify -CAfile root-ca.pem client.crt svarar på den frågan lokalt på en sekund, och det borde vara det första kommandot du kör.

Ny import med kedjan är en riktig rättelse för den halvan, och den är fortfarande inte nog ensam. När ACM-objektet väl har ändrats är slutpunkten med den gamla kopplingen det felaktiga att fortsätta testa mot. Båda stegen hör till samma reparation, därför är den tvådelade rättelsen ingen motsägelse.

Att återskapa en slutpunkt är en migrering

Att skapa en ersättningsslutpunkt är en migrering, inte ett nytt försök, och att behandla det som ett nytt försök är hur team hamnar med två halvkonfigurerade slutpunkter. Den nya slutpunkten får ett nytt ID och, om du inte planerade det, ett nytt DNS-namn för varje användare. Håll klientprofilen pekande på ett namn i stället för en adress, så att bytet blir en poständring i stället för en ny distribution.

Ordningen som håller detta säkert är kort: skapa den nya slutpunkten med samma CIDR, subnät och auktoriseringsregler, exportera en färsk profil med aws ec2 export-client-vpn-client-configuration och verifiera med en användare. Först efter det tas den gamla slutpunkten ner.

Avvecklingen av den gamla slutpunkten har sin egen ordning. Återkalla klientcertifikaten du tänkte avveckla innan du tar bort den, eftersom en ny slutpunkt som fortfarande litar på den gamla CA:n fortsätter att acceptera certifikat du trodde var borta. Ta sedan bort den gamla slutpunkten och dess auktoriseringsregler, så att en inaktuell profil inte kan återansluta till ett målnätverk du trodde var stängt. Skriv den gamla slutpunktens ID och kopplingsidentifikatorerna i ändringsposten, eftersom en migrering jämförd med minnet är hur en fungerande slutpunkt byggs om två gånger.

Ordna diagnostiken

Separera tre fel innan du ändrar någon konfiguration. Klienten kan inte slutföra TLS, klienten slutför TLS och är inte auktoriserad, eller klienten ansluter och når inte en destination. Certifikatkopplingen hör till den första, en auktoriseringsregel som inte täcker klientadressen till den andra, och en rutt eller säkerhetsgrupp till den tredje, där det nästan alltid är fel drag att återskapa en slutpunkt.

En slutpunkt som fungerade i månader och sedan slutade, utan ändring av certifikat eller policy, är ett eget fall. Att bygga om den med identiska inställningar kan återställa tjänsten, men det är en anledning att hålla konfigurationen reproducerbar, inte en anledning att bygga om vid varje incident.

Håll fyra saker under versionskontroll så att nästa ombyggnad blir en diff och inte en improvisation: slutpunktens parametrar, ARN:en för certifikatet och kedjan, auktoriseringsreglerna och klientens CIDR. Dokumentationen för Client VPN-autentisering listar vilket certifikat som spelar vilken roll, vilket är värt att kontrollera innan du ens antar att ett certifikat är problemet. Om en ny import inte ändrar något och slutpunkten fortfarande återställs är kopplingen den misstänkta, och svaret är en ny slutpunkt byggd från de registrerade parametrarna. Om slutpunkten faktiskt tar upp det nya objektet var kopplingen redan korrekt, och felet sitter i klientkedjan eller auktoriseringslagret.