У нас есть сервер разработки, доступный через Интернет, но с ограничением по IP, поэтому безопасность здесь - это просто способ позволить нам воспроизвести живую среду, а не пытаться обеспечить безопасность. Домен верхнего уровня, назовем его dev.com
, не используется, но разработчики настраивают каждый сайт в своем собственном субдомене. Итак, скажем, есть site1.com
, site2.com
и site3.com
, затем разработчики george
и nico
будет иметь полные URL-адреса, например:
Первоначально я думал, что подстановочный самозаверяющий сертификат подойдет, но позже обнаружил, что *.dev.com
применяется только к something.dev.com
а не суб-субдомены. Я решил следовать инструкциям в этот ответ. Когда я использую:
DNS.1 = www.site2.com.nico.dev.com
DNS.2 = www.site1.com.george.dev.com
все работает нормально, но, к сожалению, на многих сайтах много разработчиков, так что для DNS.x
Вот. Я хотел знать, можно ли использовать подстановочные знаки в [ alternate_names ]
раздел моего openssl.cnf
. Я пробовал следующее:
DNS.1 = dev.com
DNS.2 = www.site1.com.george.dev.com
DNS.3 = *.*.*.nico.dev.com
В то время как DNS.2
работал, DNS.3
нет, давая мне ошибку NET::ERR_CERT_COMMON_NAME_INVALID
в Chrome.
Есть ли способ сделать это, или мне придется создать очень длинный список DNS.x
записи для охвата всех сайтов?
Я слышал, что это станет возможным благодаря созданию собственного центра сертификации. Я выполнил отличные инструкции по этот ответ. Со своим собственным ЦС я создал сертификат с DNS.1
то же, что и обычное имя, и DNS.2
и DNS.3
с такими символами:
DNS.1 = dev.com
DNS.2 = *.dev.com
DNS.3 = *.*.*.*.nico.dev.com
Затем я импортировал cacert.pem
из первого шага руководства, связанного с выше, в Chrome в качестве доверенного корневого центра сертификации и перезапустил браузер. Для каждой конфигурации домена я установил SSLCertificateKeyFile
и SSLCertificateFile
к serverkey.pem
и servercert.pem
соответственно и протестировали несколько доменов:
NET::ERR_CERT_COMMON_NAME_INVALID
NET::ERR_CERT_AUTHORITY_INVALID
Таким образом, похоже, что первый уровень подстановочного знака работал нормально, но ниже этого нет. То же самое для Chrome и IE (которые используют сертификаты Windows) и для Firefox (который управляет своим собственным).
Итак, мой вопрос остается, возможно ли таким образом использовать суб-суб (-sub *) домены?
Публичные подписанные сертификаты:
Технический ответ
Да. Ничто не препятствует созданию сертификатов SAN поддоменов с подстановочными знаками с любым сочетанием уровней подстановочных знаков и доменов. Если вы управляете собственным внутренним центром сертификации, то вы можете создать сертификат SAN с любой комбинацией поддоменов, подстановочных знаков и т. Д.
Практический ответ на основе моего собственного опыта
Нет. или вряд ли ... Я не знаю ни одного центра сертификации, который продаст вам один из них. Я попросил несколько центров сертификации об этом решении, и каждый из них немедленно отклонил запрос. Я подозреваю, что они боятся потерять деньги, предлагая такие сертификаты. Они предпочитают, чтобы у вас был один подстановочный знак для каждой зоны (субдомен или нет) или один сертификат SAN с максимум п Число входов. п число, которым вас ограничит конкретный CA. Мне не удалось найти центр сертификации, который будет продавать сертификат SAN с набором поддоменов с подстановочными знаками. Я бы предоставил список центров сертификации, которые я запрашивал, но подозреваю, что здесь это неуместно.
[Обновить]
Самоподписанные сертификаты
Я неправильно понял смысл вопроса. Я считаю, что нужен был пример openssl.cnf. Вот один пример Вам нужно будет заменить записи DNS на имена поддоменов с подстановочными знаками. Есть несколько постов на security.stackexchange.com а также вокруг этой установки. Я не тестировал это, так как мои потребности были связаны с общедоступными URL-адресами, а CA не разрешили бы это как вариант.
У вас может быть только один уровень подстановочного знака.
* .example.com будет охватывать something.example.com, но не one.anything.example.com.
* .subdomain.example.com будет обрабатывать все, что угодно. subdomain.example.com.