Questão de Segurança da Informação — ICP e Autoridades Certificadoras — FCC 2026

Certificado digital e cadeia de confiança: por que o navegador não confia

Gabarito: letra A. O problema descrito é clássico de Infraestrutura de Chaves Públicas (ICP): o certificado do site é válido (não expirou), mas foi emitido por uma Autoridade Certificadora (AC) interna que não está na lista de âncoras de confiança do navegador. A solução tecnicamente correta é instalar o certificado dessa AC interna como confiável nas estações de trabalho, estabelecendo a cadeia de confiança entre o navegador e o certificado do servidor. As demais alternativas — ignorar o aviso, desativar a verificação, trocar HTTPS por HTTP ou reinstalar o navegador — são práticas inseguras ou ineficazes.

Para entender por que isso acontece, é preciso compreender o modelo de confiança dos certificados digitais. Um certificado digital é um registro eletrônico que associa uma entidade (pessoa, empresa, servidor) a uma chave pública, e é emitido por uma Autoridade Certificadora. Quando você acessa um site via HTTPS, o servidor apresenta seu certificado; o navegador, então, precisa verificar se esse certificado é confiável. Essa verificação não é feita isoladamente: o navegador sobe a cadeia de certificação até encontrar uma âncora de confiança — um certificado de uma AC raiz que já esteja pré-instalado em seu repositório de certificados confiáveis.

No cenário da questão, o certificado do servidor foi emitido por uma AC interna do órgão público. Essa AC não é reconhecida automaticamente pelos navegadores, pois não faz parte das raízes confiáveis que eles trazem de fábrica. O aviso "Sua conexão não é privada" é o mecanismo de segurança do navegador indicando exatamente isso: ele não consegue validar a cadeia de confiança até uma âncora conhecida. O certificado em si pode estar perfeitamente válido — dentro do prazo de validade, com a chave correta — mas, sem a cadeia de confiança, o navegador não tem como atestar a autenticidade do servidor.

A solução adequada, portanto, é instalar o certificado da AC interna no repositório de certificados confiáveis das estações de trabalho. Ao fazer isso, o navegador passa a reconhecer a AC interna como uma âncora de confiança, e a cadeia se completa: AC interna → certificado do servidor. Essa é uma prática comum em ambientes corporativos que utilizam sua própria infraestrutura de chaves públicas para emitir certificados para serviços internos. É importante destacar que essa instalação deve ser feita de forma controlada e segura, preferencialmente via política de grupo (GPO) ou gerenciamento centralizado, para que apenas as ACs legítimas da organização sejam adicionadas.

A alternativa A é a única que resolve o problema de forma tecnicamente correta e segura. As demais alternativas são armadilhas clássicas: ignorar o aviso (C) expõe os usuários a ataques de interceptação (man-in-the-middle), desativar a verificação (D) remove uma camada essencial de segurança, trocar HTTPS por HTTP (E) elimina a criptografia e a autenticação do servidor, e reinstalar o navegador (B) não resolve nada, pois o problema não está nas configurações do navegador, mas na ausência da AC interna no repositório de confiança.

A pegadinha central desta questão é a distinção entre certificado válido e certificado confiável. O certificado pode ser tecnicamente válido (dentro do prazo, com a criptografia correta), mas não ser confiável porque a AC que o emitiu não é reconhecida. É exatamente essa distinção que separa a alternativa correta das incorretas.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta é a providência tecnicamente adequada. Ao instalar o certificado da AC interna como confiável nas estações de trabalho, o navegador passa a reconhecer a cadeia de confiança: AC interna → certificado do servidor. Isso resolve o aviso de segurança sem comprometer a proteção da comunicação. A instalação deve ser feita no repositório de certificados raiz confiáveis do sistema operacional ou do navegador, e é uma prática padrão em ambientes corporativos com ICP própria.

Alternativa B — ❌ Incorreta

Reinstalar o navegador não resolve o problema, pois o navegador não está com configurações corrompidas. O aviso ocorre porque a AC interna não está no repositório de confiança — e reinstalar o navegador apenas restauraria as configurações padrão, que não incluem a AC interna. O problema é de infraestrutura de certificados, não de software do navegador.

Alternativa C — ❌ Incorreta

Orientar os usuários a ignorar o aviso de segurança é uma prática extremamente perigosa. O aviso existe justamente para proteger contra conexões não autenticadas, que podem ser alvo de ataques de interceptação (man-in-the-middle). Ignorar o aviso abre brecha para que um atacante se passe pelo servidor legítimo e capture dados sensíveis. A orientação correta é resolver a causa raiz, não contornar o alerta.

Alternativa D — ❌ Incorreta

Desativar a verificação de certificados no navegador remove uma camada essencial de segurança. Isso faria o navegador aceitar qualquer certificado, inclusive os de sites maliciosos, expondo os usuários a ataques de interceptação e phishing. A verificação de certificados é um mecanismo fundamental do HTTPS e não deve ser desativada.

Alternativa E — ❌ Incorreta

Substituir HTTPS por HTTP elimina a criptografia e a autenticação do servidor, tornando a comunicação vulnerável a interceptação e adulteração. O HTTPS é essencial para proteger dados em trânsito, especialmente em um sistema de protocolo eletrônico que pode conter informações sensíveis. A solução não é abandonar o HTTPS, mas sim estabelecer a cadeia de confiança do certificado.

Gabarito: letra A