Подстановочный знак IP-адреса в сертификатах SSL / TLS

#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() , но это фактически означает привязку ко всем настроенным адресам (и интерфейсам).