Verifier failure openssl cert verify error certificate has expired инстаграм

Ошибка 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, и в веб-интерфейсах оргтехники, и в контроле доступа к локальноум веб-сайту и при шифровании или подписи почты и в других областях.

Источник

4 Ways to fix SSL: CERTIFICATE_VERIFY_FAILED in Python

SSL certificate_verify_failed errors typically occur as a result of outdated Python default certificates or invalid root certificates. We will cover how to fix this issue in 4 ways in this article.

Why certificate_verify_failed happen?

The SSL connection will be established based on the following process. We will get errors if any of these steps does not go well.

For this error certificate_verify_failed, it usually happens during step 2 and step 3.

• The client sends a request to the server for a secure session. The server responds by sending its X.509 digital certificate to the client.
• The client receives the server’s X.509 digital certificate.
• The client authenticates the server, using a list of known certificate authorities.
• The client generates a random symmetric key and encrypts it using server’s public key.
• The client and server now both know the symmetric key and can use the SSL encryption process to encrypt and decrypt the information contained in the client request and the server response.

When the client receives the server’s certificate, it begins chaining that certificate back to its root. It will begin by following the chain to the intermediate that has been installed, from there it continues tracing backwards until it arrives at a trusted root certificate.

If the certificate is valid and can be chained back to a trusted root, it will be trusted. If it can’t be chained back to a trusted root, the browser will issue a warning about the certificate.

Error info about certificate_verify_failed

We will see the following error.

What is SSL certificate

Server certificates are the most popular type of X.509 certificate. SSL/TLS certificates are issued to hostnames (machine names like ‘ABC-SERVER-02’ or domain names like google.com).

A server certificate is a file installed on a website’s origin server. It’s simply a data file containing the public key and the identity of the website owner, along with other information. Without a server certificate, a website’s traffic can’t be encrypted with TLS.

Technically, any website owner can create their own server certificate, and such certificates are called self-signed certificates. However, browsers do not consider self-signed certificates to be as trustworthy as SSL certificates issued by a certificate authority.

How to fix certificate_verify_failed?

If you receive the “certificate_verify_failed” error when trying to connect to a website, it means that the certificate on the website is not trusted. There are a few different ways to fix this error.

We will skip the SSL certificate check in the first three solutions. For the fourth solution, we are going to install the latest CA certificate from certifi.

Create unverified context in SSL

import ssl
context = ssl._create_unverified_context()
urllib.request.urlopen(req,context=context)

Create unverified https context in SSL

import ssl
ssl._create_default_https_context = ssl._create_unverified_context
urllib2.urlopen(“https://google.com”).read()

Use requests module and set ssl verify to false

Update SSL certificate with PIP

we can also update our SSL certificate With PIP. All we would have to do is to update our SSL certificate directory with the following piece of code: pip install –upgrade certifi

What this command does is update our system’s SSL certificate directory.

Источник

Ошибки 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 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

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

Источник

Ошибка: «SSL certificate problem: certificate has expired»

Начиная с 1 октября 2021 начал получать много сообщений от пользователей, которые получали ошибку «SSL certificate problem: certificate has expired» при попытке обновить компонент через админку.

Ниже попытаюсь вкратце объяснить, из-за чего возникла проблема и как ее решить.

Причина ошибки:

30 сентября 2021 14:01:15 GMT закончился срок действия корневого сертификата IdenTrust DST Root CA X3.

Из-за этого стала невозможна проверка сертификатов, выпущенным центром сертификации Let’s Encrypt.

Эта проверка осуществляется при отправке запросов с вашего сервера на другой сервер через домен, который имеет SSL-сертификат Let’s Encrypt.

Потому все такие запросы, отправленные через cURL будут выдавать ошибку «SSL certificate problem: certificate has expired«

Исправление:

Если вы получаете эту ошибку при попытке обновить компонент через админку Joomla, то Вам необходимо удалить просроченный сертификат из цепочки сертификатов, которые использует Joomla.

Для этого через ФТП найдите файл /libraries/src/Http/Transport/cacert.pem (в более ранних версиях Joomla — /libraries/joomla/http/transport/cacert.pem) и скачайте его на свой ПК, чтобы сделать резервную копию.

Откройте файл и найдите строку, содержащую «DST Root CA X3«. удалите ее и все последующий блок (это и есть просроченный сертификат):

Сохраните файл на сервер.

Если же в Вашем файле сертификаты не подписаны, то найдите нужный по последним 5 буквам — CNTUQ.

Если же Вы столкнулись с ошибкой «SSL certificate problem: certificate has expired» в другом месте, то напишите в тех. поддержку своего хостинга обращение следующего содержания:

«При попытке отправки запросов через cURL получаю ошибку SSL certificate problem: certificate has expired. Удалите, пожалуйста, просроченный сертификат DST Root CA X3 из цепочки сертификатов, которую использует OpenSSL»

Источник

SSL certificate_verify_failed errors typically occur as a result of outdated Python default certificates or invalid root certificates. We will cover how to fix this issue in 4 ways in this article.

Why certificate_verify_failed  happen?

The SSL connection will be established based on the following process.   We will get errors if any of these steps does not go well.

For this error certificate_verify_failed, it usually happens during step 2 and step 3.

• The client sends a request to the server for a secure session. The server responds by sending its X.509 digital certificate to the client.
• The client receives the server’s X.509 digital certificate.
• The client authenticates the server, using a list of known certificate authorities.
• The client generates a random symmetric key and encrypts it using server’s public key.
• The client and server now both know the symmetric key and can use the SSL encryption process to encrypt and decrypt the information contained in the client request and the server response.

When the client receives the server’s certificate, it begins chaining that certificate back to its root. It will begin by following the chain to the intermediate that has been installed, from there it continues tracing backwards until it arrives at a trusted root certificate.

If the certificate is valid and can be chained back to a trusted root, it will be trusted. If it can’t be chained back to a trusted root, the browser will issue a warning about the certificate.

Related: Check SSL Certificate Chain with OpenSSL Examples

Error info about certificate_verify_failed

We will see the following error.

<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:777)>

What is SSL certificate

Server certificates are the most popular type of X.509 certificate. SSL/TLS certificates are issued to hostnames (machine names like ‘ABC-SERVER-02’ or domain names like google.com).

A server certificate is a file installed on a website’s origin server. It’s simply a data file containing the public key and the identity of the website owner, along with other information. Without a server certificate, a website’s traffic can’t be encrypted with TLS.

Technically, any website owner can create their own server certificate, and such certificates are called self-signed certificates. However, browsers do not consider self-signed certificates to be as trustworthy as SSL certificates issued by a certificate authority.

Related: 2 Ways to Create self signed certificate with Openssl Command

How to fix certificate_verify_failed?

If you receive the “certificate_verify_failed” error when trying to connect to a website, it means that the certificate on the website is not trusted. There are a few different ways to fix this error.

We will skip the SSL certificate check in the first three solutions.  For the fourth solution, we are going to install the latest CA certificate from certifi.

Create unverified context in SSL

import ssl
context = ssl._create_unverified_context()
urllib.request.urlopen(req,context=context)

Create unverified https context in SSL

import ssl
ssl._create_default_https_context = ssl._create_unverified_context
urllib2.urlopen(“https://google.com”).read()

Use requests module and set ssl verify to false

requests.get(url, headers=Hostreferer,verify=False)

Update SSL certificate with PIP

we can also update our SSL certificate With PIP.  All we would have to do is  to update our SSL certificate directory with the following piece of code: pip install –upgrade certifi

What this command does is update our system’s SSL certificate directory.

Reference:

Understanding SSL certificates

Check SSL Certificate Chain with OpenSSL Examples

5 ways to check SSL Certificate

Зачастую после установки SSL-сертификатов многие пользователи сталкиваются с ошибками, которые препятствуют корректной работе защищенного протокола HTTPS.

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

Что такое SSL?

SSL (Secure Socket Layer) — это интернет-протокол для создания зашифрованного соединения между пользователем и сервером, который гарантирует безопасную передачу данных.

Когда пользователь заходит на сайт, браузер запрашивает у сервера информацию о наличии сертификата. Если сертификат установлен, сервер отвечает положительно и отправляет копию SSL-сертификата браузеру. Затем браузер проверяет сертификат, название которого должно совпадать с именем сайта, срок действия сертификата и наличие корневого сертификата, выданного центром сертификации.

Причины возникновения ошибок SSL-соединения

Когда сертификат работает корректно, адресная строка браузера выглядит примерно так:

Но при наличии ошибок она выглядит несколько иначе:

Существует множество причин возникновения таких ошибок. К числу основных можно отнести:

• Некорректную дату и время на устройстве (компьютер, смартфон, планшет и т.д.);
• Ненадежный SSL-сертификат;
• Брандмауэр или антивирус, блокирующие сайт;
• Включенный экспериментальный интернет-протокол QUIC;
• Отсутствие обновлений операционной системы;
• Использование SSL-сертификата устаревшей версии 3.0;
• Появление ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера.

Давайте рассмотрим каждую из них подробнее.

Проблемы с датой и временем

Если на устройстве установлены некорректные дата и время, ошибка SSL-соединения неизбежна, ведь при проверке сертификата происходит проверка срока его действия. Современные браузеры умеют определять такую ошибку самостоятельно и выводят сообщение о неправильно установленной дате или времени.

Для исправления этой ошибки достаточно установить на устройстве актуальное время. После этого необходимо перезагрузить страницу или браузер.

Ненадежный SSL-сертификат

Иногда при переходе на сайт, защищенный протоколом HTTPS, появляется ошибка «SSL-сертификат сайта не заслуживает доверия».

Одной из причин появления такой ошибки, как и в предыдущем случае, может стать неправильное время. Однако есть и вторая причина — браузеру не удается проверить цепочку доверия сертификата, потому что не хватает корневого сертификата. Для избавления от такой ошибки необходимо скачать специальный пакет GeoTrust Primary Certification Authority, содержащий корневые сертификаты. После скачивания переходим к установке. Для этого:

• Нажимаем сочетание клавиш Win+R и вводим команду certmgr.msc, жмем «Ок». В Windows откроется центр сертификатов.
• Раскрываем список «Доверенные корневые центры сертификации» слева, выбираем папку «Сертификаты», кликаем по ней правой кнопкой мышки и выбираем «Все задачи — импорт».

• Запустится мастер импорта сертификатов. Жмем «Далее».

• Нажимаем кнопку «Обзор» и указываем загруженный ранее сертификат. Нажимаем «Далее»:

• В следующем диалоговом окне указываем, что сертификаты необходимо поместить в доверенные корневые центры сертификации, и нажимаем «Далее». Импорт должен успешно завершиться.

После вышеперечисленных действий можно перезагрузить устройство и проверить отображение сайта в браузере.

Брандмауэр или антивирус, блокирующие сайт

Некоторые сайты блокируются брандмауэром Windows. Для проверки можно отключить брандмауэр и попробовать зайти на нужный сайт. Если SSL-сертификат начал работать корректно, значит дело в брандмауэре. В браузере Internet Explorer вы можете внести некорректно работающий сайт в список надежных и проблема исчезнет. Однако таким образом вы снизите безопасность своего устройства, так как содержимое сайта может быть небезопасным, а контроль сайта теперь отключен.

Также SSL может блокировать антивирусная программа. Попробуйте отключить в антивирусе проверку протоколов SSL и HTTPS и зайти на сайт. При необходимости добавьте сайт в список исключений антивируса.

Включенный экспериментальный протокол QUIC

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

Показываем как отключить QUIC на примере браузера Google Chrome:

• Откройте браузер и введите команду chrome://flags/#enable-quic;
• В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

• После этого просто перезапустите браузер.

Этот способ работает и в Windows и в Mac OS.

Отсутствие обновлений операционной системы

Проблемы с SSL-сертификатами могут возникать и из-за того, что на вашей операционной системе давно не устанавливались обновлений. Особенно это касается устаревших версий Windows (7, Vista, XP и более ранние). Установите последние обновления и проверьте работу SSL.

Использование SSL-сертификата версии 3.0

Некоторые сайты используют устаревший SSL-протокол версии 3.0, который не поддерживают браузеры. По крайней мере, по умолчанию. Чтобы браузер поддерживал устаревший SSL необходимо сделать следующее (на примере браузера Google Chrome):

• Откройте браузер и перейдите в раздел «Настройки».
• Прокрутите страницу настроек вниз и нажмите «Дополнительные».
• В разделе «Система» найдите параметр «Настройки прокси-сервера» и кликните на него.

• Откроется окно. Перейдите на вкладку «Дополнительно».
• В этой вкладке вы увидите чекбокс «SSL 3.0».

• Поставьте галочку в чекбоксе, нажмите кнопку «Ок» и перезагрузите браузер.

Ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера

В процессе активации сертификата можно столкнуться с ошибкой «Invalid CSR». Такая ошибка возникает по следующим причинам:

• Неправильное имя FQDN (полное имя домена) в качестве Common Name (в некоторых панелях управления это поле может также называться Host Name или Domain Name). В этом поле должно быть указано полное доменное имя вида domain.com или subdomain.domain.com (для субдоменов). Имя домена указывается без https://. В качестве данного значения нельзя использовать интранет-имена (text.local). В запросе для wildcard-сертификатов доменное имя необходимо указывать как *.domain.com.
• В CSR или пароле есть не латинские буквы и цифры. В CSR поддерживаются только латинские буквы и цифры – спецсимволы использовать запрещено. Это правило распространяется и на пароли для пары CSR/RSA: они не должны содержать спецсимволов.
• Неверно указан код страны. Код страны должен быть двухбуквенным ISO 3166-1 кодом (к примеру, RU, US и т.д.). Он указывается в виде двух заглавных букв.
• В управляющей строке не хватает символов. CSR-запрос должен начинаться с управляющей строки ——BEGIN CERTIFICATE REQUEST—— и заканчиваться управляющей строкой ——END CERTIFICATE REQUEST——. С каждой стороны этих строк должно быть по 5 дефисов.
• В конце или начале строки CSR есть пробелы. Пробелы на концах строк в CSR не допускаются.
• Длина ключа меньше 2048 бит. Длина ключа должна быть не менее 2048 бит.
• В CRS-коде для сертификата для одного доменного имени есть SAN-имя. В CSR-коде для сертификата, предназначенного защитить одно доменное имя, не должно быть SAN (Subject Alternative Names). SAN-имена указываются для мультидоменных (UCC) сертификатов.
• При перевыпуске или продлении сертификата изменилось поле Common Name. Это поле не должно меняться.

After having worked splendidly for about half a year my piVPN server installation refuses connecting clients. From the server log file, it seems that the CA certificate has expired. I have looked around and there are some guides how to renew it, but nothing specific for the piVPN installation, so it is not directly clear how to apply it. Maybe this could be an option in the pivpn menu? Any suggestion how to resolve it?

Fri Jul 27 13:07:46 2018 us=790264 MULTI: multi_create_instance called
Fri Jul 27 13:07:46 2018 us=790712 192.168.4.100:53808 Re-using SSL/TLS context
Fri Jul 27 13:07:46 2018 us=790800 192.168.4.100:53808 LZO compression initializing
Fri Jul 27 13:07:46 2018 us=791129 192.168.4.100:53808 Control Channel MTU parms [ L:1622 D:1172 EF:78 EB:0 ET:0 EL:3 ]
Fri Jul 27 13:07:46 2018 us=791215 192.168.4.100:53808 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Fri Jul 27 13:07:46 2018 us=791412 192.168.4.100:53808 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,keydir $
Fri Jul 27 13:07:46 2018 us=791483 192.168.4.100:53808 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-l$
RFri Jul 27 13:07:46 2018 us=791670 192.168.4.100:53808 TLS: Initial packet from [AF_INET]192.168.4.100:53808, sid=e68cd7e3 4f098689
WRRWWRRWRFri Jul 27 13:07:46 2018 us=932679 192.168.4.100:53808 VERIFY ERROR: depth=0, error=CRL has expired: CN=XXXXXXX
Fri Jul 27 13:07:46 2018 us=932886 192.168.4.100:53808 OpenSSL: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
Fri Jul 27 13:07:46 2018 us=932924 192.168.4.100:53808 TLS_ERROR: BIO read tls_read_plaintext error
Fri Jul 27 13:07:46 2018 us=932958 192.168.4.100:53808 TLS Error: TLS object -> incoming plaintext read error
Fri Jul 27 13:07:46 2018 us=932991 192.168.4.100:53808 TLS Error: TLS handshake failed
Fri Jul 27 13:07:46 2018 us=933160 192.168.4.100:53808 SIGUSR1[soft,tls-error] received, client-instance restarting