Gateway-certifikatet är i ordning: varför IKEv2 PEAP-inloggning ändå misslyckas

Certifikatet för din VPN-gateway är giltigt, kedjan valideras, och IKEv2-klienten avvisar ändå inloggningen med ett meddelande om ett certifikats giltighetsintervall. Den första impulsen är att utfärda gateway-certifikatet på nytt eller byta EAP-metod, och båda är oftast fel. Inloggningsförsöket bär två separata serveridentiteter: gateway-certifikatet som IKE använder, och certifikatet som presenteras av det som avslutar PEAP. En av dem är i ordning, och den andra är anledningen till att klienten stannade.

Två identiteter, ett inloggningsförsök

Certifikatet i VPN-profilen hör till IKE-utbytet: det bevisar att gatewayen är den part som profilen namnger, under den konfigurerade IKE-principen. Certifikatet som misslyckas här hör till ett annat samtal, TLS-sessionen som PEAP öppnar med det som autentiserar användaren, vilket ofta är en RADIUS-server som NPS och inte gatewayen själv. En tredje kontroll, användarens inloggningsuppgifter, sker inne i den sessionen. Ett giltigt lösenord kan inte reparera ett utgånget servercertifikat, och ett giltigt gateway-certifikat kan inte gå i god för PEAP-slutpunkten.

Denna skiktning förklarar varför ett certifikatfel dyker upp på en plats där det enda konfigurerade certifikatet var gatewayens. Den förklarar också varför en ny utfärdning av det certifikatet inte ändrar något.

Läs loggrader mot steget

Hitta meddelandet som namnger orsaken och datumen. Ett klagomål om giltighetsintervallet bredvid ett subjektfel betyder att servern avvisade certifikatet den fick, inte att användaren avvisade inloggningen. Hitta sedan steget: en strongSwan charon-logg visar IKE_SA .* established innan EAP-utbytet börjar, så ett certifikatfel efter den raden hör till EAP-identiteten, medan ett fel före den pekar på gatewayen. Stegtexten i en Windows-klients anslutningspanel säger samma sak.

Kontrollera klientens klocka innan du rör något certifikat. En enhet som går timmar fel ger samma giltighetsfel som ett verkligt utgånget certifikat. Att ställa klockan är en rättelse på fem sekunder, och att byta ut ett certifikat som aldrig var problemet är ett avbrott.

Ta reda på vilken slutpunkt som avslutar PEAP

I en design med gateway plus RADIUS vidarebefordrar gatewayen EAP och avslutar det inte. strongSwans eap-radius-plugin lämnar utbytet till RADIUS-servern, som äger PEAP TLS-sessionen och dess certifikat. Korrelera ett misslyckat försök i båda loggarna och bekräfta vilken process som faktiskt valde ett certifikat för den sessionen.

För NPS måste certifikatet ligga i den lokala datorns arkiv, bära syftet serverautentisering, matcha namnet som klienterna förväntar sig, och vara läsbart för tjänstekontot. Microsofts certifikatkrav för NPS listar dessa villkor. Andra EAP-servrar har egna urvalsregler, så kopiera inte NPS-specifika detaljer till en FreeRADIUS-installation eller tvärtom. Regeln som håller i båda fallen är att slutpunkten som avslutar PEAP äger certifikatet du är på väg att ändra.

Byt ut certifikatet där EAP avslutas

Förnya eller byt ut certifikatet på slutpunkten som avslutar PEAP, via den stödda processen, och behåll syftet serverautentisering och det förväntade namnet. Installera hela kedjan där tjänsten letar efter den och ge tjänsten åtkomst till den privata nyckeln. Starta om eller bind om tjänsten, eftersom många tjänster behåller det gamla certifikatet i minnet och fortsätter presentera det. En fil som kopierats till maskinen bevisar ingenting om vilket certifikat tjänsten faktiskt presenterar.

Bekräfta ändringen genom att korrelera nästa försök med tjänstens egen logg, eller genom att inspektera certifikatet som sessionen presenterade. Om den loggen fortfarande visar det gamla fingeravtrycket tog omstarten inte.

Anta inte att den nyaste filen i en katalog är den som används. En kopia med rätt namn och fel behörigheter ändrar ingenting. Bedöm ändringen efter den presenterade identiteten, inte efter en fil tidsstämpel.

Vad du inte bör göra

Stäng inte av PEAP-valideringen och tvinga inte fram en svagare inre metod för att komma förbi felet. Det ändrar policyn och tar bort serverautentiseringsegenskapen som fångade det utgångna certifikatet från början. Du skulle byta en fungerande kontroll mot en fungerande anslutning, och nästa utgångna certifikat skulle komma utan något som aviserade det.

Betrakta inte en lyckad anslutning från ett annat operativsystem som bevis för att certifikatet är acceptabelt. Den klienten använder kanske en annan EAP-metod, ett annat förtroendelager eller ingen servervalidering alls, så dess framgång säger ingenting om kontrollen som misslyckades här. Behåll ett medvetet negativt test, till exempel ett certifikat med fel namn eller en obetrodd kedja, som misslyckas som förväntat. Om det testet nu går igenom har du tagit bort en kontroll i stället för att reparera ett certifikat. Skriv ned vilken identitet som misslyckades, så att nästa person inte börjar om med gateway-certifikatet.