#ssl-certificate #ip-address #wildcard-subdomain
#ssl-сертификат #ip-адрес #подстановочный знак -поддомен
Вопрос:
Сертификаты SSL / TLS, используемые для защиты веб-сайтов, позволяют указывать подстановочный знак поддомена:
*.example.com
будет действителен для www.example.com , subdomain.example.com и т.д.
Можно ли использовать подстановочные знаки для IP-адресов? В частности, мне нужен SSL-сертификат для локальной разработки, подобный этому:
192.168.1.*
, который затем будет действителен для любого из 256 различных IP-адресов, доступных внутри NAT-сети моего маршрутизатора WiFi.
Вместо того, чтобы просто использовать localhost
, 127.0.0.1
, 0.0.0.0
, ::1
в качестве альтернативных имен для моего сертификата, я также хочу иметь возможность подключать свой мобильный телефон для тестирования версии разработки моего веб-сайта, которая будет доступна, скажем 192.168.1.40
, по адресу. Но тогда тот же сертификат нельзя было бы повторно использовать с другой машины разработки, поскольку он получил бы другой IP-адрес в той же сети.
Let’s encrypt не поддерживает использование IP-адресов, что означает, что вместо этого я бы использовал самозаверяющие или локально доверенные сертификаты.
Комментарии:
1. Нет, это невозможно. Нет никакой гарантии, что если 192.168.0.1 принадлежит вам, то 192.168.0.2 не принадлежит кому-то другому.
Ответ №1:
№ RFC 2818, раздел 3.1, определяет соответствие подстановочных знаков для элементов dNSName; хотя здесь это неясно, это универсально реализовано, чтобы использовать подстановочный знак только в качестве самой левой метки DNS, которая является наименее значимой, поскольку имена DNS расположены справа налево. Он указывает, что если используется IPAddress, совпадение должно быть точным (без подстановочного знака), и даже если он разрешен подстановочный знак, поскольку IP-адреса указаны слева направо, только подстановочный знак справа, подобный тому, который вы предложили, будет полезен.
Однако, если вы используете только / 24 из 192.168.x.0 или меньше, как это делают многие люди, и, вероятно, только некоторые адреса в этом диапазоне, нетрудно просто перечислить все адреса, которые вам нужны в сертификате. Например, если вы используете адреса, назначенные DHCP, часто они охватывают только половину или меньше диапазона, номинально доступного из маски сети.
Ни один центр сертификации, работающий в соответствии с правилами CA / Browser forum и, следовательно, приемлемый для основных браузеров, не будет выдавать сертификат для частного адреса (RFC 1918); см. Базовые требования на https://wwww.cabforum.org . Они не будут использовать локальные или «поддельные» доменные имена, подобные .local .localdomain .dev .test
любому, по той же причине.
Кстати, 127.0.0.1 и ::1 являются реальными адресами, хотя и не маршрутизируемыми и, следовательно, могут использоваться только локально. 0.0.0.0 и ::0 разные; они вообще не являются адресами, и вы не можете connect()
их использовать; фактически они используются для представления состояния отсутствия подключения. Вы можете использовать их в bind()
, но это фактически означает привязку ко всем настроенным адресам (и интерфейсам).