У меня есть сервер openvpn, клиенты аутентифицируются с помощью сертификатов ssl. Каждый раз, когда истекает срок действия клиентского сертификата, необходимо выпустить новый сертификат и отправить его клиенту.
Я обнаружил, что easyrsa от openvpn имеетобновитькоманда, но, насколько мне известно, на самом деле не обновляется:Easyrsa "renew" — вводящее в заблуждение название · Проблема № 345 · OpenVPN/easy-rsa
Итак, вопрос: возможно ли технически продлить срок действия SSL-сертификата независимо от того, истек ли его срок действия, чтобы избежать отправки нового файла клиенту?
решение1
Это очень хороший вопрос :-).
Technically : yes (at the end the client could use expired one to connect)
Easily : no
В принципе это невозможно, так как CA подписывает запрос на сертификат с определенным сроком действия, поэтому его нельзя продлить. Что вы можете сделать, так это создать новый сертификат, и сложная часть может заключаться в процессе выпуска и в процессе проверки действительности.
В начале было бы справедливо отметить, что нижеследующее технически связано с сертификатами в целом, и я не тестировал это с OpenVPN — если бы тест не прошёл, то общий ответ был бы НЕТ :-(.
В конфигурации openVPN есть 3 параметра, связанных с сертификатами — ca, key и cert.
key : закрытый ключ для подписи данных. Может использоваться для расшифровки данных, зашифрованныхсертификат.
cert: открытый ключ (полученный изключ) для подтверждения действительности данных, подписанных ключом. Его можно использовать для шифрования данных для ключа. Это будет предоставлено «другому концу» во время согласования безопасного соединения. / этот сценарий работает в случае, когда действительный сертификат может быть уже известен на удаленном конце, поэтому отправка сертификата может быть необязательной, а просроченный сертификат может быть проигнорирован /
ca: используется для проверки действительности сертификата, предоставленного во время согласования безопасного соединения.
После того, как срок действия клиентского сертификата истек, дело обстоит так:сертификатустарел. Ключ в принципе не имеет срока действия, и CA не должен быть просрочен (в этом случае это совершенно другой вариант использования ;-) ). Сертификат содержит срок действия и является частью "конверта", подписанного CA в структуре x.509.
Хорошей практикой является генерация нового ключа с генерацией нового сертификата, но нет ничего, что принуждало бы к этому шагу, поэтому технически не проблема создать CSR (запрос на подпись сертификата) с использованием того же ключа, что и фактически истекающий сертификат. Если у вас есть доступный старый CSR, вы можете использовать его напрямую для нового сертификата. После того, как этот CSR подписан CA, новый сертификат выводится из «старого» ключа.
Самое сложное в том, что вам понадобится (одно из):
доставьте этот новый сертификат текущему пользователю для замены сертификата
сообщить серверу об этом сертификате, чтобы его можно было использовать вместо просроченного сертификата, предоставленного клиентом (это теоретическая часть этого варианта использования ;-) )
Я знаю, что можно объединить больше сертификатов CA вокфайл, связанный в конфигурации на сервере без проблем (в формате PEM). Технически "пользовательский" сертификат и "ca" сертификат отличаются параметром, указывающим, может ли он использоваться как CA. Так что технически вы можете объединить CA сертификат с этим недавно сгенерированным сертификатом в один файл...
Как только этот файл будет на месте (вероятнее всего, потребуется перезапуск сервера OpenVPN), вы можете попробовать установить новое соединение. Как только клиент с ключом попытается подключиться, может случиться так, что сервер сможет «идентифицировать» ключ на основе хэша, связанного с этим клиентским сертификатом, расположенным на сервере, и проигнорирует сертификат, предоставленный клиентом (это необходимо проверить). Технически (с точки зрения сертификата как технологии) это будет работать, но я не пробовал это с OpenVPN. Поскольку OpenVPN использует внешнюю библиотеку для SSL-вещей, это может быть рабочим подходом ;-).
На стороне клиента необходим CA для проверки стороны сервера (он не просрочен), ключ для подписи и расшифровки связи (он не просрочен), а собственный сертификат на самом деле не нужен для локальной работы, поэтому просроченный сертификат на самом деле не проблема. Сертификат сервера получается во время согласования SSL и проверяется с помощью локального сертификата CA, поэтому все необходимое доступно (локальный ключ, удаленный сертификат).
Недостатком такого подхода является то, что вы немного теряете преимущество CA как единого сертификата для проверки клиентского сертификата (вам необходимо, чтобы он был указан на стороне сервера рядом с сертификатом CA), но с другой стороны, плюсом будет возможность продления сертификата...
Если вы попробуете, не стесняйтесь оставить отзыв...
Удачи!
Другим подходом в случае планирования может быть выпуск сертификата с длительным сроком действия и использование CRL (список перемещения сертификатов) для отзыва недействительного сертификата в течение этого времени. Но это не является предметом данного вопроса...