Назад | Перейти на главную страницу

Могу ли я использовать подстановочные знаки с самозаверяющими сертификатами SAN?

У нас есть сервер разработки, доступный через Интернет, но с ограничением по 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 соответственно и протестировали несколько доменов:

Таким образом, похоже, что первый уровень подстановочного знака работал нормально, но ниже этого нет. То же самое для 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.