У меня есть работающий (до сих пор) сервер ubuntu openvpn.
Я думаю, что мой сервер использует неправильный ЦС для подписи клиентских CRT.
Например:
Я использую «source ./vars», за которым следует «./build-key john.doe», и все работает нормально (под «нормально работать» я имею в виду, что я получаю csr, crt и ключ john.doe).
Но если я протестирую crt с помощью: "openssl verify -CAfile ca.crt keys / john.doe.crt", я получу следующее:
keys / john.doe.crt: C = VE, ST = MI, L = Caracas, O = www www, CN = john.doe, emailAddress = me@myhost.mydomain ошибка 20 при поиске глубины 0: невозможно получить локального эмитента свидетельство
Тестирование любого работающего (и более старого) клиента crt не вызывает ошибок ...
Я тоже пробовал эту команду: «openssl x509 -in keys / jhon.doe.crt -noout -text | grep Issuer» и выдает:
Эмитент: C = VE, ST = MI, L = Caracas, O = www www, CN = fred.durst / name = Fred Durst/emailAddress=me@myhost.mydomain
Что довольно странно, потому что Фред Дерст - клиент, а не центр сертификации ...
Когда я пробую ту же команду с работающим клиентом crt, она выдает:
Эмитент: C = VE, ST = MI, L = Caracas, O = www www, OU = Section, CN = SGBVPN / name = SGBVPN
Мне это кажется прекрасным ... Любопытно, что Фред Дерст был последним созданным crt до того, как возникла эта проблема .. Все старые клиентские crt, созданные до fred.durst, работают нормально, проблема просто возникает только с новыми ключами .. .
Какие-нибудь подсказки? TIA
Стандартного способа создания этих сертификатов не существует. В зависимости от содержания вашего скрипта он может выполнять несколько функций. Однако я собираюсь указать на две вещи.
Во-первых, вы не сказали, что соединение не работает. Я очень надеюсь, что никто не сможет аутентифицироваться с помощью этих сертификатов; если да, то это означает, что любой пользователь может подписать еще один произвольный запрос сертификата и предоставить доступ к вашей VPN. Способ предотвратить это - выпустить сертификаты, которые явно не являются сертификатами CA и имеют только необходимые атрибуты использования ключа.
В любом случае, обычно вы будете подписывать сертификаты с помощью openssl ca команда, которая зависит от параметров из openssl.conf файл (обычно в /etc/openssl.conf или указан в командной строке). Убедитесь, что параметры здесь верны. Найдите сертификат CA и ключ, который он использует, и убедитесь, что они верны (опять же, это либо в файле конфигурации openssl, либо в командной строке).
Если вы не используете openssl, применимо то же самое общее решение - найдите сертификат CA и убедитесь, что он не был заменен случайно.
Если вам каким-то образом удалось перезаписать ключ (или это сделал кто-то другой), вам придется найти резервную копию или перестроить свой PKI.
Без содержания вашего сценария я мало что могу вам сказать.