Внутренний сетевой центр сертификации: «Недействительное общее имя» или недействительный сертификат для всего (кроме Internet Explorer и Windows 'Certificates mmc snapin)
Мы запускаем внутренний центр сертификации на базе сервера Ubuntu 16.04 и бэкэнда OpenSSL для внутренних ресурсов в смешанной среде Windows / Linux.
Этот CA используется с некоторыми внутренние веб-сайты в попытке предоставить действительные, надежные сертификаты сайтов для внутренних веб-сайтов, развертываний программного обеспечения и т. д. У нас есть одна проблема.
Корневой сертификат CA передается во все наши системы 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
... и когда подписывает сертификат с CA, мы должны были использовать что-то вроде этого, выполняя это оттуда, где у нас все сохраненные сертификаты сайта (включая CSR и ключ, в первую очередь для генерации сертификата - сертификаты и ключи CA находятся в отдельном разделе / 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, и теперь система возвращает сертификат как «действительный» для внутренних сайтов и (большинства) внутренних служб.