Como o IE / Chrome sabe qual CA Intermediária usar quando não faz parte da cadeia?

Question

Um servidor na minha rede é assinado com um certificado emitido pelo RapidSSL CA, mas não fornece para concluir a cadeia do emissor (o certificado do RapidSSL CA é emitido pelo GeoTrust CA, que é uma autoridade raiz confiável).

Quando eu acesso o site usando o firefox, recebo o seguinte erro:

The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)

Mas se eu me conectar ao site usando o IE ou o chrome, isso funciona e notei que o RapidSSL é carregado como uma CA Intermediária posteriormente. Não entendo como o Chrome / IE (suponho que ele usa o armazenamento de certificados do Windows) sabe adicionar o RapidSSL como CA intermediária.

Eu recebo o comportamento esperado (de acordo comigo) quando uso openssl s_client para depurar a conexão.

Eu recebo o seguinte quando uso apenas o GeoTrust como CA:

Verify return code: 21 (unable to verify the first certificate)

Usando apenas RapidSSL como CA:

Verify return code: 2 (unable to get issuer certificate)

Ao usar os dois:

Verify return code: 0 (ok)

Alguém pode me ajudar a entender como o Windows sabe como carregar o RapidSSL CA como autoridade intermediária?

    

Answer 1

Os certificados de CA são baixados com base nas informações de URL na extensão de acesso a informações da autoridade (AIA) dos certificados emitidos.

O Firefox, pela última vez que ouvi, usa seu próprio armazenamento de certificados e / ou mecanismo de encadeamento. O Chrome e o IE usam o Windows.

Processo de validação de certificado

Quando um certificado é apresentado a um aplicativo, o aplicativo deve usar o mecanismo de encadeamento de certificado para determinar a validade do certificado. Somente depois que a cadeia de certificados for validada com êxito, o aplicativo poderá confiar no certificado e na identidade representada pelo certificado. Três processos distintos, mas inter-relacionados, são usados para determinar a validade de um certificado:

■ Descoberta de certificados Para criar cadeias de certificados, o mecanismo de encadeamento de certificados deve coletar o certificado de CA de emissão e todos os certificados de CA até o certificado da CA raiz. Os certificados de CA são coletados do cache CryptoAPI, da Diretiva de Grupo ou da Diretiva Corporativa ou, como último recurso, baixados dos URLs (URLs) nos Localizadores de recursos uniformes (AIA) nos certificados emitidos. Depois que um certificado é baixado de um local diferente do cache do CryptoAPI, ele é adicionado ao cache do CryptoAPI do usuário para uma recuperação mais rápida.

■ Validação de caminho Quando o mecanismo de encadeamento de certificado valida um certificado, ele não não pare no certificado apresentado. Cada certificado na cadeia de certificados deve ser validado até que um certificado raiz auto-assinado seja alcançado. Os testes de validação podem incluir verificando as assinaturas do authenticode, determinando se o certificado da CA emissora incluído no armazenamento NTAuth ou a inclusão de OIDs (identificadores de objeto de política) de aplicativo ou certificado específicos. Se um certificado falhar no teste de validade, é possível que toda a cadeia seja considerada inválida e não seja usada pelo aplicativo de chamada.

    

Answer 2

Na verdade, é o armazenamento de certificados diferente. Os intermediários são necessários apenas em aplicativos que ainda não possuem esses certificados. A CA do emissor é incluída em todos os certificados. A única questão é se esse certificado de emissor é confiável. A adição dos intermediários ajuda no software com um conjunto menor de certificados confiáveis instalados por padrão. .