Certifikát brány je v pořádku: proč přihlášení IKEv2 PEAP stále selhává

Certifikát vaší VPN brány je platný, řetězec se ověří a klient IKEv2 přesto odmítá přihlášení se zprávou o intervalu platnosti certifikátu. První instinkt je znovu vydat certifikát brány nebo změnit metodu EAP, a obojí je obvykle chyba. Pokus o přihlášení nese dvě oddělené identity serveru: certifikát brány, který používá IKE, a certifikát, který předkládá ten, kdo ukončuje PEAP. Jedna z nich je v pořádku a ta druhá je důvod, proč se klient zastavil.

Dvě identity, jeden pokus o přihlášení

Certifikát v profilu VPN patří výměně IKE: dokazuje, že brána je protějšek, který profil uvádí, podle nastavené zásady IKE. Certifikát, který zde selhává, patří jinému rozhovoru, relaci TLS, kterou PEAP otevírá s tím, kdo autentizuje uživatele, což je často server RADIUS, například NPS, a ne sama brána. Třetí kontrola, přihlašovací údaje uživatele, probíhá uvnitř této relace. Platné heslo nemůže opravit prošlý certifikát serveru a platný certifikát brány nemůže ručit za koncový bod PEAP.

Toto vrstvení vysvětluje, proč se chyba certifikátu objevuje tam, kde byl jediným nakonfigurovaným certifikátem právě ten brány. Vysvětluje také, proč nové vydání tohoto certifikátu nic nemění.

Čtěte řádek protokolu proti fázi

Najděte zprávu, která uvádí důvod a data. Stížnost na interval platnosti vedle chyby subjektu znamená, že server odmítl certifikát, který dostal, a ne že uživatel odmítl přihlášení. Pak najděte fázi: protokol charon v strongSwanu ukazuje IKE_SA .* established před začátkem výměny EAP, takže chyba certifikátu za tímto řádkem patří identitě EAP, zatímco chyba před ním ukazuje na bránu. Text fáze v panelu připojení klienta Windows říká totéž.

Zkontrolujte hodiny klienta, než se dotknete jakéhokoli certifikátu. Zařízení, které je o hodiny vedle, dává stejnou chybu platnosti jako skutečně prošlý certifikát. Seřízení hodin je oprava na pět sekund a výměna certifikátu, který nikdy nebyl problémem, je výpadek.

Zjistěte, který koncový bod ukončuje PEAP

V uspořádání brána plus RADIUS brána předává EAP dál a neukončuje ho. Zásuvný modul eap-radius v strongSwanu předá výměnu serveru RADIUS, který vlastní relaci TLS PEAP a její certifikát. Zkorelujte jeden neúspěšný pokus v obou protokolech a potvrďte, který proces pro tuto relaci skutečně vybral certifikát.

U NPS musí certifikát být v úložišti místního počítače, nést účel ověření identity serveru, odpovídat názvu, který klienti očekávají, a být čitelný pro servisní účet. Požadavky Microsoftu na certifikáty pro NPS tyto podmínky vypočítávají. Jiné servery EAP mají vlastní pravidla výběru, takže nekopírujte specifika NPS do nasazení FreeRADIUS ani naopak. Pravidlo, které platí v obou případech, je, že koncový bod ukončující PEAP vlastní certifikát, který se chystáte změnit.

Vyměňte certifikát tam, kde EAP končí

Obnovte nebo vyměňte certifikát na koncovém bodu, který ukončuje PEAP, podporovaným postupem, se zachováním účelu ověření identity serveru a očekávaného názvu. Nainstalujte celý řetězec tam, kde ho služba hledá, a dejte službě přístup k soukromému klíči. Restartujte nebo znovu připojte službu, protože mnoho služeb drží starý certifikát v paměti a dál ho předkládá. Soubor zkopírovaný na stroj nic nedokazuje o tom, který certifikát služba skutečně předkládá.

Změnu potvrďte zkorelováním dalšího pokusu s vlastním protokolem služby nebo prohlédnutím certifikátu, který relace předložila. Pokud ten protokol stále ukazuje starý otisk, restart nezabral.

Nepředpokládejte, že nejnovější soubor v adresáři je ten, který se používá. Kopie se správným názvem a špatnými oprávněními nic nemění. Změnu posuzujte podle předložené identity, ne podle časového razítka souboru.

Co nedělat

Nevypínejte ověřování PEAP a nevynucujte slabší vnitřní metodu, abyste chybu obešli. Tím měníte zásadu a odstraňujete vlastnost ověření identity serveru, která prošlý certifikát vůbec zachytila. Vyměnili byste fungující kontrolu za fungující spojení a další prošlý certifikát by přišel bez čehokoli, co by ho ohlásilo.

Nepovažujte úspěšné připojení jiného operačního systému za důkaz, že je certifikát přijatelný. Ten klient může používat jinou metodu EAP, jiné úložiště důvěry nebo vůbec žádné ověření serveru, takže jeho úspěch nic neříká o kontrole, která zde selhala. Zachovejte jeden záměrný negativní test, například certifikát se špatným názvem nebo nedůvěryhodný řetězec, který podle očekávání selže. Pokud tento test nyní projde, odstranili jste kontrolu, a ne opravili certifikát. Zapište, která identita selhala, aby příští člověk nezačínal znovu certifikátem brány.