Сервер в моей сети подписан сертификатом, выданным RapidSSL CA, но не предоставляет полную цепочку эмитентов (сертификат RapidSSL CA выдается GeoTrust CA, который является доверенным корневым центром).
Когда я захожу на сайт с помощью firefox, я получаю следующую ошибку:
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)
Но если я подключаюсь к сайту с помощью IE или Chrome, он работает, и я заметил, что RapidSSL затем загружается как промежуточный центр сертификации. Я не понимаю, как Chrome / IE (я предполагаю, что он использует хранилище сертификатов Windows) знает, что нужно добавить RapidSSL в качестве промежуточного центра сертификации.
Я получаю ожидаемое поведение (по моему мнению), когда использую openssl s_client
для отладки соединения.
Я получаю следующее, когда использую GeoTrust только как CA:
Verify return code: 21 (unable to verify the first certificate)
Использование только RapidSSL в качестве CA:
Verify return code: 2 (unable to get issuer certificate)
При использовании обоих:
Verify return code: 0 (ok)
Может ли кто-нибудь помочь мне понять, как Windows узнает о загрузке RapidSSL CA в качестве промежуточного органа?
Сертификаты CA загружаются на основе информации URL в расширении доступа к информации о полномочиях (AIA) выданных сертификатов.
Последнее, что я слышал, Firefox использует собственное хранилище сертификатов и / или механизм цепочки. Chrome и IE используют тот же, что и в Windows.
Процесс проверки сертификата
Когда сертификат предоставляется приложению, приложение должно использовать механизм цепочки сертификатов для определения действительности сертификата. Только после успешной проверки цепочки сертификатов приложение может доверять сертификату и идентификатору, представленному сертификатом. Для определения действительности сертификата используются три различных, но взаимосвязанных процесса:
■ Открытие сертификата Чтобы построить цепочки сертификатов, механизм цепочки сертификатов должен собрать сертификат ЦС, выдающий сертификат, и все сертификаты ЦС до сертификата корневого ЦС. Сертификаты CA собираются из кэша CryptoAPI, групповой политики или корпоративной политики или, в крайнем случае, загружаются из унифицированных указателей ресурсов (URL-адресов) доступа к авторитетной информации (AIA) в выпущенных сертификатах. После загрузки сертификата из места, отличного от кеша CryptoAPI, он добавляется в кэш CryptoAPI пользователя для более быстрого поиска.
■ Проверка пути Когда механизм цепочки сертификатов проверяет сертификат, он не останавливается на представленном сертификате. Каждый сертификат в цепочке сертификатов должен проверяться до получения самоподписанного корневого сертификата. Проверочные тесты могут включать проверку подписей аутентификационных кодов, определение того, включен ли выпускающий сертификат CA в хранилище NTAuth, или включение определенных идентификаторов объектов политики сертификатов или приложений (OID). Если один сертификат не прошел проверку на достоверность, возможно, что вся цепочка будет признана недействительной и не будет использоваться вызывающим приложением.
Это действительно другое хранилище сертификатов. Промежуточные звенья необходимы только в приложениях, в которые еще не встроены эти сертификаты. ЦС эмитента включен в каждый сертификат. Вопрос только в том, доверяют ли этому сертификату эмитента. Добавление промежуточных звеньев помогает программному обеспечению с меньшим набором доверенных сертификатов, установленным по умолчанию. .