Сертификатът на шлюза е наред: защо входът IKEv2 PEAP все още се проваля

Сертификатът на VPN шлюза ви е валиден, веригата се проверява, а IKEv2 клиентът все още отказва входа със съобщение за срок на валидност на сертификат. Първият импулс е да преиздадете сертификата на шлюза или да смените EAP метода, и двете обикновено са грешка. Опитът за вход носи две отделни сървърни идентичности: сертификата на шлюза, който IKE използва, и сертификата, който представя този, който прекратява PEAP. Едната е наред, а другата е причината клиентът да спре.

Две идентичности, един опит за вход

Сертификатът в VPN профила принадлежи на IKE обмена: той доказва, че шлюзът е страната, която профилът посочва, при зададената IKE политика. Сертификатът, който се проваля тук, принадлежи на друг разговор — TLS сесията, която PEAP отваря с този, който удостоверява потребителя, често RADIUS сървър като NPS, а не самият шлюз. Трета проверка, потребителските данни, се извършва вътре в тази сесия. Валидна парола не може да поправи изтекъл сървърен сертификат, а валиден шлюзов сертификат не може да гарантира за PEAP крайната точка.

Това подреждане обяснява защо грешка за сертификат се появява там, където единственият конфигуриран сертификат е бил този на шлюза. Обяснява и защо преиздаването на този сертификат не променя нищо.

Четете реда от журнала спрямо етапа

Намерете съобщението, което посочва причината и датите. Оплакване за срок на валидност до грешка за субект означава, че сървърът е отхвърлил сертификата, който му е даден, а не че потребителят е отхвърлил входа. После намерете етапа: журналът charon на strongSwan показва IKE_SA .* established преди да започне EAP обменът, така че грешка за сертификат след този ред принадлежи на EAP идентичността, а грешка преди него сочи към шлюза. Текстът за етапа в панела за връзка на Windows клиент казва същото.

Проверете часовника на клиента, преди да пипате какъвто и да е сертификат. Устройство, което изостава с часове, дава същата грешка за валидност като наистина изтекъл сертификат. Нулирането на часовника е поправка за пет секунди, а подмяната на сертификат, който никога не е бил проблемът, е прекъсване.

Открийте коя крайна точка прекратява PEAP

При схема шлюз плюс RADIUS шлюзът препредава EAP и не го прекратява. Плъгинът eap-radius на strongSwan предава обмена на RADIUS сървъра, който притежава PEAP TLS сесията и нейния сертификат. Съпоставете един неуспешен опит по двата журнала и потвърдете кой процес действително е избрал сертификат за тази сесия.

За NPS сертификатът трябва да е в хранилището на локалния компютър, да носи предназначението за удостоверяване на сървър, да съвпада с името, което клиентите очакват, и да е четим от служебния акаунт. Изискванията на Microsoft за сертификати за NPS изброяват тези условия. Другите EAP сървъри имат собствени правила за избор, затова не копирайте особеностите на NPS в инсталация с FreeRADIUS или обратното. Правилото, което остава вярно и в двата случая, е, че крайната точка, която прекратява PEAP, притежава сертификата, който ще сменяте.

Подменете сертификата там, където EAP прекратява

Подновете или подменете сертификата на крайната точка, която прекратява PEAP, чрез поддържания процес, като запазите предназначението за удостоверяване на сървър и очакваното име. Инсталирайте пълната верига там, където услугата я търси, и дайте на услугата достъп до частния ключ. Рестартирайте или презакачете услугата, защото много услуги пазят стария сертификат в паметта и продължават да го представят. Файл, копиран на машината, не доказва нищо за това кой сертификат услугата действително представя.

Потвърдете промяната, като съпоставите следващия опит със собствения журнал на услугата или като прегледате сертификата, който сесията е представила. Ако този журнал още показва стария отпечатък, рестартът не е сработил.

Не смятайте, че най-новият файл в папка е този, който се използва. Копие с правилното име и грешните права не променя нищо. Съдете за промяната по представената идентичност, а не по времева марка на файл.

Какво да не правите

Не изключвайте проверката на PEAP и не налагайте по-слаб вътрешен метод, за да прескочите грешката. Това променя политиката и премахва свойството за удостоверяване на сървър, което първо хвана изтеклия сертификат. Ще размените работеща проверка за работеща връзка, а следващият изтекъл сертификат ще дойде без нищо, което да го обяви.

Не приемайте успешна връзка от друга операционна система като доказателство, че сертификатът е приемлив. Онзи клиент може да ползва друг EAP метод, друго хранилище за доверие или изобщо без проверка на сървъра, така че успехът му не казва нищо за проверката, която се провали тук. Дръжте един умишлен негативен тест — например сертификат с грешно име или недоверена верига — който се проваля както се очаква. Ако този тест сега минава, вие сте премахнали проверка, а не сте поправили сертификат. Запишете коя идентичност се провали, за да не започва следващият човек отново със сертификата на шлюза.