Про PKI «на пальцах» за 1. Блог компании Pixonic / Хабрахабр. Предложил коллегам провести внутреннюю мини- лекцию по сабжу — идея зашла.
Сел писать план лекции и. Подумал, что будет полезно добавить сюда что- то для быстрого понимания, что такое PKI, зачем она нужна и как работает, так как пока готовился, чтобы освежить память, искал информацию в том числе на полюбившемся «Хабрахабре», но статей в таком формате не нашел. Пишу на примере наших повседневных задач, которые знакомы многим: беспарольный доступ к серверам Open. VPN и защита доступа к ресурсам с помощью HTTPS. Без теории не обойтись. PKI (Public Key Infrastructure, инфраструктура открытых ключей) — это про безопасность. Подразумевается, что у каждой сущности в инфраструктуре есть свой ключ, которым она однозначно идентифицируется.
Это ваш закрытый ключ RSA/DSA, а ~/.ssh/id. Можно отметить, что структура ASN.1 довольно простая: последовательность 9 целых чисел. OpenSSL поддерживает формат закрытых ключей PKCS#8. KEY), а открытых заголовков Proc-Type и DEK-Info больше нет. X.509 — стандарт ITU-T для инфраструктуры открытого ключа (англ. Public key infrastructure, PKI) и инфраструктуры управления привилегиями (англ. X.509 определяет стандартные форматы данных и процедуры распределения открытых ключей с .
То есть, если ключ украден, пострадавшей сущностью может представиться укравший. PKI нужна для того, чтобы оперативно минимизировать последствия такой кражи. Ключ представлен двумя частями: публичной и приватной. Аналог — это RSA ключи для SSH, но инфраструктурой их назвать сложно, так как отсутствует централизованный механизм управления ими. Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.
В PKI существует один (на самом деле, должно быть минимум два) или несколько Certification Authority — центров сертификации (удостоверяющих центров), отдающих публичные части своих ключей клиентам, которым выдают подписанные ими сертификаты. Таким образом, участники инфраструктуры «понимают», кто ими управляет, и действителен ли сертификат, выданный им или их «товарищам», в настоящий момент времени (одним из важнейших атрибутов сертификатов является срок их действия). Либо же сервер, у которого есть публичная часть ключа CA инфраструктуры, в которой он и его клиенты работают, понимает, что к нему пришел клиент с действительным сертификатом, и разрешает ему что- то, или запрещает в противном случае. Open. VPN: как это бывает. На самом деле во многих компаниях на этот случай уже есть «PKI» и у него есть имя, потому что это кто- то из сотрудников. Назовем такого человека, к примеру, Полуэкт (с) и расскажем, как обычно это работает, а потом я расскажу, как это должно быть в идеале. При появлении в компании нового сотрудника Полуэкт создает и присылает ему архив, в котором, помимо конфигурации собственно Open.
VPN клиента, находятся файлы (на примере сотрудника Иванова А. Фанты Карамельный Рай здесь. А.): a. ivanov- office.
SSH — файл id. Очень удобно, в отличие от, например, мозголомных Java Keystore или PFX от Microsoft: можно сливать сертификаты в один файл простым cat'ом для образования цепочек CA (так называемых bundle, что полезно для nginx, например, в конфигурации которого нет отдельной директивы для указания сертификата CA), можно совмещать сертификаты CA и свой, и даже свой приватный ключ, если зачем- то понадобится. И еще полезность: можно прописать сертификат CA прямо в конфигурации Open. VPN клиента, между тегами .
Инфраструктура Открытых Ключей (Public Key Infrastructure, PKI) является технологией. Реализация инфраструктуры открытых ключей на OpenSSL. Инфраструктура открытых ключей (PKI) Антон Карпов для. Домашнее задание: OpenSSL http://www.madboa.com/geek/openssl/ .
Наверное, должно быть можно и сертификат прописать подобным образом. Впрочем, я уже отвлекаюсь на частности. В компании Acme все эти файлы генерирует Полуэкт.
В чем «фишка» PKI? Дело в том, что в этой цепочке фишка просто отсутствует.
А называется она — CRL (Cerificate Revocation List). Это список отозванных сертификатов, который публикует CA, и в который Полуэкт может внести мой сертификат, выпущенный и подписанный ранее, в случае, если выяснилось, что, к примеру, я упоролся веществами и смог продиктовать свой приватный ключ конкурентам (ну или у меня украли ноут). Нужна ли вам эта фишка — вопрос для обсуждения. Соответственно, то, как ее внедрить, пока что выходит за рамки этой статьи. И про срок действия клиентского сертификата: если предположить, что я устроился в Pixonic по временному контракту на 3 месяца, и мы его не продлили, то в описанной ситуации мой доступ к VPN автоматически отключится через 9. Чего не случится с SSH- доступом, если коллеги забудут отключить аккаунт во Free.
IPA или удалить строчку из authorized. C — сесуриту. Теперь по Борщеву HTTPS. Предположим, вы хотите «включить SSL» для вашего сайта, чтобы у посетителей появился красивый замочек в браузере. Тут, собственно, все то же самое, но с некоторыми нюансами: Очевидно, что на своей стороне вы можете только сгенерировать приватный ключ и запрос на подпись сертификата. При генерировании запроса в качестве Common Name обязательно нужно указывать Server. Name вашего виртуального хоста и все алиасы, которые вы пропишете для него в конфигурации веб- сервера.
Например, domain. CA обычно сами добавляют при выпуске сертификатов. Чаще всего можно указать просто *. CA, а также четко понимать последствия такого решения. Как правило, общедоступные CA не дают в качестве алиаса использовать IP- адрес. При генерировании запроса не стоит указывать challenge password, иначе вам придется вводить его вручную при каждом рестарте веб- сервера. Обычно общедоступные CA — это маститые конторы вроде Comodo, Symantec и Go.
Daddy. Выпуск сертификата стоит денег, а хорошего сертификата — много денег. Впрочем, помимо них относительно недавно существует Let's Encrypt — бесплатный проект, которому склонны доверять многие, но я бы очень хорошо подумал, какие ресурсы и при каких обстоятельствах защищать их сертификатами. Эти ребята договорились с другими ребятами таким образом, что последние предустанавливают сертификаты (публичные части ключей, т. То есть о PKI как таковой речи быть не может. Просто все договорились верить определенным компаниям. Это не плохо, так как HTTPS в конечном итоге нужен для шифрования трафика, а шифровать его можно и самоподписанной парой ключей. Скорее, тут вопрос престижа, чтобы не светить на весь интернет предупреждением о просроченном/недействительном сертификате.
Некоторые особо одаренные CA предлагают для удобства сгенерировать приватный ключ и CSR за вас. Этого делать не надо. Надеюсь, понятно, почему. О сроке действия сертификатов.
Всегда нужно заранее продумать систему их своевременного обновления. Особенно это актуально для сертификатов от Let's Encrypt, срок действия которых составляет всего 3 месяца (на момент написания). И о договоренностях между «этими ребятами».
Как оказалось после давешней фееричной истории с Google и Symantec, теперь нужно уметь подстелить соломки и на такой «веселый» случай. Надеюсь, обещанное в начале статьи понимание появилось. P. S. Конечно, у маститого профи- безопасника, который на этом собаку съел, могут волосы зашевелится в самых нескромных местах от того, как в статье описана такая сложная штука, как PKI. Я же написал этот небольшой гайд для тех, кто вроде как сталкивается с этим по работе, но не очень понимает, что и зачем он делает. А хардкорного «матана» и без меня хватает в этих ваших ынтырнетах. Если же, несмотря на это, вам есть, что сказать — добро пожаловать в комментарии.