Щзутмзт error crl has expired

Достаточно часто при использовании списка отозванных сертификатов через месяц становится невозможно установить связь с сервером OpenVPN. В логах OpenVPN появляется ошибка установления соединения с сервером:

TLS: Initial packet from [AF_INET]ХХ.ХХ.ХХ.ХХ:62889, sid=ba13f8a4 4c4aec28
VERIFY ERROR: depth=0, error=CRL has expired: CN=client1
OpenSSL: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, client-instance restarting

Причина — в превышении времени жизни списка отозванных сертификатов, который хранится в файле crl.pem (CRL — certificate revoke list). Проверить это можно выдав следующую команду:

$ sudo openssl crl -inform PEM -in /etc/openvpn/easy-rsa/keys/crl.pem -text -noout
[sudo] пароль для user1: 
Certificate Revocation List (CRL):
Version 1 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=RU/ST=RU/L=Moscow/O=ХХХХ/OU=ХХХХ/CN=ХХХХ/name=EasyRSA/emailAddress=хххх@yourmail.ru
Last Update: Sep 10 09:26:36 2020 GMT
Next Update: Sep 11 09:26:36 2021 GMT

Из вывода видно что не позднее 11 сентября необходимо перевыпустить список отозванных сертификатов. Иначе будет появляться эта ошибка.

Можно конечно перевыпустить список ещё на год, но лучше всё таки увеличить его срок жизни.

Время жизни списка отозванных сертификатов задается в файле /etc/openvpn/easy-rsa/openssl-1.0.0.cnf в следующей секции:

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crl_extensions = crl_ext

default_days = 3650 # how long to certify for
default_crl_days= 365 # how long before next CRL
default_md = sha256 # use public key default MD
preserve = no # keep passed DN ordering

default_crl_days= 365 это и есть количество дней до перевыпуска списка отозванных сертификатов или время жизни этого списка. Открываем файл конфигурации любимым редактором, например nano:

$ sudo nano  /etc/openvpn/easy-rsa/openssl-1.0.0.cnf

и изменяем default_crl_days= 365 на, например, default_crl_days= 3650. То-есть на 10 лет. Затем перевыпускаем сам список:

$ sudo su
# cd /etc/openvpn/easy-rsa
# openssl ca -gencrl -keyfile keys/ca.key -cert keys/ca.crt -out keys/crl.pem -config ./openssl-1.0.0.cnf
# exit

Проверяем:

$ sudo openssl crl -inform PEM -in /etc/openvpn/easy-rsa/keys/crl.pem -text -noout
[sudo] пароль для user1: 
Certificate Revocation List (CRL):
Version 1 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=RU/ST=RU/L=Moscow/O=ХХХХ/OU=ХХХХ/CN=ХХХХ/name=EasyRSA/emailAddress=хххх@yourmail.ru
Last Update: Sep 10 09:26:36 2020 GMT
Next Update: Sep 11 09:26:36 2030 GMT

Все нормально и все должно работать.

freebsd команды, настройка, установка сервера и не только

Ошибка VERIFY ERROR: depth=0, error=CRL has expired в openvpn.log

Столкнулся с проблемой, когда клиенты не могут подключиться к openvpn серверу, запущенному на ubuntu server, при этом на сервере в логах openvpn постоянно сыпется ошибка:
WARNING: Failed to stat CRL file, not (re)loading CRL.
VERIFY ERROR: depth=0, error=CRL has expired: CN= название_клиента
И уж раз пришлось решать проблему, то 2 варианта её решения опишу здесь.
Все действия выполнялись на ubuntu server 20.04.

Вариант решения 1:
Смотрим в консоли ubuntu server:
cd /etc/openvpn/server
sudo openssl crl -inform PEM -in crl.pem -text -noout
вижу:
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm:
Issuer: CN = имя
Last Update: Jan 6 18:59:07 2021 GMT
Next Update: Jul 5 18:59:07 2021 GMT

Конфиг /etc/openvpn/server/server.conf службы openvpn содержит у меня строку:
crl-verify /etc/openvpn/server/crl.pem
которая как раз говорит о том, какие сертификаты отозваны. Если для вас не важно отзывать сертификаты клиентов, то в конфигурационном файле /etc/openvpn/server/server.conf закомментируйте строку выше и перезапустите службу openvpn, проблема должна устраниться. Если же важно блокировать подключение клиентам с отозванными сертификатами, то строку не комментируем а переходим к решению номер 2.

Вариант решения 2.
в /etc/easy-rsa/vars вписываем параметр:
set_var EASYRSA_CRL_DAYS 36500

Так как генерировал сертификаты я с помощью easyrsa, то сделаем сначала резервную копию файла /etc/openvpn/server/crl.pem
sudo cp /etc/openvpn/server/crl.pem /etc/openvpn/server/crl.pem-bkp
и генерируем новый /etc/openvpn/server/crl.pem
cd /etc/easy-rsa/
sudo ./easyrsa gen-crl
После генерации не забудьте переложить его из /etc/easy-rsa/pki/ в место, которое указывали в конфиге openvpn сервера /etc/openvpn/server/server.conf в строке crl-verify /etc/openvpn/server/crl.pem

После генерации, проверяем:
cd /etc/openvpn/server
sudo openssl crl -inform PEM -in crl.pem -text -noout
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm:
Issuer: CN = имя
Last Update: Jul 7 05:50:04 2021 GMT
Next Update: Jun 13 05:50:04 2121 GMT

Видим, что сгенерировали на 100 лет вперёд, вы можете генерировать на нужный вам период. Здесь 100 лет (35500 дней) просто для примера.
Перезапускаем службу openvpn
sudo service openvpn restart
и проблемы такой больше быть не должно.

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник

Ошибка OpenVPN CRL has expired (просрочен список CRL)

Сразу после обновления OpenVPN до версии 2.4.1(и, соответственно, после рестарта службы), клиенты не смогли подключиться к серверу, а на сервере в логе было что-то вроде:

TLS: Initial packet from [AF_INET]19.10.5.11:51849, sid=ba13f8a4 4c4aec28
VERIFY ERROR: depth=0, error=CRL has expired: CN=client1
OpenSSL: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, client-instance restarting

Это ошибка проверки списка отзывов сертификатов (CRL — certificate revoke list).

Возможно, это и не связано с версией 2.4, просто очень долго не нужно было перезапускать сервис OpenVPN, а тут при обновлении пришлось.

В конфиге сервера список CRL указан директивой:

Убедиться, что проблема в этом списке, можно закомментировав эту строку в конфиге сервера и перезапустив сервер. Если дело только в списке отозванных сертификатов, клиенты спокойно начнут подключаться.

Для решения проблемы со списком CRL надо этот список обновить. В зависимости от того, каким образом вы управляете ключами OpenVN, это может быть по-разному.

Перед любыми действиями с CA рекомендую сделать архив:

# tar -cvzf /backup/openvpn.tar.gz /etc/openvpn

1) OpenSSL (общий случай):

# openssl ca -gencrl -keyfile ca.key -cert ca.crt -out crl.pem -config openssl.cnf

далее файл crl.pem скопировать в рабочее расположение OpenVPN и рестарт OpenVPN-сервера.

2) EasyRSA (версия 3):

# cd /etc/openvpn/easy-rsa
# ./easyrsa gen-crl

далее файл crl.pem скопировать в рабочее расположение OpenVPN:

# mv pki/crl.pem /etc/openvpn/

Рестарт сервера OpenVPN:

# systemctl restart openvpn@server

3) EasyRSA (версия 2) + OpenSSL

Не нашел специальной команды на обновление CRL с помощью EasyRSA 2, пришлось использовать openssl.

# cd /etc/openvpn/easy-rsa/2.0/
# . /etc/openvpn/easy-rsa/2.0/vars
# echo $KEY_CONFIG
/etc/openvpn/easy-rsa/2.0/openssl-1.0.0.cnf

По-умолчанию, обновление списка отозванных сертификатов производится раз в 30 дней. Это указано в конфиге в секции [ CA_default ]:

Можно увеличить этот интервал, например:

# openssl ca -gencrl -keyfile keys/ca.key -cert keys/ca.crt -out keys/crl.pem -config openssl-1.0.0.cnf

error on line 145 of /etc/openvpn/easy-rsa/openssl-1.0.0.cnf
4352345234545:error:0E065068:configuration file routines:STR_COPY:variable has no value:conf_def.c:618:line 145

Это из-за того, что скрипт vars не экспортировал переменную, которую использует конфиг openssl-1.0.0.cnf. В скрипте vars раскомментировал директиву export KEY_CN=»CommonName» (была в самом конце файла). Еще раз выполнил экспорт:

# openssl ca -gencrl -keyfile keys/ca.key -cert keys/ca.crt -out keys/crl.pem -config openssl-1.0.0.cnf

Можно просмотреть выпущенный сертификат CRL:

# openssl crl -inform PEM -in keys/crl.pem -text -noout

В информации будет указан список отозванных ключей (серийные номера), дата обновления и ближайшая необходимая дата регенерации CRL.

Далее файл crl.pem скопируем в рабочее расположение OpenVPN и рестартуем OpenVPN-сервер:

# service openvpn restart

Дополнительно

Открытым остался вопрос: все дело в просроченном сроке обновления сертификата CRL (default_crl_days) или только из-за обновления OpenVPN, не знаю. Проблема решена, дальше будет видно.

Все вышеописанное говорит о том, что в основе всех «easyrsa» скриптов лежит обычный openssl, поэтому 1) при возможности тренируйтесь в понимании «чистого» openssl, 2) имейте ввиду, что сертификаты openvpn могут быть частью общей инфраструктуры (например, у вас может быть свой корпоративный CA, чей сертификат установлен как корневой доверенный везде, а подписанные им сертификаты используются и в OpenVPN, и в веб-интерфейсах оргтехники, и в контроле доступа к локальноум веб-сайту и при шифровании или подписи почты и в других областях.

Источник

Ошибка OpenVPN CRL has expired (просрочен список CRL)

Сегодня речь пойдет об одном нюансе, связанном со списком отозванных сертификатов (Сertificate Revocation List, CRL) в OpenVPN. Данный механизм применяется, когда требуется блокировать доступ отдельных узлов к сети (в случае увольнения сотрудника или подозрения что выданный сертификат скомпрометирован).

В какой-то момент времени, может возникнуть ошибка OpenVPN CRL has expired (просрочен список CRL) и клиенты перестают подключаться. Убедиться, что проблема именно в этом довольно просто, достаточно закомментировать в конфиге сервера строку проверки отозванных сертификатов и перезапустить сервер.

После чего клиенты спокойно начнут подключаться.

Обновление списка отозванных сертификатов OpenVPN

Для решения проблемы со списком CRL надо этот список обновить. Делается это элементарно, о чём я уже рассказывал в статье про отзыв пользовательских сертификатов OpenVPN на FreeBSD 10/11:

Почему возникла данная проблема? Дело в том, что периодичность обновление списка отозванных сертификатов задаётся в переменной default_crl_days в конфиге /usr/local/openvpn/easy-rsa/openssl-1.0.cnf:

Сами значения переменных задаются в файле /usr/local/openvpn/easy-rsa/vars. По умолчанию обновление списка CRL происходит каждые 180 дней (можно задать своё значение, например 365 дней) :

Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.

Комментариев: 3

Ой спасибо добрый человек. Два дня искал в чем проблема.

очень помогло. сегодня по той же причине openVPN сервер перестал принимать соединения и отрубил все которые были

Сегодня такая же проблема была. Всё заработало!

Источник

Openvpn verify error depth 0 error crl has expired

После обновления OpenVPN либо после переноса на другую ОС можно получить ошибку “OpenVPN CRL has expired”. Клиенты не смогут подключиться к серверу.

На сервере в логе будет что-то вроде:

Это ошибка проверки списка отзывов сертификатов (CRL – certificate revoke list).

В конфиге сервера список CRL указан директивой:

Убедиться, что проблема в этом списке, можно закомментировав эту строку в конфиге сервера и перезапустив сервер. Если дело только в списке отозванных сертификатов, клиенты спокойно начнут подключаться.

Для решения проблемы со списком CRL надо этот список обновить. В зависимости от того, каким образом вы управляете ключами OpenVN, это может быть по-разному.

Перед любыми действиями с CA рекомендую сделать архив:

# tar -cvzf /backup/openvpn.tar.gz /etc/openvpn

1) OpenSSL (общий случай):

# openssl ca -gencrl -keyfile ca.key -cert ca.crt -out crl.pem -config openssl.cnf

Далее файл crl.pem скопировать в рабочее расположение OpenVPN и рестарт OpenVPN-сервера.

2) EasyRSA (версия 3):

# cd /etc/openvpn/easy-rsa
# ./easyrsa gen-crl

Далее файл crl.pem скопировать в рабочее расположение OpenVPN:

# mv pki/crl.pem /etc/openvpn/

Рестарт сервера OpenVPN:

# systemctl restart openvpn@server

3) EasyRSA (версия 2) + OpenSSL

Не нашел специальной команды на обновление CRL с помощью EasyRSA 2, пришлось использовать openssl.

# cd /etc/openvpn/easy-rsa/2.0/
# . /etc/openvpn/easy-rsa/2.0/vars
# echo $KEY_CONFIG
/etc/openvpn/easy-rsa/2.0/openssl-1.0.0.cnf

По-умолчанию, обновление списка отозванных сертификатов производится раз в 30 дней. Это указано в конфиге в секции [ CA_default ]:

default_crl_days= 30

Можно увеличить этот интервал, например:

default_crl_days= 365

После изменения выполняем команду:

# openssl ca -gencrl -keyfile keys/ca.key -cert keys/ca.crt -out keys/crl.pem -config openssl-1.0.0.cnf

На этом этапе может возникнуть ошибка вроде configuration file routines:STR_COPY:variable has no value:conf_def.c

Можно просмотреть выпущенный сертификат CRL:

# openssl crl -inform PEM -in keys/crl.pem -text -noout

В информации будет указан список отозванных ключей (серийные номера), дата обновления и ближайшая необходимая дата регенерации CRL.

Источник

Ошибки OpenVPN — CRL has expired и CRL signature failure

В то время как все нормальные люди отдыхают, системные администраторы переносят сервисы в дни минимальных нагрузок. В очередной раз мне пришлось перенести работающий шлюз на старой версии freebsd на современную centos 7. Так как я переносил шлюзы уже много раз, предполагал, что возникнут непредвиденные трудности. Они и возникли с openvpn.

Мои предположения оправдались. Теоретически все выглядело понятно и достаточно просто. Шлюзы я много раз переносил и уже приноровился. Последовательность действий всегда примерно одинаковая:

1. Берем свободный внешний ip и настраиваем на нем новый сервер.
2. Переносим настройки фаервола, переносим таблицу маршрутов, делаем заготовки для переноса сетевых настроек.
3. Запускаем на новом сервере идентичные сервисы, отлаживаем их работу.
4. Цепляемся какой-нибудь виртуалкой к новому шлюзу и все проверяем.
5. Выключаем старый шлюз, убираем его из автозагрузки, если он на виртуалке, и переносим его сетевые настройки на новый шлюз.
6. Вместо пятого пункта, можно просто на dhcp поменять для клиентов дефолтный шлюз и ждать, когда они обновят свои сетевые настройки.

Правильнее и удобнее делать все по 6-му пункту, так как так проще откатиться назад в случае нештатной ситуации. Можно оставить два шлюза одновременно работающими и отлаживать их одновременно. К сожалению, чаще всего так сделать не получается по разным причинам (много клиентов с ручными настройками сети, dhcp сервер на этом же шлюзе и т.д.)

В общем, ситуации бывают разные, но план всегда примерно такой. Более подробный план я всегда стараюсь составить отдельно, где прописываю все шаги, чтобы в ключевой момент, когда ты приезжаешь в нерабочее время, не тратить лишних сил на те вещи, которые можно сделать заранее.

В этот раз я поленился все проверить заранее. Даже не то, что поленился. Просто праздники и у меня много времени в запасе. Решил сразу все делать на месте, прикинув простой план в голове.

Сложность возникла с переносом настроек и сертификатов openvpn сервера. Было много разных туннелей под разные задачи с разными настройками. Но не в этом суть, перенести их дело техники. Первой проявилась следующая проблема.

Я перенес настройки и сертификаты openvpn первого тоннеля, запустил его. На вид все в порядке, тоннель запустился без ошибок. Стал подключаться клиентом — он не подключается. В логе сервера ошибка:

Я сразу уловил суть ошибки и стал гуглить. Проблема была в файле отозванных сертификатов. Если его не использовать, то все работало нормально и клиенты openvpn подключались. Но я не мог от него отказаться, отзывов было очень много, я не мог допустить возможности подключиться отозванным сертификатам.

Решение проблемы нашлось достаточно быстро, ошибка весьма популярная. Не буду на ней останавливаться подробно, я воспользовался вот этой статьей — https://bozza.ru/art-287.html, там есть вся необходимая информация.

Я проверил свой файл, оказалось, он действительно был просрочен.

Отредактировал конфиг openssl.cnf, увеличил срок жизни файла и пересоздал его.

Закинул новый файл в директорию с openvpn и перезапустил тоннель. Еще порадовался, что быстро решил проблему. Но как оказалось, мои проблемы только начались. При подключении клиента к новому openvpn серверу, снова выскакивала ошибка, но уже принципиально другая:

Тут наскоком решить вопрос не получилось. Стал опять шерстить англоязычный поиск на релевантную тему. Похожих запросов именно с crl почти не было, а там где были, не было решений. И вообще было не очень понятно, в чем тут дело. Но худо бедно картинка началась складываться. Я так же не мог добавить новый сертификат к списку отзыва со старыми настройками openssl, получал ошибку.

Дело оказалось вот в чем. Я переносил сертификаты openvpn с очень старого сервера freebsd 8.2, который настраивали примерно в 2010 году. Для генерации файла отзывов сертификатов (Certificate Revocation List (CRL) использовался алгоритм вычисления хэша md5, который не поддерживается в Centos 7, так как считается небезопасным.

В моих планах не было экстренного перевыпуска клиентских сертификатов, а как собрать полный новый список отзывов, на основе существующего, я не знаю. Думаю, это возможно, но я пошел по другому пути. Пришлось искать временное решение проблемы, которое даст время для плановой смены всего устаревшего.

Для того, чтобы в CentOS 7 можно было работать с md5, нужно добавить в окружение следующие переменные:

Для этого достаточно просто в консоли ввести:

Можно добавить эти переменные в easy-rsa/vars. Это позволит вам продолжать вести старый список отзывов для openvpn. Для того, что служба openvpn применила эти переменные и начала нормально работать с md5, необходимо привести конфиг systemd к следующему виду:

После этого все запускаемые тоннели или добавленные в автозагрузку скрипты запуска для openvpn в systemd (в /etc/systemd/system/multi-user.target.wants), будут созданы с этими значениями окружения.

После этих изменений мои клиенты openvpn стали нормально подключаться к серверу. К счастью, сертификаты клиентов были сгенерированы c применением хэша sha1, который пока еще не запретили.

Если у вас еще нет своего vpn сервера, рекомендую мою подробную статью на эту тему — настройка openvpn сервера.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите подробнее программу по ссылке.

Источник

Столкнулся с проблемой, когда клиенты не могут подключиться к openvpn серверу, запущенному на ubuntu server, при этом на сервере в логах openvpn постоянно сыпется ошибка:
WARNING: Failed to stat CRL file, not (re)loading CRL.
VERIFY ERROR: depth=0, error=CRL has expired: CN= название_клиента
И уж раз пришлось решать проблему, то 2 варианта её решения опишу здесь.
Все действия выполнялись на ubuntu server 20.04.

Вариант решения 1:
Смотрим в консоли ubuntu server:
cd /etc/openvpn/server
sudo openssl crl -inform PEM -in crl.pem -text -noout
вижу:
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm:
Issuer: CN = имя
Last Update: Jan 6 18:59:07 2021 GMT
Next Update: Jul 5 18:59:07 2021 GMT

Конфиг /etc/openvpn/server/server.conf службы openvpn содержит у меня строку:
crl-verify /etc/openvpn/server/crl.pem
которая как раз говорит о том, какие сертификаты отозваны. Если для вас не важно отзывать сертификаты клиентов, то в конфигурационном файле /etc/openvpn/server/server.conf закомментируйте строку выше и перезапустите службу openvpn, проблема должна устраниться. Если же важно блокировать подключение клиентам с отозванными сертификатами, то строку не комментируем а переходим к решению номер 2.

Вариант решения 2.
в /etc/easy-rsa/vars вписываем параметр:
set_var EASYRSA_CRL_DAYS 36500

Так как генерировал сертификаты я с помощью easyrsa, то сделаем сначала резервную копию файла /etc/openvpn/server/crl.pem
sudo cp /etc/openvpn/server/crl.pem /etc/openvpn/server/crl.pem-bkp
и генерируем новый /etc/openvpn/server/crl.pem
cd /etc/easy-rsa/
sudo ./easyrsa gen-crl
После генерации не забудьте переложить его из /etc/easy-rsa/pki/ в место, которое указывали в конфиге openvpn сервера /etc/openvpn/server/server.conf в строке crl-verify /etc/openvpn/server/crl.pem

После генерации, проверяем:
cd /etc/openvpn/server
sudo openssl crl -inform PEM -in crl.pem -text -noout
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm:
Issuer: CN = имя
Last Update: Jul 7 05:50:04 2021 GMT
Next Update: Jun 13 05:50:04 2121 GMT

Видим, что сгенерировали на 100 лет вперёд, вы можете генерировать на нужный вам период. Здесь 100 лет (35500 дней) просто для примера.
Перезапускаем службу openvpn
sudo service openvpn restart
и проблемы такой больше быть не должно.