Verify error depth 0 error certificate has expired cn server

---

---

---

---

---

---

---

---

---

---

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 Support Forum

Community Support Forum

error=certificate has expired

error=certificate has expired

Post by rickyvaughn2 » Tue Jun 21, 2022 10:31 pm

Tue Jun 21 17:27:05 2022 VERIFY ERROR: depth=0, error=certificate has expired: CN=server_abc, serial=123

I understand that there is something that expires around 10 years but this install is only 3 years old.

I created all keys at one time. All are getting the same error implying that the certificate has expired. If I create a new key, it has the same error. ALL of these systems that connect to this VPN are remote and unmanned. Is there anything I can do on the server that can fix this?

The whole error when I try to use the new key (same error on the old keys)

Re: error=certificate has expired

Post by TinCanTech » Tue Jun 21, 2022 10:42 pm

Your server certificate has expired but not your CA certificate, which means you can make a new server certificate and everything will be ticketty-boo, until your next certificate expires.

You could try the all new Easy-RSA command `show-expire`, if you have the new Easy-RSA (git/master only)

Re: error=certificate has expired

Post by rickyvaughn2 » Wed Jun 22, 2022 1:42 pm

Re: error=certificate has expired

Post by rickyvaughn2 » Wed Jun 22, 2022 2:35 pm

I really do not want to mess this up. I believe the cert is /etc/openvpn/server_abc.crt and the key is located at /etc/openvpn/server_abc.key

I ran the command: «openssl x509 -in certificate.crt -text -noout» and I see that it did expire on the 15th

I believe I need to do the following:
Export CSR from the expired certificate: «openssl x509 -x509toreq -in server.crt -signkey server.key -out new-server.csr»
Renew self-signed certificate: «openssl x509 -req -days 365 -in new-server.csr -signkey server.key -out new-server.crt»

Questions:
Can I go more than 365 days? (looks like it is limited to 398)
Will the new-server.crt need to overwrite the existing expired one?
Do these steps look correct to not wreck the existing connections to the VPN and get this back up?

I appreciate the help, this is not my primary skill set

Источник

Перевыпуск просроченного сертификата на OpenVPN -сервере

2018-11-20 2018-11-20 Рубрики

Перевыпуск просроченного сертификата на OpenVPN -сервере

При подключении к OpenVPN-серверу неожиданно стала появляться ошибка

После анализа выяснялось, что срок действия сертификата центра сертификации (ca.crt) OpenVPN сервера истек.

Для устранения этой ошибки перевыпускаем самоподписанный сертификат центра сертификации

Старый файл сертификата ca.key можно удалить, новый (ca-new.crt) переименовать в ca.crt

Далее, перевыпускаем сертификат сервера

и перезапускаем OpenVPN

Теперь, что бы пользователи смогли подключаться к OpenVPN-серверу надо что б они на ПК заменили старый сертификат центра сертификации ca.crt на новый

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

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

Похожие записи

Установка Redmine 2.4.0

Устанавливаем необходимые библиотеки Скачиваем исходники Ruby Распаковываем Компилируем и устанавливаем Смотрим версию Устанавливаем passenger: Создаем конфигурационный файл Перезапускаем Apache Настройки хоста для Apache: Качаем Redmine Распаковываем Переносим распакованные файлы в /var/www/html/redmine Ставим Меняем владельца директории Доустанавливаем библиотеки Устанавливаем redmine Настройка подключения к базе Конфигурируем redmine для подключения к базе Открываем database.yml и прописываем логин/пароль от…

Установка Nginx в Debian 11 из репозитория

Nginx — веб-сервер и почтовый прокси-сервер, работающий на Unix-подобных операционных системах. Начиная с версии 0.7.52 появилась экспериментальная бинарная сборка под Microsoft Windows. Загружаем ключ для подписи Nginx Устанавливаем утилиту gnupg2 что бы в дальнейшем добавить скаченный ключ Добавляем загруженный ключ в список программных ключей Добавляем репозиторий Nginx Устанавливаем Nginx Запускаем Nginx и добавляем его в…

Источник

Ошибки 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
и проблемы такой больше быть не должно.

Перевыпуск просроченного сертификата на OpenVPN -сервере

При подключении к OpenVPN-серверу неожиданно стала появляться ошибка

Mon Nov 19 05:42:24 2018 VERIFY ERROR: depth=1, error=certificate has expired: C=RU, ST=ru, L=Moscow, O=Domain, CN=Domain CA, emailAddress=cert@example.com
Mon Nov 19 05:42:24 2018 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Mon Nov 19 05:42:24 2018 TLS_ERROR: BIO read tls_read_plaintext error
Mon Nov 19 05:42:24 2018 TLS Error: TLS object -> incoming plaintext read error
Mon Nov 19 05:42:24 2018 TLS Error: TLS handshake failed

После анализа выяснялось, что срок действия сертификата центра сертификации (ca.crt) OpenVPN сервера истек.

Для устранения этой ошибки перевыпускаем самоподписанный сертификат центра сертификации

[root@localhost keys]# openssl x509 -in ca.crt -days 3650 -out ca-new.crt -signkey ca.key
Getting Private key

где

ca.crt - просроченный сертификат
ca-new.crt - новый сертификат
ca.key - ключ сертификата 
3650 - срок действия, в днях

Старый файл сертификата ca.key можно удалить, новый (ca-new.crt) переименовать в ca.crt

Проверяем

[root@localhost keys]# openssl verify -CAfile ca.crt client-username.crt
client-username.crt: OK

Далее, перевыпускаем сертификат сервера

[root@localhost keys]# cd ../
[root@localhost 2.0]# . ./vars
[root@localhost 2.0]# ./build-key-server server

и перезапускаем OpenVPN

[root@localhost keys]# service openvpn restart

Теперь, что бы пользователи смогли подключаться к OpenVPN-серверу надо что б они на ПК заменили старый  сертификат центра сертификации ca.crt на новый

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

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