Моя компания создает программное обеспечение для презентаций. При использовании докладчики входят в систему через веб-сайт с поддержкой HTTPS для отправки текста, документов, токенов аутентификации и т. Д.
Как включить связь HTTPS, если:
Для тех, кто заинтересован, я использую Httplistener и PowerShell для управления C #.
Некоторые из моих исследований:
Если ваше внутреннее доменное имя совпадает с внешним доменным именем (например, sales.corp.example.com) вы все равно можете получить сертификат от большинства общедоступных центров сертификации, так как они примут право собственности на example.com предполагая, кто владеет admin@example.com/webmaster@example.com/ любой рад утвердить ваш запрос на сертификат. Сам сайт не обязательно должен быть доступен через Интернет. Существуют и другие провайдеры, которые реализуют протокол ACME Let's Encrypt, поэтому, если вы не можете соблюдать их требования, вы все равно сможете использовать тот же протокол с другим провайдером.
Если никакая часть вашего внутреннего домена не разрешается публично (например, вы использовали поддельный TLD, например sales.corp.example.local), то единственный вариант - использовать внутренний центр сертификации.
Если вы хотите использовать внутренний ЦС для подписи сертификатов, вам необходимо установить этот ЦС в качестве надежного поставщика на всех ваших устройствах. И если вы хотите сделать это «правильно», тогда это довольно обширная вещь для настройки (обычно у вас есть корневой ЦС, который живет в автономном режиме, который подписывает подчиненный ЦС, который фактически подписывает ваши сертификаты). Вам потребуются процессы для ротации корневых сертификатов по истечении срока их действия и способ их распространения (если вы полностью интегрированы в домен Windows без устройств Linux, это на самом деле не так уж и сложно).
Когда-то давным-давно можно было пойти в ЦС и попросить их выпустить сертификат для внутреннего домена и пройти длительную и дорогостоящую процедуру проверки, однако новые процедуры, введенные 1 июля 2012 года, запрещали любому ЦС выдавать любой сертификат, содержащий внутреннее общее имя с 2015 года и отозвать существующие сертификаты к 2016 году. Так что, если у вас нет машины времени, этого не произойдет.
Как в сторону:
Клиент устанавливает программное обеспечение, и все готово.
Это очень маловероятно. За прошедшие годы я установил много корпоративного программного обеспечения, и настройку TLS мне всегда приходилось делать вручную. Существует множество причин, по которым вы не можете предположить, что можете настраивать сертификаты автоматически:
На самом деле, если бы ваше устройство было в моей сети с автоматически настроенным, действительным, надежным SSL-сертификатом из коробки, я был бы чрезвычайно подозрительным. Существует множество устройств, которые позволяют настроить Let's Encrypt одним щелчком мыши, но это никогда не используется по умолчанию. Это всегда включено.
Никакие ручные шаги не допускаются. Клиент устанавливает программное обеспечение, и все готово.
Если вы не контролируете устройства конечных пользователей, никакие дополнительные действия не означают, что вы должны использовать центр сертификации, уже имеющийся в их хранилищах корневых сертификатов (ОС или браузер). Внутренняя PKI клиента может подписывать ваши сертификаты, но это предполагает, что он у них есть, и он не будет работать для неуправляемых устройств. Остается известный «публичный» CA.
Веб-сайт может быть предназначен только для внутреннего использования. (https://letsencrypt.org/ не могу дотянуться.)
Проблемы владения не обязательно должны исходить от хоста, который получает сертификат. Вы упомянули Let's Encrypt, их запрос DNS может быть выполнен с любого DNS, видимого в Интернете. Включая подстановочные знаки, чтобы вы могли *.present.example.com.
В моей компании есть несколько веб-сайтов, предназначенных только для интрасети. Из-за недавних / текущих изменений политики браузера мы настроили их с поддержкой HTTPS / TLS.
Поскольку эти сайты предназначены только для внутреннего использования, мы решили создать собственный центр сертификации с использованием службы центра сертификации Microsoft Active Directory (MS AD CA). Кроме того, мы используем URL-адреса [Название компании] .local для веб-сайтов.
Используя службу AD CA, мы создали сертификат RootCA, который распространяется на все подключенные к домену системы через контроллер домена. Затем с помощью службы AD CA мы можем выдавать сертификаты для различных внутренних веб-сайтов и устройств с веб-интерфейсами.
Затем мы используем службу DNS Active Directory для настройки домена [Company Name] .local для назначения правильных IP-адресов правильным URL-адресам. Поскольку внутренний AD DNS является основным DNS для нашей сети.
Единственная проблема, с которой мы столкнулись с этим подходом, заключается в том, что браузер Firefox не использует хранилище сертификатов Windows и ему необходимо вручную импортировать созданный сертификат RootCA. Из моих ограниченных исследований кажется, что можно автоматически импортировать сертификат RootCA в хранилище сертификатов Firefox, но из-за ограниченного количества пользователей Firefox мы решили использовать ручной подход. Кроме того, если я правильно помню, команда разработчиков Firefox ожидает разрешения на доступ к хранилищу сертификатов Windows.
Это казалось наиболее надежным решением для нашей ситуации, ваш пробег может отличаться :)
Для любых внешних сайтов мы используем сертификаты из авторитетных источников.