Могу ли я использовать свой собственный центр сертификации для HTTPS через локальную сеть?

У меня есть сервер и несколько клиентов, все они работают в разных док-контейнерах. Пользователи могут использовать клиент, введя localhost: 3000 в своем браузере (где запущен клиентский докер). Все контейнеры работают в одной локальной сети. Я хочу использовать HTTPS. Могу ли я подписать пару открытых закрытых ключей, используя свой собственный ЦС, а затем загрузить открытый ключ ЦС в браузер? Я хочу использовать обычный поток для общедоступных доменов, но внутри своего ЦС. Или мне искать другое решение?


58
1

Ответ:

Решено

Мета: поскольку вы раскрыли nodejs, это делает его по крайней мере граничным для актуальности.

В общем, способ работы PKIX (используемый в SSL/TLS, включая HTTPS) заключается в том, что сервер должен иметь закрытый ключ и соответствующий сертификат; это то же самое, используете ли вы общедоступный ЦС или свой собственный (по вашему желанию). Сервер также должен иметь любые промежуточные или «цепные» сертификаты, необходимые для проверки его сертификата; общедоступному ЦС всегда потребуется такой цепной сертификат (сертификаты), поскольку правила CABforum (обобщающие общепринятые рекомендации) запрещают выдачу сертификатов «подписчика» (EE) непосредственно из корня, в то время как ваш собственный ЦС зависит от вас — вы можете использовать промежуточные или нет, хотя, как я уже сказал, считается лучшей практикой использовать их и держать корневой закрытый ключ «в автономном режиме» — в криптографии это означает, что ни в какой системе, которая связывается с кем-либо, например, в этом случае серверы, которые запрашивать сертификаты, тем самым устраняя один путь атаки — на специализированном устройстве, которое «заблокировано» (не подключено или даже не может быть подключено к какой-либо сети) и в запертом хранилище, возможно, с «защитой от несанкционированного доступа», вежливое название для саморазрушение. В качестве известного примера строгости, необходимой для защиты чего-то столь важного, как корневой ключ важного ЦС, сравните Stuxnet.

Клиент(ы) не нуждаются и не должны быть настроены с сертификатом сервер, если вы не хотите выполнять закрепление; ему (им) делать нужен корневой сертификат Калифорния. Большинство клиентов, и особенно браузеров, уже имеют много/большинство/все встроенные общедоступные корневые сертификаты ЦС, поэтому использование сертификата из такого ЦС не требует каких-либо действий на клиенте(ах); OTOH, использующий ваш собственный ЦС, требует добавления сертификата ЦС к клиенту (клиентам). Chrome в Windows использует магазин Microsoft (Windows); вы можете добавить к этому явно (с помощью диалогового окна GUI, программы certutil или powershell), хотя в средах, управляемых доменом (например, на предприятиях), также популярно «проталкивать» сертификат CA (или сертификаты) с помощью GPO. Firefox использует собственное хранилище доверенных сертификатов, которое вы должны явно добавить.

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

PS: обратите внимание, что обычно вам следует, а для Chrome (и нового Edge, который на самом деле Chromium) должен иметь расширение SubjectAlternativeName (SAN) в сертификате сервера, указывающее его доменное имя (и) или, возможно, IP-адрес (а), НЕ (или не только) атрибут CommonName (CN), который вы найдете во многих устаревших и/или некомпетентных инструкциях и учебниках в Интернете. Командная строка OpenSSL упрощает работу с CommonName, но не так просто с SAN; в нескольких стеках есть вопросы многие по этому поводу. Любой публичный ЦС примерно после 2010 года делает SAN автоматически.