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

Как IE / Chrome узнает, какой промежуточный ЦС использовать, если он не входит в цепочку?

Сервер в моей сети подписан сертификатом, выданным 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). Если один сертификат не прошел проверку на достоверность, возможно, что вся цепочка будет признана недействительной и не будет использоваться вызывающим приложением.

Это действительно другое хранилище сертификатов. Промежуточные звенья необходимы только в приложениях, в которые еще не встроены эти сертификаты. ЦС эмитента включен в каждый сертификат. Вопрос только в том, доверяют ли этому сертификату эмитента. Добавление промежуточных звеньев помогает программному обеспечению с меньшим набором доверенных сертификатов, установленным по умолчанию. .