Можно ли вообще получить SSL-сертификат для IPv6-адреса, например https://[1234:5678:9000:abcd:9876:5432:10ab:cdef]? Если да, то есть ли примеры такого использования? Предположим, что настройка личного корневого центра сертификации и установка на устройства в этом случае является приемлемым вариантом.
Этот вопрос похож на: "SSL-сертификат для публичного IP-адреса?", но это не совсем то же самое, потому что:
Да, subjectAltName расширение позволяет iPAddress OID, который может содержать IPv6-адрес в виде 16 октетов в сетевом порядке байтов. Видеть RFC5280 s4.2.1.6 Больше подробностей.
Технически вы можете иметь IP-адрес (v4 или v6, не имеет значения) в разделе SAN сертификата X.509, однако не без мер предосторожности.
Они редки в мире HTTPS (потому что они побеждают массовый виртуальный хостинг HTTPS), но существуют, https://1.1.1.1/ это известный случай. Используя поиск в журналах прозрачности сертификатов, вы можете найти гораздо больше сертификатов, имеющих IP-адреса в расширении альтернативного имени субъекта, вот ссылка для поиска некоторых: https://censys.io/certificates?q=parsed.extensions.subject_alt_name.ip_addresses%3A* (Мне также не удалось найти способ специально искать адреса IPv6; https://crt.sh/ также есть критерии поиска для Identify / iPAddress, но мне вообще не удалось заставить его работать).
Они действительно нужны новичкам »DNS через HTTP" и "DNS через TLS"протоколы.
Обратите внимание, что:
Клиент DoH может столкнуться с аналогичной проблемой начальной загрузки, когда HTTP-запрос должен разрешить часть имени хоста DNS URI. Просто
поскольку адрес традиционного DNS-сервера имен не может быть изначально
определяется с того же сервера, клиент DoH не может использовать свой DoH
server для первоначального преобразования имени хоста сервера в адрес.
Альтернативные стратегии, которые может использовать клиент, включают 1)
часть конфигурации начального разрешения, 2) URI на основе IP и
соответствующие сертификаты на основе IP для HTTPS, или 3) разрешение
Имя хоста сервера DNS API через традиционный DNS или другой сервер DoH
при этом все еще аутентифицируя полученное соединение через HTTPS.
Но обратите внимание, что сертификаты с IP-адресами работают и существовали задолго до того, как DoT и DoH стали мейнстримом, но в другой области, которая малоизвестна: RPKI. Это касается защиты обмена BGP: когда кто-то объявляет определенный блок IP-адресов через свой RIR, из которого он получил блок IP-адресов, он может получить сертификат (следовательно, подписанный ЦС RIR), содержащий как его блоки IP-адресов, так и его Номер AS. Это позволяет другим проверять, объявляются ли IP-адреса правильным номером AS. Видеть https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure для начинающих по всему этому.
Эти сертификаты нормализованы в RFC 6487 и выглядят они так:
Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer
Data:
Version: 3 (0x2)
Serial: 1500 (0x5dc)
Signature Algorithm: SHA256WithRSAEncryption
Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s
Validity
Not Before: Oct 25 12:50:00 2008 GMT
Not After : Jan 31 00:00:00 2010 GMT
Subject: CN=A91872ED
Subject Public Key Info:
[...]
X509v3 extensions:
[...]
sbgp-autonomousSysNum: critical
Autonomous System Numbers:
24021
38610
131072
131074
sbgp-ipAddrBlock: critical
IPv4:
203.133.248.0/22
203.147.108.0/23
См. RFC 5280, как сказал вомбл в своем ответе. Обратите особое внимание на тот факт, что вам нужно использовать поле «IPAddress» в альтернативном имени субъекта, а не часто используемый по умолчанию / общий случай «DNSname», который применяется только к именам.
Этот RFC правильно обслуживает адреса IPv4 и IPv6:
Если расширение subjectAltName содержит iPAddress, адрес ДОЛЖЕН быть сохранен в строке октетов в «сетевом порядке байтов», как указано в [RFC791]. Самый младший бит (LSB) каждого октета - это LSB соответствующего байта в сетевом адресе. Для IP версии 4, как указано в [RFC791], строка октета ДОЛЖНА содержать ровно четыре октета. Для IP версии 6, как указано в
[RFC2460] строка октетов ДОЛЖНА содержать ровно шестнадцать октетов.
Если вы контролируете CA, то подписать правильно построенный CSR не проблема. Если вы хотите, чтобы он был подписан известным центром сертификации, вам нужно будет найти тот, который согласен это сделать, и, хотя у меня нет списка, я считаю, что они существуют, но не являются большинством.
Большинство центров сертификации и тех, которые распознаются браузерами, применяют рекомендации CAB Forum. Помимо прочего, они описывают, какой тип проверки должен выполнять ЦС на основе содержимого выдаваемого сертификата.
Видеть https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf
В вашем конкретном случае:
7.1.4.2.1 Альтернативное имя субъекта Поле ExtensionCertificate: extension: subjectAltNameRequired / Optional: RequiredContents: Это расширение ДОЛЖНО содержать по крайней мере одну запись. Каждая запись ДОЛЖНА быть либо dNSName, содержащим полное доменное имя, либо iPAddress, содержащим IP-адрес сервера. ЦС ДОЛЖЕН подтвердить, что кандидат контролирует полное доменное имя или IP-адрес или что ему предоставлено право использовать его регистрантом доменного имени или уполномоченным IP-адресом, в зависимости от обстоятельств.
В разделе 3.2.2.5 подробно описано, как проверяется IP-адрес, со следующими возможностями (подробности см. В документе):
Более подробная информация по последним двум пунктам также представлена на https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4 который в точности ссылается на протокол ACME, недавно опубликованный как RFC: https://tools.ietf.org/html/rfc8555
Есть некоторые моменты, которые не всегда хорошо известны и не соблюдаются центрами сертификации. Но в целом они должны отозвать любой сертификат, как только базовые свойства больше не проверяются. Например, если домен не продлен текущим владельцем и не зарегистрирован другим, то существующий сертификат должен быть отозван.
То же самое и с IP-адресами: при смене владельца блока существующие сертификаты должны быть отозваны.
Существует проект по присвоению имени каждому IPv6-адресу. У них есть соответствующий образ Docker, который запускает Let's Encrypt с этими именами. Это не совсем то же самое, что «сертификат для IPv6-адреса», но он довольно близок и автоматизирован.
Что касается производственного использования, cloudflare-dns.com более известен как 1.1.1.1. SAN сертификата включают адреса IPv4 и IPv6 службы.
Я подозреваю, что причиной такого сертификата является реализация DNS через TLS. Также в ответ на https вы можете увидеть сертификат в своем браузере: https: // [2606: 4700: 4700 :: 1111]
Реализации, поддерживающие subjectAltName, но не iPAddress v6, являются ошибкой.
Есть несколько примеров запросов сертификатов iPAddress, и еще меньше с v6. Благодаря FreeIPA для тестирования v6 когда они недавно добавили сертификаты IP-адресов. Запрос сертификата может быть сгенерирован с помощью NSS следующим образом:
certutil --extSAN dns:host.example.com,ip:2001:db8:3902:3468::443