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

В предыдущих статьях на тему OpenVPN я рассказывал как настроить openVPN сервер и клиентов для него с использованием личных сертификатов пользователей. Остался не раскрытым вопрос, что делать в случае если требуется отказать какому-либо клиенту в доступе по его сертификату. Причины могут разными — закрытый ключ, связанный с сертификатом скомпрометирован или украден, пользователь забыл пароль на ключ, либо просто хотите прекратить доступ данного человека в вашу сеть. Решением этой задачи является создание списка отзыва сертификатов (Certificate Revocation List — CRL), в котором перечисляются отозванные вами клиентские сертификаты и руководствуясь которым сервер будет отклонять запросы.

В качестве примера, отзовём сертификат пользователя client2. Пример будет для Linux/BSD/Unix.

В результате видим примерно следующее:

Обратите внимание на «Ошибку 23» в последней строке, указывающую на неудавшуюся попытку проверки отозванного сертификата. Скрипт revoke-full как раз и создает CRL (certificate revocation list) — crl.pem. Этот файл (не является секретным) должен быть скопирован в каталог, видимый OpenVPN сервером, а путь к нему прописан в конфиге server.conf.

Теперь при подключении, все клиентские сертификаты будут проверяться на наличие в CRL, и если таковое будет найдено, в соединении будет отказано. При использовании crl-verify в OpenVPN, CRL-файл перечитывается по умолчанию каждый час. Таким образом, если в момент добавления сертификата в исключения, клиент уже установил связь, то он будет продолжать работу. Чтобы изменения применились наверняка перезапустите демон OpenVPN сервера.

При отзыве сертификата бывает ещё ошибка такого вида:

Решается комментированием следующих строчек в openssl.cnf:

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

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

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

Познавательно, а то как-то не очень вопрос этот раскрыт на других сайтах. Везде описано только как поднять сервер.

лень было документацию читать, а на всех топиках только как развернуть.

кстати кому надо есть пара полезный команд для создания комплекта для мобильных устройств

VPN-сервер для офисной сети

Вступление

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

Основы криптографии

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

Итак. Алгоритмы шифрования бывают симметричные и ассиметричные. Симметричный алгоритм представляет из себя один единственный ключ(и/или пароль) с помощью которого некоторый набор данных может быть зашифрован и с помощью этого же ключа он может быть расшифрован. Соответственно этот ключ является серкретным и для безопасного обмена данными должен быть распространен между участниками обмена по безопасным каналам вручную заранее до сеанса обмена. Учитывая ограничения алгоритма, в основном он используется в таких программах, как шифрование диска(truecrypt, diskcryptor) и подобных. Основные представители этого алгоритма: DES, AES, IDEA, RC4. Типичные размеры ключей 64, 128, 192 или 256 бит.

Ассиметричный алгоритм использует пару ключей — открытый и закрытый. Открытый ключ секретом не является и может распространяться свободно, тогда как закрытый ключ должен быть защищен от посторонних. Основная идея такой системы, что с помощью открытого ключа можно зашифровать данные и расшифровать их получится только закрытым ключем. Таким образом, сторона А может передать стороне Б свой открытый ключ и сторона Б сможет зашифровать с помощью него данные и отправить стороне А, которая в свою очередь сможет эти данные расшифровать своим закрытым ключем. У данного алгоритма есть одна интересная особенность, которая используется в цифровых подписях(о них ниже): данные зашифрованные закрытым ключем, могут быть расшифрованы открытым ключем, запомним эту особенность. Основные представители этого алгоритма: RSA, ECC. Типичные размеры ключей RSA 512, 1024, 2048.

Есть еще такая штука как Хеш(контрольная сумма, отпечаток, digest) — это такой алгоритм, который с помощью математики может сгенерить строку фиксированной длины для любого объема данных. Т.е. берутся нужные данные(любого объема) и используя один из алгоритмов вычисляется хеш этих данных, т.е. некоторая строка фиксированной длины, которая не зависит от размера данных. При малейшем изменении исходных данных хеш меняется. Хеши используются для контроля целостности данных, когда шифрование самих данных не нужно. Хеш сам по себе не гарантирует, что по пути данные не были злонамеренно подменены, т.к. злоумышленник может подменить данные и сгенерить новый хеш, но зато он гарантирует что данные не были испорчены по пути из-за технических сбоев, ведь если по пути данные были хоть немного повреждены(либо сам хеш), то на стороне получателя это будет выявлено при проверке. Наиболее известные представители: MD5 (Message Digest 5), SHA-1, SHA-224, SHA-256, SHA-384 и SHA-512. Пример хеша MD5: d29aaa0b9cd402b4bfe2395a805f9ada.

Особенность ассиметричного алгоритма используется для технологии цифровых подписей, т.е. когда данные могут быть зашифрованы закрытым ключем, а расшифрованы его открытым ключем. Цифровые подписи используются не для защиты данных от прочтения посторонними, а для гарантирования того, что данные, во-первых, получены от идентифицированно источника(от того, за кого он себя выдает), во-вторых, в неизмененном виде. Достигается это следующим путем: отправитель с данных снимает отпечаток(хеш) и вместе с данными шифрует закрытым ключем(подписывает). Теперь принимающая сторона, во-первых, расшифровывает данные открытым ключем — данный факт подтверждает, что данные были зашифрованы закрытым ключем, который есть только у отправителя, а значит данные точно получены именно от него, а не от кого другого. Во-вторых, сверяет расшифрованные данные с отпечатком(хешем), если они совпадают, значит данные не были изменены или испорчены по пути. Злоумышленник может перехватить данные и расшифровать их(т.к. открытый ключ свободно доступен), но он не может подменить данные, т.к. для этого ему надо сгенерить новый отпечаток и зашифровать его месте с данным обратно, но закрытого ключа у него нет. Таким образом, цифровая подпись гарантирует, что данные получены в неизменном виде и именно от того, от кого мы ожидали(не рассматривает тот вариант, когда закрытый ключ украден). Наиболее распространенные алгоритмы RSA-MD5, RSA-SHA-1, RSA-SHA-256, RSA-SHA-384, DSA и ECDSA. Есть еще такая разновидность цифровых подписей(как я понял) аутентификационный код сообщения (Message Authentication Code, MAC), тоже бывает разных типов в зависимости от используемого алгоритма хеширования.

Есть еще такая штука, как контейнер X.509, который представляет из себя набор данных: открытый ключ, цифровую подпись удостоверяющего центра(СА), уникальное имя и прочую дополнительную информацию. Этот контейнер называется сертификат. Сертификаты бывают самоподписанные и подписанные удостоверяющим центром(СА). Разница лишь в том, что будет ли на вашем сертификате подпись «авторитетного» центра или нет. Аторитетность центра определяется насколько его корневой сертификат известен в раличных операционных системах. CA — корневой сертификат центра сертификации. Взглянем на это с практической стороны. Допустим у нас есть https сервер, мы устанавливаем с ним сеанс связи и наш компьютер пытается проверить его сертификат. Первым делом он ищет в своей локальной базе доверенных корневых сертификатов корневой сертификат того центра, который подписал сертификат веб-сервера. Если такой находится и сертификат действительно был подписан этим центром и при этом сертификат(веб-сервера) не числится в базе отозванных сертификатов, то считается, что все прошло успешно. Если же не нашлось подходящего корневого сертификата(в случае самоподписанного сертификата, либо сертификат был подписан малоизвестным центром, корневой сертификат которого отсутствует в нашей ОС), то пользователь увидит устрашающее сообщение, что подлинность сертификата сервера не удалось проверить. Но в данном случа можно добаваить сертифика в список доверенных и продолжать работать. Итак, еще раз: известный удостоверяющий центр подписывает наш сертификат своим закрытым ключем, открытый ключ удостоверяющего центра(корневой сетификат) уже есть в нашей ОС, как мы помним, именно с помощью открытого ключа можно проверить, действительно ли данные были подписаны тем, кем надо.

Как уже упоминалось выше, сертификат может фигурировать в базе отозванных сертификатов. Хоть у сертификата есть срок действия, может возникнуть ситуация, когда действие сертификата нужно завершить раньше истечения его срока действия. Существуют различные варианты подобных «черных списков» сертификатов. Самый простой: Certificate Revocation List, CRL — база данных отозванных сертификатов, это обыкновенный файл со списком отозванных сертификатов. Его просто использовать с малым числом сертификатов, но в случае с удостоверяющими центрами, подобная база может достигать внушительных размеров и клиенту каждый раз ее скачивать достаточно накладно. Есть альтернативные варианты, например Online Certificate Status Protocol, OCSP — протокол онлайн проверки валидности сертификатов. Это альтеренатива спискам отозванных сертификатов(CRL). Сервис OCSP обязателен только для EV (Extended Validation) сертификатов, для остальных типов опционален. Вся эта система пользовательских сертификатов, центра сертификации и БД отозванных сертификатов называется PKI — Public Key Infrastructure.

Вообще сам по себе ассиметричный алгоритм для шифрования данных не используется из-за достаточно высокого потребления ресурсов. Он используется только на этапе согласования и установки соединения для идентификации участников, после чего уже сам сеанс связи шифруется симетричным протоколом. Но как известно, у симетричного протокола есть проблема с распространением ключей, т.е. они должны быть предварительно предоставлены все сторонам участникам диалога, а это ломает всю логику установки защищенного соединения между двумя случайными собеседниками. Тут на помощь приходит протокол Diffie-Hellman(DH). С помощью этого протокола две стороны(или более) генерят общий секретный ключ не обмениваясь секретными данными, посредством которого в дальнейшем выполняется шифрование передаваемых данных(одним из алгоритмов симметричного шифрования). Этот протокол избавил от необходимости обмениваться секретными ключами по защищенным каналам связи, наоборот на этапе генерации общего ключа все данные передаются в открытую. Но этот протокол уязвим к атаке «человек по середине», т.е. он надежен только в том случае, если данные на этапе генерации не были подменены третьей стороной. Именно для этих целей и используется асиметричный алгоритм, т.е. с помощью цифровых подписей гарантируется неизменность данных на этапе обмена сторон и генерации общего секретного ключа симетричного шифрования. Ну и соответственно после генерации такого ключа дальше уже обмен данными выполняется в зашифрованном виде. Открытые параметры(DH ключ) как правило генерятся на одной стороне(сервером) и при установке сеанса связи передаются другой.

Ну вот, вроде, и все. Подводя итог: асиметричный алгоритм используется для аунтификации сторон и для контроля идентичности данных на этапе соглосования соединения, а симетричный протокол используется для шифрования потока данных уже после установки соединения. Небольшой абстрактный пример установки сеанса связи(https):

Криптография в OpenVPN

Еще на шаг ближе к практике. Рассмотрим как все вышеописанное применяется в OpenVPN. Как и положено создается структура PKI, на стороне сервера создается корневой сертификат и закрытый ключ(ca.crt и ca.key). Корневой сертификат раздается всем клиентам, а корневой закрытый ключ используется для подписи сертификата сервера и всех клиентских сертификатов. Хранить его на сервере совсем не обязательно(он используется только подписывания), а если вы параноик, то даже не желательно. Также у сервера есть своя пара сертификат/ключ. Сертификат сервера используется клиентами для его идентификации(в OpenVPN используется двусторонняя аунтификация, т.е. клиент тоже аунтифицирует сервер). Еще у сервера есть DH ключ, как описано выше, с помощью него согласовывается ключ симетричного шифрования. Ну и соответственно у каждого клиента своя пара сертификат/ключ(по сертификату сервер аунтифицирует клиента), в сертификате клиента важное поле CN — его значение принимается за имя клиента. Таким образом, сервер и клиент аунтифицируют друг друга на этапе установки соединения, после чего генерят ключ симетричного шифрования с помощью DH и переходят на шифрование потока данных.

В качестве дополнительной защиты в OpenVPN есть возможность использовать HMAC подписи(опция tls-auth). Для этого генерируется отдельный ключ, который распространяется среди всех клиентов через защищенный канал, затем этот ключ, как я понял, используется на этапе согласования подключения, каждый пакет данных на этом этапе подписывается HMAC и если пакет полученный от клиента имеет не корректную HMAC подпись, то соединение сбрасывается(пакет игнорируется). Данная процедура позволяет избежать некоторых проблем, например DOS-атаки, сканирование портов и т.д.

В итоге, в общем случае клиент имеет три файла: ca.crt(не секрет), client.crt(не секрет) и client.key(секрет). Сервер имеет четыре файла: ca.crt(не секрет), server.crt(не секрет), dh2048.pem(не секрет) и server.key(секрет). В случае использования tls-auth ключей, все участники имеют еще ta.key(секрет).

Настройка сервера

Настройка будет проводиться на примере Debian 7, но в других дистрибудтивах принципиально ничем не отличается. Переходим в каталог /usr/share/doc/openvpn/examples/easy-rsa/2.0 и редактируем файл vars, тут задаются некоторые переменные среды, которые используются скриптами при генерации сертификатов, например указываем каталог, в который генерить сертификаты, увеличиваем длину ключа до 2048 бит и по желанию редактируем срок действия сертификатов(корневого и клиентских):

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

Перед тем как выполнять какие-либо действия с сертификатами нужно загрузить переменные среды:

Запустим скрипт очистки сертификатов, он нам создаст и инициализирует необходимые файлы:

В результате должы появиться следующие файлы:

Далее генерим корневой сертификат, в качестве Common Name указываем что-то вроде «OpenVPN Server CA»

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

Далее генерим сертификат сервера, качестве Common Name указываем что-то вроде «server»:

Дальше ключ DH(Diffie Hellman):

Также в качестве дополнительной защиты(HMAC-firewall) сгенерим еще один ключик:

Осталось сгенерить клиентские сертификаты. Генерим такое кол-во, которое нужно и в качестве CN указываем интуитивно понятное имя, чтобы по нему можно было идентифицировать клиента:

Конфигурационный файл сервера /etc/openvpn/server.conf:

Теперь создаем каталог для логов, запускаем сервер и проверяем, что он ждет подключения на порту 1194:

Чтобы лог-файл со временем не занял все место создадим такой файл /etc/logrotate.d/openvpn:

И в заключении зададим клиенту client1 персональные настройки, для этого создаем файл /etc/openvpn/ccd/client1:

Тут статически задан адрес клиента 192.168.0.241, также переданы ему адрес DNS -сервера и маршрут(в данном случае маршрут по-умолчанию).