Consigo acessar o site https://ce.uci.edu em máquinas não Linux (incluindo meu telefone) sem problemas. Mas quando navego até ele no meu computador Linux, no Chrome ou no Firefox, recebo um erro "NET::ERR_CERT_AUTHORITY_INVALID".
Por que meu sistema operacional está causando isso e outros não? A validação do certificado de segurança não deveria ser independente do sistema operacional?
Isso cria uma conversa estranha com o departamento de TI porque eles não veem nenhum problema.
O servidor não está enviando o certificado "intermediário" (também conhecido como "cadeia"), então o cliente simplesmente não tem informações suficientes para verificar.
O navegador da área de trabalho e/ou o sistema operacional examinam esse problema, armazenando em cache todos os certificados intermediários que ele vê. Quando você visita este site, o navegador usa seu cache para completar a cadeia. Navegadores móveis e aplicativos que não são navegadores geralmente não fazem isso.
Eles não sabem como verificar corretamente, além de apenas abrir o site em um navegador. ("Se abrir, funciona.")
Tente fornecer a eles, por exemplo, os resultados da verificação de https://www.ssllabs.com/ssltest/ , que é um site amplamente usado que tenta detectar exatamente esse tipo de configuração incorreta, entre outros.
O processo em si – sim (principalmente; pode ficar complicado).
(Vamos ignorar problemas triviais como bugs ou relógios incompatíveis.)
Listas de CA raiz "confiáveis"
A primeira diferença é que muitos navegadores não usam suas próprias listas de emissores de certificados "confiáveis" – eles delegam essa parte ao sistema operacional, e cada sistema operacional pode ter uma lista diferente. A Microsoft e a Apple certamente têm seus próprios programas emissores confiáveis para seus sistemas operacionais, enquanto a maioria das distribuições Linux usa a lista da Mozilla. (Acredito que o Google também tenha o seu próprio especificamente para Android, mas não para o Chrome de desktop.)
curl-ca-bundle.crt, que é uma cópia da lista do Mozilla) e, às vezes, esse arquivo fica bastante desatualizado.Cache
Há também a questão do "cache intermediário". Os certificados da web comerciais são sempre emitidos usando pelo menos um sistema de 2 camadas: a CA raiz é protegida offline e só emite certificados "intermediários", e apenas esses certificados estão online e têm permissão para emitir os certificados do servidor. Para passar na verificação, o cliente precisa conhecer toda a “cadeia”.
Normalmente, o cliente possui apenas as CAs raiz e o servidor envia os certificados intermediários. Mas às vezes o administrador do sistema configura incorretamente o servidor (ou é impossível configurar corretamente) de modo que os intermediários não sejam enviados e a cadeia de verificação seja interrompida. Por exemplo, seu site usa um certificado emitido por "InCommon RSA Server CA", que está um nível abaixo de uma CA raiz. Mas ele não envia o certificado InCommon em si, portanto, é impossível compará-lo com a lista de "CA raiz confiável".
Para lidar com esses erros, alguns navegadores – e alguns sistemas operacionais – criam um cache de CAs intermediárias vistas anteriormente. (O Windows armazena em cache aqueles que teve que baixar por conta própria; o Firefox armazena em cache todos os intermediários que viu.) Isso significa que, se você estiver visitando um site mal configurado, o sucesso/falha agora pode variar de usuário para usuário , pois todos eles têm diferentes caches construídos.
Isso se torna especialmente prejudicial quando a resposta automática do administrador do sistema é "Funciona bem no meu sistema", porque eles podem, sem saber , fazê - lo funcionar apenas no sistema.
construção de cadeia
Às vezes, é possível que várias cadeias sejam válidas para o mesmo certificado, devido a "assinaturas cruzadas" feitas. Por exemplo, os certificados Let's Encrypt podem ser enraizados no "DST Root CA X3" da IdenTrust ou podem ser enraizados em seu próprio "ISRG Root X1" novinho em folha, dependendo do que o cliente possui e de quais intermediários o servidor envia ( poderia enviar mais de um).
Alguns sites de mil/gov dos EUA usam seus próprios certificados PKI federais, em vez de certificados de uma CA comercial. O Windows é o único sistema operacional que vem com uma CA raiz "confiável" para isso; outros navegadores não a aceitarão, a menos que você instale manualmente algumas CAs raiz. E, dependendo de quais CAs raiz você instalar, o mesmo site pode ter muitos caminhos de confiança possíveis, às vezes até 6 a 7 certificados na cadeia.
Diferentes navegadores – especialmente aqueles que transferem a verificação para o sistema operacional – podem apresentar diferentes cadeias possíveis nessa situação – por exemplo, o Windows é muito flexível, enquanto o OpenSSL costumava ser muito inexistente antes de 1.1.x, e o Firefox passou por três reescritas de seu código de construção de encadeamento. (A biblioteca atualmente usada, mozilla::pkix, era inicialmente chamada de "insanity::pkix" e isso deve lhe dar uma dica de como ela pode ser desnecessariamente complexa.)
autoridadeInformaçõesAcesso
Mencionei que o Windows é capaz de baixar esses intermediários ausentes por si só - embora tecnicamente seja um recurso padrão, alguns navegadores se recusam completamente a implementá-lo devido a questões de privacidade e outros não se preocupam com isso devido à complexidade adicional desnecessária. Isso cria mais uma diferença entre o Windows e o Linux.
(Novamente, esse recurso é muito usado na "PKI federal" dos EUA, onde as assinaturas cruzadas são comuns e o sistema começa a parecer mais uma malha do que uma hierarquia enraizada. Por exemplo, a organização A pode reconhecer a cadeia A→B→C→ D, outro pode reconhecer B→A→C→D ou B→C→D com exatamente o mesmo certificado de servidor D.)