Шаги для создания самоподписанного certficate (s), что, доверяясь, будет работать на двух других дюйм/с без предупреждения системы безопасности
У нас есть тестовый сервер, что я пытаюсь перейти на HTTPS/SSL, и он имеет и внутренний IP и внешний IP. Мы должны использовать самоподписанные сертификаты для этого конкретного сервера. Было одно время в прошлом, что я сделал некоторого R&D на RTMPS с Flash, и таким образом, у меня все еще был список шагов, лежащих вокруг, чтобы создать самоподписанный сертификат для внутреннего IP и поместить его в доверяемое хранилище на клиентских машинах.
Однако я должен получить эту работу одновременно и для внутреннего и для внешнего дюйм/с, Когда я пытаюсь использовать те же шаги, чтобы произвести и доверять сертификату для внешнего IP, сервер продолжает пытаться дурачиться с внутренним certifcate IP, даже когда клиент, использующий внешний IP. Это, по-видимому, имеет некоторое отношение к нему проходящий HTTP-заголовки и получающий сертификат для сайта по умолчанию. Таким образом, даже если сертификату внешнего IP доверяют, клиентская машина продолжает генерировать предупреждение системы безопасности при просмотре на сайт на внешнем IP.
Полностью набирая мои предыдущие примечания, как сделать это с внутренним IP в стороне, как это может быть обработано simulatenously и для внутреннего и для внешнего IP? Как можно использовать самоподписанные сертификаты для обоих дюйм/с ни с какой генерацией предупреждения системы безопасности в браузере клиента?
Обратите внимание, что это не дубликат. Я понимаю, что существует информация там о Подчиненных Альтернативных названиях, Wildcard-сертификатах, и т.д. Однако:
Большая часть его для Apache; я использую IIS 7.
Большая часть его для Linux; я использую Windows.
Это также имеет тенденцию иметь дело с доменными именами, которые, кажется, необходимы для Wildcard-сертификатов; я использую дюйм/с только.
Часть из того, что оставляют в этой точке, ожидает, что у меня будут опции в IIS или в Windows, которые не универсально доступны.
Что можно оставить немного частей, немногим более, чем моя голова, и шаги, которые они используют, ожидают некоторое существующее ранее знание, которое это просто не там. Другими словами, они пропускают шаги, переход к усовершенствованным темам, и т.д.
Что такое четкий список шагов, чтобы сделать это, предполагая, что сервер является IIS 7 / Windows Server 2008 R2, и что клиентские машины используют Windows 7 (иногда Windows Embedded Standard) и различные версии IE? Клиенты получают доступ к страницам, веб-сервисам, и такой через IP-адреса, и я использовал OpenSSL (хотя я открыт для других опций).Спасибо.
См. Ответ Массимо для Правильного способа сделать это.
В противном случае вы можете добавить IP-адреса в SAN сертификата, создав файл конфигурации со следующими (плюс любые другие параметры, которые вы хотите):
[ v3_ca ]
subjectAltName = IP:1.2.3.4
Или, если у вас есть несколько IP-адресов ....
[ v3_ca ]
subjectAltName = @alt_names
[alt_names]
IP.1 = 1.2.3.4
IP.2 = 2.3.4.5
IP.3 = 3.4.5.6
Затем введите обычную команду OpenSSL для создания сертификата со следующими дополнениями:
-extfile configuration_file_mentioned_above.cnf -extensions v3_ca
Примечание: приведенная выше строка обычно начинается с openssl x509 -req , если у вас возникли проблемы.
Простейший действительный файл конфигурации будет примерно таким (я сохранил его как example.cfg ):
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
[ req_distinguished_name ]
commonName = TypeCommonNameHere
[v3_ca]
subjectAltName = @alt_names
[alt_names]
IP.1 = 203.0.113.1
IP.2 = 192.0.2.1
IP.3 = 198.51.100.1
Then run:
openssl req -x509 -nodes -days 3653 -newkey rsa:2048 -keyout example.key -out example.pem -config example.cfg
Он запросит общее имя для сертификата и напишет example.key и example.pem с закрытым и открытым ключами (соответственно). Также,вы должны поместить IP-адреса в файл конфигурации, но не можете поместить туда общее имя (вы можете, но вам все равно нужно ввести его, когда OpenSSL запрашивает его).
Кроме того, в этом примере используется весь файл конфигурации, где исходный ответ выше предполагает, что у вас уже есть файл конфигурации и вы дополняете его информацией SAN из файла конфигурации расширения (это, вероятно, просто более запутанно, но причина, по которой я не использовал аргументы, приведенные в исходном Ответе)
Вы действительно не должны использовать IP-адреса в сертификате SSL; вам следует настроить надлежащую инфраструктуру DNS, чтобы у вас, например, было internal.yourdomain.com указывает на внутренний IP-адрес, а external.yourdomain.com указывает на внешний; тогда вам нужно будет указать оба имени в качестве альтернативных имен субъектов в сертификате, и он будет работать безупречно.
Тем не менее, вы можете использовать IP-адреса в качестве сетей SAN; но как именно это можно сделать, зависит как от инструмента, который вы используете для запроса сертификата, так и от центра сертификации, который будет его выдавать.
В обоих случаях вы должны использовать одиночный сертификат с двумя SAN; использование двух сертификатов не имеет смысла и даже не сработает, потому что вы не можете привязать два разных сертификата к одному и тому же веб-сайту.
Если у вас есть два IP-адреса или на основе имени, вам понадобятся два сертификата и два определения https. На Apache httpd это будет два раздела vhost.