Предложил коллегам провести внутреннюю мини-лекцию по сабжу — идея зашла. Сел писать план лекции и… чот психанул — в итоге очнулся, дописывая небольшой гайд. Подумал, что будет полезно добавить сюда что-то для быстрого понимания, что такое PKI, зачем она нужна и как работает, так как пока готовился, чтобы освежить память, искал информацию в том числе на полюбившемся «Хабрахабре», но статей в таком формате не нашел.
Пишу на примере наших повседневных задач, которые знакомы многим: беспарольный доступ к серверам OpenVPN и защита доступа к ресурсам с помощью HTTPS.
Без теории не обойтись
PKI (Public Key Infrastructure, инфраструктура открытых ключей) — это про безопасность. Подразумевается, что у каждой сущности в инфраструктуре есть свой ключ, которым она однозначно идентифицируется. То есть, если ключ украден, пострадавшей сущностью может представиться укравший. PKI нужна для того, чтобы оперативно минимизировать последствия такой кражи. Ключ представлен двумя частями: публичной и приватной.
Аналог — это RSA ключи для SSH, но инфраструктурой их назвать сложно, так как отсутствует централизованный механизм управления ими. Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.
В PKI существует один (на самом деле, должно быть минимум два) или несколько Certification Authority — центров сертификации (удостоверяющих центров), отдающих публичные части своих ключей клиентам, которым выдают подписанные ими сертификаты. Таким образом, участники инфраструктуры «понимают», кто ими управляет, и действителен ли сертификат, выданный им или их «товарищам», в настоящий момент времени (одним из важнейших атрибутов сертификатов является срок их действия). Либо же сервер, у которого есть публичная часть ключа CA инфраструктуры, в которой он и его клиенты работают, понимает, что к нему пришел клиент с действительным сертификатом, и разрешает ему что-то, или запрещает в противном случае.
OpenVPN: как это бывает
На самом деле во многих компаниях на этот случай уже есть «PKI» и у него есть имя, потому что это кто-то из сотрудников. Назовем такого человека, к примеру, Полуэкт (с) и расскажем, как обычно это работает, а потом я расскажу, как это должно быть в идеале.
При появлении в компании нового сотрудника Полуэкт создает и присылает ему архив, в котором, помимо конфигурации собственно OpenVPN клиента, находятся файлы (на примере сотрудника Иванова А.А.):
- a.ivanov-office.key — его приватный ключ, самая мякотка, которую нужно хранить как зеницу ока и никому не показывать (аналог в SSH — файл id_rsa);
- a.ivanov-office.csr — Certificate Signing Request, запрос на подпись сертификата, в котором описано, для кого нужно выписать сертификат, сгенерирован на основе предыдущего файла, чтобы не «палить» приватный ключ (для работы самого OpenVPN нафиг не нужен);
- a.ivanov-office.crt — вожделенный сертификат, который он предъявляет OpenVPN серверу, чтобы тот разрешил ему подключение (по сути это публичная часть ключа);
- ca.crt — сертификат нашего CA, чтобы OpenVPN клиент предъявил его серверу, чтобы тот сопоставил его с приватной частью, которая лежит у него, и убедился, что сертификат подписывал именно он, а не кто-то другой. «Деталька», которая обозначает принадлежность OpenVPN клиента Иванова А.А. к PKI, в которой работает сервер.
Это простые текстовые файлики в специальном формате PEM. Очень удобно, в отличие от, например, мозголомных Java Keystore или PFX от Microsoft: можно сливать сертификаты в один файл простым cat'ом для образования цепочек CA (так называемых bundle, что полезно для nginx, например, в конфигурации которого нет отдельной директивы для указания сертификата CA), можно совмещать сертификаты CA и свой, и даже свой приватный ключ, если зачем-то понадобится. И еще полезность: можно прописать сертификат CA прямо в конфигурации OpenVPN клиента, между тегами <ca> </ca>. Наверное, должно быть можно и сертификат прописать подобным образом. Впрочем, я уже отвлекаюсь на частности.
В компании Acme все эти файлы генерирует Полуэкт…
А теперь как должно быть
На моем примере, упрощенно:
- я у себя локально генерирую свой приватный ключ (можно и, пожалуй, логично, использовать уже готовый из ~/.ssh/id_rsa):
openssl genrsa -out openvpn.key 2048
- готовлю запрос на подпись сертификата — CSR, для чего заполняю небольшую анкету:
openssl req -new -key openvpn.key -out a.vrublevskiy-office.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:RU
State or Province Name (full name) []:.
Locality Name (eg, city) [Default City]:Moscow
Organization Name (eg, company) [Default Company Ltd]:Pixonic
Organizational Unit Name (eg, section) []:Sysadmins Dept
Common Name (eg, your name or your server's hostname) []:Alexander Vrublevskiy
Email Address []:a.vrublevskiy@pixonic.ru
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
(пароль в конце лучше не указывать, а то придется его вводить каждый раз при подключении, а VPN у нас по сертификатам как раз, чтобы этого не было; тем более у нас в Pixonic есть OTP от Google);
- отправляю получившийся файл a.vrublevskiy-office.csr Полуэкту;
- Полуэкт, получив мой запрос и имея обе части ключа CA (здесь — ca.key и ca.crt), выпускает для меня сертификат, подписывая его ключом CA (модные хипстеры пользуются easy-rsa, но мы суровые бородатые админы):
openssl x509 -req -in a.vrublevskiy-office.csr -CA ca.crt -CAkey ca.key -out a.vrublevskiy-office.crt -days 90
- Полуэкт отправляет мне получившийся файл.
Возникает резонный вопрос: к чему такие сложности? В чем «фишка» PKI? Отвечаю. Дело в том, что в этой цепочке фишка просто отсутствует. А называется она — CRL (Cerificate Revocation List). Это список отозванных сертификатов, который публикует CA, и в который Полуэкт может внести мой сертификат, выпущенный и подписанный ранее, в случае, если выяснилось, что, к примеру, я упоролся веществами и смог продиктовать свой приватный ключ конкурентам (ну или у меня украли ноут).
Нужна ли вам эта фишка — вопрос для обсуждения. Соответственно, то, как ее внедрить, пока что выходит за рамки этой статьи.
И про срок действия клиентского сертификата: если предположить, что я устроился в Pixonic по временному контракту на 3 месяца, и мы его не продлили, то в описанной ситуации мой доступ к VPN автоматически отключится через 90 дней с момента выпуска сертификата. Чего не случится с SSH-доступом, если коллеги забудут отключить аккаунт во FreeIPA или удалить строчку из authorized_keys руками. C — сесуриту.
Теперь по Борщеву HTTPS
Предположим, вы хотите «включить SSL» для вашего сайта, чтобы у посетителей появился красивый замочек в браузере. Тут, собственно, все то же самое, но с некоторыми нюансами:
- Очевидно, что на своей стороне вы можете только сгенерировать приватный ключ и запрос на подпись сертификата.
- При генерировании запроса в качестве Common Name обязательно нужно указывать ServerName вашего виртуального хоста и все алиасы, которые вы пропишете для него в конфигурации веб-сервера. Например, domain.tld и www.domain.tld, хотя «www» CA обычно сами добавляют при выпуске сертификатов. Чаще всего можно указать просто *.domain.tld (чтобы запросить так называемый wildcard certificate), но возможно ли это, нужно узнавать у конкретного CA, а также четко понимать последствия такого решения. Как правило, общедоступные CA не дают в качестве алиаса использовать IP-адрес.
- При генерировании запроса не стоит указывать challenge password, иначе вам придется вводить его вручную при каждом рестарте веб-сервера.
- Обычно общедоступные CA — это маститые конторы вроде Comodo,
Symantecи GoDaddy. Выпуск сертификата стоит денег, а хорошего сертификата — много денег. Впрочем, помимо них относительно недавно существует Let's Encrypt — бесплатный проект, которому склонны доверять многие, но я бы очень хорошо подумал, какие ресурсы и при каких обстоятельствах защищать их сертификатами. - Эти ребята договорились с другими ребятами таким образом, что последние предустанавливают сертификаты (публичные части ключей, т.е. ca.crt из прошлого примера) этих CA в свои браузеры. То есть о PKI как таковой речи быть не может. Просто все договорились верить определенным компаниям. Это не плохо, так как HTTPS в конечном итоге нужен для шифрования трафика, а шифровать его можно и самоподписанной парой ключей. Скорее, тут вопрос престижа, чтобы не светить на весь интернет предупреждением о просроченном/недействительном сертификате.
- Некоторые особо одаренные CA предлагают для удобства сгенерировать приватный ключ и CSR за вас. Этого делать не надо. Надеюсь, понятно, почему.
- О сроке действия сертификатов. Всегда нужно заранее продумать систему их своевременного обновления. Особенно это актуально для сертификатов от Let's Encrypt, срок действия которых составляет всего 3 месяца (на момент написания).
- И о договоренностях между «этими ребятами». Как оказалось после давешней фееричной истории с Google и Symantec, теперь нужно уметь подстелить соломки и на такой «веселый» случай.
Такие дела. Надеюсь, обещанное в начале статьи понимание появилось.
P.S. Конечно, у маститого профи-безопасника, который на этом собаку съел, могут волосы зашевелится в самых нескромных местах от того, как в статье описана такая сложная штука, как PKI. Я же написал этот небольшой гайд для тех, кто вроде как сталкивается с этим по работе, но не очень понимает, что и зачем он делает. А хардкорного «матана» и без меня хватает в этих ваших ынтырнетах. Если же, несмотря на это, вам есть, что сказать — добро пожаловать в комментарии.
Автор: bofh666
