Назад | Перейти на главную страницу

Распространение сертификатов SSL на все браузеры в среде Active Directory

Я создал один самоподписанный сертификат SSL (срок действия которого истекает через 5000 лет). Цель сертификата - просто зашифровать https-трафик доверенного обозначать приложение, к которому обращаются различные веб-браузеры на нескольких сайтах корпоративной интрасети.

В комментарии моего предыдущий вопрос, кто-то посоветовал мне распространить мой самозаверяющий открытый ключ SSL на все компьютеры в среде Active Directory с помощью групповой политики на контроллере домена.

Моя цель - запретить пользователям вручную принимать этот самозаверяющий сертификат.

Безопасность этого приложения не является главным приоритетом. Главный приоритет - автоматическое принятие самоподписанного сертификата. Таким образом, даже если новый пользователь использует Chrome или Firefox для доступа к этому приложению в первый раз, ему не нужно будет вручную принимать сертификат, чтобы увидеть страницу в приложении.

Если вам интересно, почему я не использую просто http (вместо https), то это только потому, что в веб-стандартах есть функции, которые недоступны, если ваш протокол не https. В Уведомление API это один из примеров.

Есть ли полное руководство для моего варианта использования?

Я щелкнул здесь правой кнопкой мыши:

Это привело меня к редактору групповой политики, и мне действительно удалось импортировать сюда свой самозаверяющий открытый ключ:

Однако это никак не повлияло. Например, я вошел в систему на нескольких рабочих станциях в локальной сети, и из Firefox и Chrome мне все равно было предложено вручную разрешить сертификат.

Где я могу найти подробные инструкции для моего конкретного варианта использования и целей. Как я могу сделать это так, чтобы и Chrome, и Firefox автоматически получали предварительную авторизацию сертификата, который я пытаюсь распространить?

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

Написание подробного руководства по этому вопросу может не подойти для сайта вопросов и ответов, но вот несколько советов. Кроме того, это с точки зрения управление установкой для одного клиента в их собственной интрасети. Например, При установке SaaS лучше использовать глобальные FQDN и PKI.

Как поставщик программного обеспечения вы НЕ ДОЛЖНА:

  • реализовать собственный PKI и распространить его среди ваших клиентов, поскольку он позволяет вам выдавать сертификаты для произвольных имен хостов, что дает вам режим бога по всей их инфраструктуре.
  • используйте одни и те же самозаверяющие сертификаты для нескольких клиентов с жестко запрограммированными закрытыми ключами, поскольку их можно легко извлечь и использовать против других клиентов.
  • объединить эти ошибки, так как это даст каждому клиенту режим бога по сравнению со всеми другими клиентами.

Создайте свою собственную PKI вместо того, чтобы доверять отдельным сертификатам

Это в основном соображение безопасности, но его также проще поддерживать, поскольку вы упомянули о нескольких установках на нескольких сайтах интрасети.

  • С точки зрения безопасности вы не хотите, чтобы каждое приложение могло подписывать сертификаты для произвольных имен хостов. Следовательно, не все отдельные самозаверяющие сертификаты должны быть доверенными центрами сертификации.

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

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

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

Если вам нужен только крошечный центр сертификации только для этой цели, вы можете использовать OpenSSL:

  1. Сгенерируйте корневой ключ (rootCA.key) и корневой сертификат (rootCA.crt). 

    openssl genrsa -aes256 -out rootCA.key 4096
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 7300 -out rootCA.crt

    Храните ключ в надежном месте, рекомендуется в автономном режимеи распространите сертификат с помощью групповой политики.

  2. Создайте сертификат для своего приложения, начиная с ключа и запрос на подпись сертификата (.csr).

    openssl genrsa -out app.example.com.key 2048

openssl req -new -sha256 \
    -key app.example.com.key \
    -subj "/C=US/ST=CA/O=My Application/CN=app.example.com" \
    -out app.example.com.csr

  3. Создайте сертификат приложения, подписанный вашим ЦС:

    openssl x509 -req -in app.example.com.csr \
    -CA rootCA.crt -CAkey rootCA.key -CAcreateserial \
    -days 730 -sha256 \
    -out app.example.com.crt

  4. Использовать app.example.com.key и app.example.com.crt в вашем приложении.

Для более тяжелых решений есть Службы сертификатов Active Directory (AD CS), но это действительно требует некоторого планирования, и ваш набор навыков может еще не подходить для этого.

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

Кстати, я бы не стал редактировать Политика домена по умолчанию для этого, но вместо этого создайте новый объект групповой политики (GPO). Намного проще ограничить объем изменений, например позволяя применить их, во-первых, к группе тестовых компьютеров. Это также упрощает возврат изменений, если что-то пойдет не так.

Firefox имеет собственное хранилище сертификатов - можно использовать сертификаты из Windows

Программа сертификации ЦС Mozilla регулирует включение корневых сертификатов в Службы сетевой безопасности (NSS), набор библиотек с открытым исходным кодом, предназначенный для поддержки кроссплатформенной разработки клиентских и серверных приложений с поддержкой безопасности. Хранилище корневых сертификатов NSS используется в продуктах Mozilla, таких как браузер Firefox, а также другими компаниями в различных продуктах.

Это означает, что сертификаты, добавленные в хранилище сертификатов Windows, по умолчанию не применяются к Firefox. Для упрощения обслуживания было бы неплохо заставить Firefox использовать сертификаты, установленные в Windows. Использование собственного хранилища сертификатов - хорошая идея для защита конфиденциальности людей, использующих Firefox, но не подходящих для сред Windows AD. К счастью, есть способ отключить его.

Предполагая, что каталог установки Firefox C:\Program Files\Mozilla Firefox\, вам необходимо добавить два файла конфигурации в кодировке ANSI:

  1. C:\Program Files\Mozilla Firefox\defaults\pref\local-settings.js имея

    pref("general.config.obscure_value", 0); 
pref("general.config.filename", "ownsettings.cfg");

    Это просто относится к следующему файлу, имеющему фактические параметры конфигурации.

  2. C:\Program Files\Mozilla Firefox\ownsettings.cfg имея

    //
lockPref("security.enterprise_roots.enabled", true);

    Важно, чтобы фактические настройки начинались со второй строки после //!

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

Computer Configuration \ Preferences \ Windows Settings \ Files

Не вводите корневые центры сертификации в другие организации

Использование самозаверяющих сертификатов и их распространение через Active Directory возможно, но довольно сложно. Эса Йокинен более подробно рассказывает в своем ответе.

Более важны последствия для безопасности; корневые сертификаты похожи на главный ключ, всем сертификатам, подписанным корневым сертификатом в AD, будут доверять все компьютеры компании. Если вы контролируете корневой сертификат в приложении, вы не можете просто создать сертификат для yourapp.intranet которому будут доверять, вы можете это сделать для любого домена. Также для bigbank.com, или для google.com.

По сути, если кто-то установит ваш корневой сертификат, вы сможете атаковать все их HTTPS-соединения. Это означает, что вам необходимо иметь надлежащие процедуры для работы с этими ключами, для работы с отзывами и для устранения нарушений безопасности. Это также означает, что этим компаниям нужно очень доверять вам. И я не думаю, что им следует, извините.

Честно говоря, если бы поставщик попытался внедрить свой собственный корневой ЦС в мою организацию, не понимая досконально связанных с этим проблем и не имея надлежащих планов на все, я бы наложил вето на него. Я бы, наверное, даже наложил вето на эти планы.

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

Есть ли альтернатива?

Рассмотрим этот альтернативный подход; Получите подходящее доменное имя для своего приложения и получите обычный сертификат SSL от любого центра сертификации. Если вас беспокоит стоимость, есть несколько сторон, предлагающих сертификаты бесплатно. Мне нравится Let's Encrypt.

Для доменного имени наиболее очевидными вариантами являются company.yourapp.com и yourapp.company.com. Первым вам легче управлять, поскольку получение имени хоста и сертификата стандартизовано для всех развертываний. Последнее требует, чтобы вы работали с ИТ-отделом клиента, но предлагает лучшую интеграцию для них.

Между прочим, ни один из этих вариантов не требует, чтобы ваше приложение было общедоступным (хотя это, безусловно, вариант). Домен может просто указывать на внутренний IP-адрес компании, в которой развернуто приложение; Вам нужно будет использовать подтверждение по электронной почте или Проверка DNS получить сертификаты.

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

Отвечая на некоторые комментарии

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

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

В конце концов, проверка личности является неотъемлемой частью получения зашифрованного сообщения; это не обязательно.

Дело в том, что самозаверяющий сертификат может обеспечивать тот же уровень шифрования (во время передачи данных), что и используемый Bank of America.

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

Вот почему мы используем центры сертификации; они обеспечивают способ распространения сертификатов масштабируемым и достаточно безопасным способом.

На мой взгляд, приложения, обслуживаемые с частных IP-адресов, не должны работать по тем же правилам, что и международные банки.

Дело в том, что у компьютеров нет здравого смысла. Они не понимают, что хорошая безопасность необходима для посещения веб-сайта банка, но безопасность подходит для посещения вашего приложения. Oни не могу понять это. И они не должны пытаться. Что, если ваше приложение начнет работать с медицинскими записями? Внезапно «здравый смысл» принятия безопасности для вашего приложения становится неприемлемым. Компьютер не может знать этого различия.

Если компьютерам приходится соглашаться с небрежной системой безопасности на вашем сайте, они должны соглашаться и с другими сайтами. И, к счастью, мы дошли до того, что это недопустимо. Примите это и с гордостью предоставьте своему приложению то же самое, что и банки шифрования!

Это ложит ужасную ненужную ношу на разработчика.

Нет, это не так.

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

Честно говоря, просто поставьте несколько сертификатов Let's Encrypt на свои сайты. Это дает вам желаемую безопасность (плюс немного больше) и гораздо меньше усилий, чем жаловаться на все это. К тому же это меньше усилий и безопаснее, чем пытаться быть центром сертификации для ваших клиентов.