Как проверяется клиентский ssl сертификат?

Question

[rutest]

Решил попробовать организовать свой CA (Certificate Authority) для создания и подписи сертификатов OpenVPN. В данный момент вникаю в детали - перечитал множество иструкций, но никак не пойму каким образом проходит проверка подлинности клиентского сертификата, если CA находится на изолированной (не подключенной к интернету) машине. Обращается ли вообще клиент к CA? Если не трудно по подроблее разъясните.

Answer 1

[KeyDoo]

Подлинность проверяется основываясь на списке доверенных сертификатов которые лежат на сервере. Можете добавить в этот список свой. И им подписывать клиентские.

Конкретно в каком файле они находятся у OpenVPN не подскажу, но рыть в сторону bundle-ca, ca.crt

Comments

[rutest]

Допустим, создал серверный сертификат для OpenVPN подписал его корневым. Добавил корневой сертификат CA в список доверенных. Как проверяется не отозвал ли CA серверный сертификат?

[Николай Корабельников]

Для этого есть CRL.

Answer 2

[Руслан Федосеев]

Генерируется CA.
Генерируется серверный сертификат, подписывается CA
Генерируется клиентский сертификат, подписывается серверным.

При проверке пользователя проверяется клиенский сертификат, который подписан серверным сертификатом, доступ к которому есть у сервера.

Comments

[rutest]

А как сервер проверяет отозван его сертификат или нет?

[Руслан Федосеев]

создается и поддерживается crl лист для отозванных сертификатов. Сервер должен иметь к нему доступ.

[rutest]

Руслан Федосеев: crl лист создается на отдельной от CA машине?

[Руслан Федосеев]

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

[Николай Корабельников]

Про CRL важно заметить, что URL, по которому доступен CRL должен быть указан в сертификате пользователя и при проверке сертификата на отзыв, проверяющая сторона будет искать CRL именно там.

[rutest]

Николай Корабельников: Какой параметр отвечает за URL не подскажите? Как его указывать при создании клиентского сертификата?

[Николай Корабельников]

rutest:
Это может быть ссылка http, но допускается и ldap:// и даже ftp://.

[rutest]

Николай Корабельников: Это понятно, что http ссылка, а как её указать при создании сертификата?

[Николай Корабельников]

rutest: если вы делаете УЦ, то, наверно, используете какой-то PKI. Я работал с несколькими разными PKI, в т.ч. Microsoft CA, OpenTrust PKI, neXus CA. Какой софт используете вы для подписи открытых ключей?

[Руслан Федосеев]

скорее всего непосредственно с openssl в командной строке.
Посмотрите в примерах и документации. Там есть, как создать и поддерживать crl лист.

[Николай Корабельников]

вот например для нелюбимого мной мелкомягкого PKI:

[rutest]

Николай Корабельников: easy-rsa

[rutest]

Руслан Федосеев: С созданием разобрался. А вот как при создании клиентского сертификата указать ссылку на расположение CRL листа?

[Николай Корабельников]

rutest: к сожалению, не работал с easy-rsa. Судя по всему, easy-rsa представляет собой надстройку над openssl. Вероятно, вы сможете генерировать сертификаты коммандой openssl, с указанием расширения CRL Distribution Point. Тогда можно следовать ответу на этот вопрос: stackoverflow.com/questions/11966123/howto-create-...

Вообще, это не очень-то удобно - работать с сертификатами из командной строки. Лучше иметь нормальный интерфейс. Иметь возможность быстро определить статус сертификата, отозвать его.
Могу посоветовать opensource PKI с удобным веб-интерфейсом: retrust.me
Проект активно развивается и предоставляет очень неплохие возможности для управления сертификатами.
Если нужна будет помощь по нему или одному из указанных выше PKI - обращайтесь.