можно ли с помощью openssl сгенерировать сертификат для всех доменов?
Зависит, но в основном да.Я называю это «Super Cert».
Я могу сказать только «в основном», потому что браузеры отвергнут методику ниже.Другие пользовательские агенты, платформы, библиотеки и даже операционные системы примут его.
Короче говоря, вы добавляете следующее к своему openssl.cnffile:
[ x509_ext ]
...
subjectAltName = @alternate_names
...
[ alternate_names ]
DNS.1 = *.com
DNS.2 = www.*.com
DNS.3 = *.net
DNS.4 = www.*.net
DNS.5 = *.gov
DNS.6 = www.*.gov
DNS.7 = *.mil
DNS.8 = www.*.mil
...
Затем вы подаете один и тот же сертификат для каждого запроса.
Причина, по которой он работает, состоит в том ... Есть две группы, которые публикуют правила, которые большинствоПользовательские агенты следуют.Во-первых, это базовые требования CA / Browser Forum .Второй - IETF с RFC 5280 и RFC 6125 .Браузеры следуют CA / Browser Forum BR.Другие пользовательские агенты, такие как cURL и Wget, и фреймворки, такие как Java, Cocoa и .Net, следуют RFC.
И CA / B, и IETF имеют правила для сопоставления с подстановочными знаками, и это означает, что вы должны работатьпри создании Супер Сертификата.Вы не можете просто использовать *.com и *.*.com для всех случаев.
В зависимости отв соответствии с правилами, иногда допускается использование нескольких подстановочных знаков, иногда подстановочный знак должен находиться в самой левой метке, а иногда подстановочный знак не может быть в метке домена.
Теперь браузеры откажутся сопоставлятьимя типа *.com в сертификате.Его кодифицировано в Базовых требованиях и Глобальных доменах верхнего уровня (рДВУ), перечисленных в Общедоступном списке суффиксов (PSL) , используемом браузерами.
Другие пользователи-агенты будут с радостью соответствовать емухотя это не имеет смысла.Вот пользовательские агенты, библиотеки и фреймворки, которые, похоже, не могут правильно подобрать.Здесь «правильный» означает обеспечение посредственного уровня безопасности.Эти пользовательские агенты должны знать, что канал подвергается атаке, когда они сталкиваются с сертификатом, который претендует на выдачу для всего рДВУ:
- Python
- Ruby
- Java
- .Net
- Какао
Мне кажется, я помню, что PERL был единственным, кто получил его частично правильно, отклонив *.com и друзья.Однако, если я правильно помню, он принял www.*.com.
К другим пользовательским агентам, которым не удалось отклонить бессмысленные имена хостов, относятся:
Когда я подавал сообщения об ошибках, наиболее цитируемым ответом для его принятия был«... но RFC не запрещает это».
Я пытался получить рабочую группу PKIX (PKI в Интернете) и рабочую группу DBOUND (доменграницы) , чтобы отклонить их (или, по крайней мере, не рекомендовать их принимать), поскольку мы знаем, что не существует единой организации, которая выпускает сертификаты для всех .COM, всех .NET и т. Д. Также см. Некоторые работы, которые, вероятно, поразят dbound раньше, чем позже .
Джеймс Полк сказал следующее:
ЦС подпишет его, только если сможет подтвердить, что вы управляете этими доменами.Если конечно вы не можете обмануть CA.
Это в основном верно.Если вы используете свою собственную PKI, то вы создаете Super Cert, подписываете его внутренним CA, и все будет работать так, как ожидается, как Public CA подписал его.
Это предполагает, что вы установили внутренний сертификат CA какподходит, но это то, что вы делаете, когда запускаете свой собственный CA.