Truststore de certificados

O que é uma truststore de certificados?

Truststore pode ser traduzida como repositório de confiança. É uma espécie de lista de autoridades certificadoras que o sistema considera confiáveis. Sempre que o software se conecta a outro servidor por uma conexão segura, ele consulta essa lista para decidir se pode confiar na identidade de quem está do outro lado.

Na prática, a truststore guarda apenas certificados públicos, normalmente de autoridades certificadoras raiz e intermediárias. Ela não contém chaves privadas nem senhas de assinatura, por isso não serve para assinar documentos, apenas para validar certificados de terceiros.

Como a truststore funciona em uma conexão HTTPS?

Quando um sistema acessa um endereço HTTPS, o servidor apresenta seu certificado digital. O sistema então verifica a cadeia de certificação desse certificado: quem o emitiu, quem emitiu o emissor e assim por diante, até chegar a uma autoridade raiz.

Se essa autoridade raiz, ou uma intermediária da cadeia, estiver na truststore, a conexão é considerada confiável e segue normalmente. Se não estiver, o sistema interrompe a comunicação, porque não consegue garantir que está falando com o servidor verdadeiro e não com um impostor.

Qual a diferença entre truststore e keystore?

A keystore guarda a identidade do próprio sistema: o certificado e a chave privada usados para se autenticar e assinar. Um certificado digital A1 em arquivo PFX, usado para assinar o XML de uma NF-e, é um exemplo de conteúdo de keystore.

A truststore guarda as identidades em que o sistema confia, ou seja, certificados de terceiros. Uma forma simples de lembrar: a keystore responde quem eu sou, e a truststore responde em quem eu confio. Em muitas tecnologias as duas usam o mesmo formato de arquivo, como JKS ou PKCS12, mas cumprem papéis diferentes.

Por que a truststore importa na emissão de notas fiscais?

Os webservices das secretarias da fazenda e de muitas prefeituras utilizam certificados emitidos dentro da ICP-Brasil. Nem sempre as truststores padrão de sistemas operacionais e linguagens de programação incluem as autoridades raiz da ICP-Brasil, o que pode impedir a conexão com esses serviços.

Por isso, quem integra diretamente com a SEFAZ costuma precisar adicionar a AC Raiz da ICP-Brasil e suas autoridades intermediárias à truststore da aplicação, além de mantê-la atualizada quando novas cadeias são publicadas. Quando a emissão é feita por uma API fiscal intermediária, essa gestão em geral fica com o provedor, e o sistema do cliente só precisa confiar no certificado HTTPS da própria API.

Quais problemas comuns envolvem a truststore?

O erro mais frequente é a falha na validação da cadeia, que em aplicações Java costuma aparecer como mensagem de que não foi possível construir o caminho de certificação. Isso indica que a autoridade que emitiu o certificado do servidor não está na truststore.

Outros problemas incluem truststore desatualizada após a renovação de cadeias de certificação, uso de uma truststore diferente da esperada pela aplicação e a solução insegura de desativar a validação de certificados para contornar o erro, o que expõe a integração a ataques de interceptação.

Exemplos de Truststore de certificados

• Uma software house em Java recebe erro ao chamar o webservice de autorização da NF-e e resolve o problema importando os certificados da cadeia ICP-Brasil para a truststore da aplicação.
• Um ERP que emite notas por uma API fiscal mantém apenas a truststore padrão do sistema operacional, suficiente para validar o certificado HTTPS do provedor, sem precisar lidar com as cadeias de cada SEFAZ.
• A equipe de infraestrutura de uma plataforma de vendas inclui a atualização da truststore no checklist de manutenção, para evitar falhas quando uma autoridade certificadora publica nova cadeia.
• Um desenvolvedor configura em um ambiente de homologação uma truststore em formato PKCS12 contendo apenas as autoridades necessárias para se comunicar com o webservice de NFS-e de um município.