Самоподписанный SSL на IIS: создание и развёртывание на клиентских машинах

Быстрые ссылки

• Создание самоподписанного сертификата в IIS
• Экспорт сертификата
• Развёртывание на клиентских машинах
• Internet Explorer и Google Chrome — установка сертификата локально
• Firefox — добавление исключений
• Критерии приёмки
• Сводка и рекомендации
• Полезные альтернативы и примечания безопасности
• Ссылки

Введение

Разработчикам и администраторам часто нужно обеспечить HTTPS для тестовых или локальных окружений. Покупка и продление коммерческого сертификата неудобно для временных сред. В таких случаях удобен самоподписанный сертификат, который можно сгенерировать на Windows Server с IIS и развернуть на клиентских машинах.

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

Определение: самоподписанный сертификат — сертификат, подписанный тем же узлом (сервером), который его выдал, а не сторонним центром сертификации.

1. Создание самоподписанного сертификата в IIS

Мы используем утилиту SelfSSL от Microsoft. Она входит в IIS 6.0 Resource Toolkit, но корректно работает с IIS 7 и выше. Достаточно распаковать пакет и скопировать selfssl.exe в удобное место — каталог Windows, сетевую папку или на USB.

Запустите командную строку от имени администратора и выполните команду (замените значения в <>):

selfssl /N:CN= /V:

Пример: создание wildcard-сертификата для mydomain.com и сроком действия 9999 дней. При подтверждении утилита автоматически привяжет сертификат к порту 443 в Default Web Site.

Важно: после создания сертификат сохраняется в хранилище «Личные» (Personal) текущего компьютера. Чтобы клиенты доверяли сертификату, корневой сертификат (тот же сертификат для самоподписанного случая) нужно поместить в «Доверенные корневые центры сертификации» (Trusted Root Certification Authorities).

Шаги для добавления сертификата в доверенные корневые центры:

1. Нажмите Start > Run (Win + R) и введите mmc. Подтвердите UAC при необходимости.
2. В консоли MMC откройте File > Add/Remove Snap-in.
3. Добавьте «Certificates» (Сертификаты) и выберите «Computer account» (Учётная запись компьютера) → Local computer (Этот компьютер).
4. Перейдите в Personal > Certificates. Найдите сертификат, созданный SelfSSL, правый клик → Copy.
5. Перейдите в Trusted Root Certification Authorities > Certificates. Правый клик по папке Certificates → Paste.

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

Important: Не храните и не копируйте приватный ключ в небезопасные места. Приватный ключ обеспечивает владение сертификатом.

2. Экспорт сертификата с приватным ключом (PFX)

Чтобы развернуть доверие на клиентских машинах, необходим файл сертификата с приватным ключом (PFX), который вы экспортируете с сервера и перенесёте на клиентов.

Шаги экспорта:

1. В MMC откройте Trusted Root Certification Authorities > Certificates (или Personal > Certificates, в зависимости от того, где находится сертификат).
2. Найдите нужный сертификат, правый клик → All Tasks > Export.
3. При запросе «Экспортировать приватный ключ?» выберите Yes.
4. Выберите формат PFX (обычно по умолчанию) и включите опцию экспорта всех свойств, если требуется.
5. Установите пароль для PFX — это защитит приватный ключ. Без пароля импорт невозможен.
6. Укажите путь для сохранения .pfx файла и завершите мастер.

Полученный PFX-файл переносите на клиентские машины по защищённому каналу (SCP, SFTP, защищённая файлообменная папка) и удаляйте исходные копии из временных мест хранения после установки.

Security note: Храните PFX под паролем и ограничьте доступ. Передача PFX по открытому каналу без шифрования небезопасна.

3. Развёртывание на клиентских машинах (Windows: IE/Chrome)

IE и Chrome используют хранилище сертификатов Windows. Процесс установки PFX следующий:

1. Скопируйте .pfx на клиентскую машину или доступную сетевую точку.
2. Откройте mmc → File > Add/Remove Snap-in → Certificates → Computer account → Local computer.
3. Перейдите в Trusted Root Certification Authorities > Certificates.
4. Правый клик по папке Certificates → All Tasks > Import.
5. Выберите .pfx файл, введите пароль, подтвердите импорт в хранилище «Trusted Root Certification Authorities».
6. После успешного импорта откройте браузер и перейдите на HTTPS-адрес. Предупреждения должны исчезнуть.

После завершения клиентский браузер не будет отображать предупреждения для этого сертификата (если имя в сертификате совпадает с URL).

Important: Никогда не устанавливайте сертификат от неизвестного источника. Устанавливайте только те сертификаты, которые вы сами создали или которые были выданы доверенным внутренним CA.

4. Firefox — добавление исключений

Firefox по умолчанию использует собственное хранилище сертификатов. Установка PFX в Windows не влияет на Firefox. У вас есть два подхода:

• Установить корневой сертификат в хранилище Firefox вручную (рекомендуется, если вы управляете несколькими клиентами). Это делается через Options > Privacy & Security > View Certificates > Authorities > Import.
• Либо при первом доступе к сайту добавить исключение вручную.

Когда вы заходите на сайт с самоподписанным сертификатом, Firefox покажет предупреждение с возможностью «Add Exception». Нажмите на «Add Exception», затем «Confirm Security Exception».

Примечание: если сайт перенаправляет на поддомены, может потребоваться добавить исключения для каждого URL отдельно.

5. Критерии приёмки

Критерии, по которым принимается успешная установка и развёртывание сертификата:

• На сервере: сертификат создан и корректно привязан к сайту в IIS на порту 443; при обращении с локального сервера HTTPS-запрос проходит без предупреждений.
• На клиенте (Windows/IE/Chrome): сертификат импортирован в Trusted Root Certification Authorities и при обращении к HTTPS-адресу предупреждений нет.
• На клиенте (Firefox): либо корневой сертификат импортирован в Authorities Firefox, либо добавлено явное исключение для URL; в обоих случаях доступ к сайту осуществляется без блокирующего предупреждения.
• Приватный ключ защищён паролем в PFX и хранится/передаётся по защищённому каналу.

Критерии прохождения тестов подробно в разделе ниже.

6. Тест-кейсы и приёмочные проверки

Тест-кейсы для QA и администраторов:

1. Серверная проверка: открыть сайт через HTTPS на самом сервере. Ожидаемый результат: соединение установлено без предупреждений.
2. Клиентская проверка: импортировать PFX в Trusted Root на тестовой машине → открыть сайт в IE и Chrome. Ожидаемый результат: нет предупреждений; валидный зелёный/нейтральный индикатор безопасности.
3. Проверка Firefox: добавить сертификат в Authorities Firefox или добавить исключение вручную. Ожидаемый: сайт доступен без блокирующих предупреждений.
4. Тест с неправильным CN: если сертификат с CN=example.com, а вы открываете my.example.com, браузер покажет предупреждение. Ожидаемый: ошибка имени хоста.
5. Тест отзыва/удаления: удалить сертификат из Trusted Root на клиенте и открыть сайт; ожидаемый результат: браузер выдаёт предупреждение безопасности.

Критерии приёмки: все тест-кейсы выполнены без блокирующих предупреждений и приватный ключ надежно защищён.

7. Откат и план реагирования на инцидент

Если нужно быстро откатить изменения (например, сертификат скомпрометирован), выполните следующие действия:

1. На сервере: удалите самоподписанный сертификат из Personal и Trusted Root.
2. На клиентах: удалите корневой сертификат из Trusted Root и из Firefox Authorities.
3. Если PFX распространили на файловые хранилища, удалите копии и пересоздайте новые, с новым приватным ключом.
4. Сообщите пользователям и обновите документацию о причинах отката.

Важно: при компрометации приватного ключа следует немедленно отозвать/удалить сертификат с клиентов и сгенерировать новый ключ и сертификат.

8. Альтернативы и когда не использовать самоподписанные сертификаты

Когда самоподписанный сертификат — хорошее решение:

• Локальная разработка и тестирование.
• Внутренние демонстрации и PoC.
• Временные стенды, не открытые в публичный интернет.

Когда лучше не использовать:

• Публичные веб-сайты с реальными пользователями — используйте доверенный CA (Let’s Encrypt, коммерческие CA).
• Для API/продакшен-сервисов, где требуется доверие сторонних клиентов.

Альтернативы:

• Let’s Encrypt — бесплатный, автоматизированный CA (подходит для публичных доменов). Ограничение: с публичными DNS-записями или с помощью DNS-01 для внутренних доменов.
• Внутренний корпоративный CA (Active Directory Certificate Services) — подходит для больших инфраструктур: централизованное управление, автоматическая выдача сертификатов через GPO.
• Использование тестовой среды PKI: выстраиваете корневой и промежуточные CA и импортируете корень в доверенные хранилища клиентов.

Ментальная модель: самоподписанный сертификат = «локальная подпись»; корпоративный CA = «внутренний авторитет»; публичный CA = «всемирно доверяемая подпись».

9. Риски и рекомендации по безопасности

Риски:

• Приватный ключ в PFX-файле может быть скомпрометирован при неправильном хранении/передаче.
• На клиентских машинах ссылка на корневой сертификат даёт доверие всем сертификатам, подписанным этим корнем. Если корень скомпрометирован, злоумышленник может выпустить сертификаты от вашего имени.

Меры смягчения:

• Используйте сильный пароль для PFX и защищённый канал передачи (SFTP, scp, защищённые сетевые шаре).
• Ограничьте доступ к файлам и учетным записям, которые могут экспортировать приватные ключи.
• Для больших инфраструктур используйте внутренний CA с политикой выдачи и контролем доступа.

Privacy/GDPR: сам по себе сертификат не содержит персональные данные. Однако при тестовой передаче файлов по сети придерживайтесь правил обработки данных в вашей компании.

10. Совместимость, миграция и советы для RU/локальной среды

Совместимость:

• Команды и инструменты SelfSSL из IIS6RT работают на Windows Server 2008/2012/2016 и выше с установленным IIS.
• Chrome/IE используют хранилище Windows. Firefox использует собственное хранилище.

Миграция на корпоративный CA:

1. Разработайте политику выдачи сертификатов.
2. Разверните AD CS (если используете Active Directory) и настройте шаблоны сертификатов.
3. Распространите корневой сертификат через GPO на все клиентские машины.

Локальные советы:

• Для доменов вида mysite.local или internal.example используйте DNS записи и — при возможности — корпоративный CA.
• В России многие организации используют внутренние CA; учитывайте политики безопасности и требования регуляторов при развёртывании.

11. Практический чек-лист перед развёртыванием

Для администратора:

• Скопировать selfssl.exe на сервер и выполнить команду создания сертификата.
• Проверить CN/SubjectAltName на предмет соответствия URL.
• Добавить сертификат в Trusted Root на сервере.
• Экспортировать PFX с паролем и сохранить во временной защищённой папке.
• Передать PFX клиентам по защищённому каналу.
• Инструментально проверить доступность сайта на чистой клиентской машине.
• Запланировать ревизию и ротацию сертификатов.

Роли и ответственность:

• DevOps/Системный администратор: создание сертификата, привязка к IIS, экспорт PFX.
• Сетевая/Системная безопасность: политика хранения ключей, контроль доступа.
• QA: проверка сертификата на всех целевых браузерах и платформах.

12. SOP: быстрый рабочий процесс (Playbook)

1. Подготовка: загрузить selfssl.exe, подготовить имя CN и срок действия.
2. Генерация: запустить selfssl от админа; проверить привязку IIS.
3. Добавление в доверенные корни на сервере.
4. Экспорт PFX с паролем.
5. Передача PFX на клиентскую машину через защищённый канал.
6. Импорт PFX в Trusted Root на клиенте и/или импорт в Firefox Authorities.
7. Проверка в браузерах и решение обнаруженных проблем.
8. Документирование: где хранится PFX, пароль, список установленных клиентов.

13. Decision tree для выбора решения (Mermaid)

flowchart TD
  A[Нужно HTTPS для ресурса?] --> B{Домен публичный?}
  B -- Да --> C{Можно использовать Let's Encrypt?}
  C -- Да --> D[Использовать Let's Encrypt]
  C -- Нет --> E[Покупной коммерческий сертификат]
  B -- Нет --> F{Ресурс внутренний/тестовый?}
  F -- Да --> G{Много клиентов/AD есть?}
  G -- Да --> H[Внутренний CA 'AD CS' + GPO]
  G -- Нет --> I[Самоподписанный сертификат + ручной импорт]
  F -- Нет --> E

14. Шаблоны и примеры команд

Команда SelfSSL (пример):

selfssl /N:CN=dev.example.local /V:365

Экспорт PFX через MMC: пошагово в разделе Экспорт.

15. Краткое объявление для команды (100–200 слов)

Короткое сообщение для рассылки: «Мы настроили самоподписанный SSL-сертификат для тестового стенда https://dev.example.local с помощью SelfSSL. Сертификат экспортирован в PFX и защищён паролем. Клиентам необходимо импортировать PFX в Trusted Root Certification Authorities (или добавить исключение в Firefox). Нельзя устанавливать сертификат от неизвестных источников. Копии PFX хранятся временно в защищённой папке и будут удалены после развёртывания. При возникновении вопросов обращайтесь к команде инфраструктуры.»

16. Заключение

Самоподписанный сертификат — удобный и быстрый инструмент для разработки и тестирования. Он прост в создании и развёртывании, но требует аккуратного обращения с приватным ключом и понимания ограничений доверия браузеров. Для публичных сайтов и критичных сервисов используйте доверенный CA или внутренний корпоративный PKI.

Сводка:

• SelfSSL позволяет оперативно создать сертификат и привязать его в IIS.
• Экспортируйте сертификат в PFX с паролем и импортируйте на клиенты в Trusted Root.
• Firefox требует отдельного управления сертификатами или исключений.
• Рассмотрите внутренний CA или Let’s Encrypt для более масштабируемых решений.

Полезные ссылки

• Download IIS 6.0 Resource Toolkit (includes SelfSSL utility) from Microsoft

Важно: устанавливайте на клиентские машины только те сертификаты, которые вы контролируете. Несанкционированная установка сертификатов нарушает безопасность и может привести к компрометации доверия.