Мы запускаем внутренний центр сертификации на базе сервера Ubuntu 16.04 и бэкэнда OpenSSL для внутренних ресурсов в смешанной среде Windows / Linux.
Этот ЦС используется с некоторыми внутренними веб-сайтами в попытке предоставить действительные, надежные сертификаты сайтов для внутренних веб-сайтов, развертываний программного обеспечения и т. Д. У нас есть одна проблема.
Сертификат CA Root передается во все наши системы Windows с помощью объекта групповой политики или был установлен вручную. Однако каждый сертификат, подписанный этим ЦС, в конечном итоге вызывает некоторые проблемы - Chrome и Firefox указывают, что сертификат имеет недопустимое общее имя, в то время как другие утилиты, такие как сервер XMPP здесь, не могут проверить сертификат, даже если сертификат ЦС находится в трастовые магазины.
Только Internet Explorer уважает сертификат. К сожалению, мы являемся разработчиками Chrome и Firefox, поэтому использование IE для всего будет проблемой.
Кто-нибудь придумал решение для создания сертификата CA OpenSSL и его подписанных сертификатов для выпущенных сертификатов не иметь ошибку «Недопустимое общее имя» в Chrome и Firefox и, таким образом, разрешить внутренним сертификатам считаться «действительными»?
Я действительно понял основную проблему, и потребовалось много поисков. Наконец-то нашел ответ на StackOverflow, что в сочетании с моим исследованием фактических данных самого сертификата с openssl req -text -noout -verify -in CSR.csr читать данные в CSR, и openssl x509 -in certificate.crt -text -noout чтобы проанализировать сгенерированный сертификат и сравнить эти два, указать на основную проблему.
По-видимому, OpenSSL игнорировал раздел нашего файла конфигурации, относящийся к расширениям V3, и не выполняет расширения v3, если вы сказать это правильно на фактическом шаге подписи CA ...
Это данные файла конфигурации, передаваемые в openssl req команда:
[ req ]
default_bits = 4096
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = v3_req
[ dn ]
C=US
ST=Pennsylvania
L=Somewhere
O=No Man's Land
OU=Internal
CN = chat.foo.bar.baz
[ v3_req ]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage=serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = chat.foo.bar.baz
DNS.2 = chat
DNS.3 = 10.1.2.151
Стандартный вызов следующего кода каким-то образом не учитывает расширения v3:
openssl req -new -sha256 -out cert.csr -key cert.key -config csrgen.cnf
... однако это сработало:
openssl req -new -sha256 -out cert.csr -key cert.key -config csrgen.cnf -extensions v3_req
... и когда подписание сертификат с ЦС, нам пришлось использовать что-то вроде этого, выполняя это из того места, где у нас хранились все сертификаты сайта (включая CSR и ключ, для генерации сертификата в первую очередь - сертификаты ЦС и ключи находятся в отдельном /certauthority/... раздел в нашей системе):
openssl x509 -req -days 3650 -in ./cert.csr -CA /certauthority/certs/cacert.pem -CAkey /certauthority/private/cakey.pem -CAserial /certauthority/CA/serial -CAcreateserial -out certificate.crt -extfile csrgen.cnf -extensions v3_req
Эта команда правильно поместила расширения v3 в сертификат и каким-то образом игнорируется в противном случае фактические расширения в файле. Это, в свою очередь, решило проблемы CN и SAN, и теперь система возвращает сертификат как «действительный» для внутренних сайтов и (большинства) внутренних служб.