Guia de Implementação da SES GO - Segurança - Local Development build (v0.0.2) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Montar cadeia
A cadeia de certificados é exigida pela política para compor uma assinatura digital, conforma entrada (item 4) do caso de uso de criação de assinatura digital.
Objetivo
Permitir a recuperação da cadeia completa de certificados digitais (x5c), a partir de um certificado do signatário. O serviço deve manter em cache as cadeias recuperadas com sucesso, otimizando desempenho e reduzindo consultas posteriores.
Entradas
-
Certificado digital do signatário (folha/end-entity), no formato X.509v3 DER codificado em base64 padrão. O certificado deve ser válido e elegível para uso em assinatura digital ICP-Brasil.
-
Configurações operacionais:
- Parâmetros de cache de cadeia: tempo de vida (TTL) para o cache de cadeias de certificados já construídas. Valor padrão 86400 segundos (24h), intervalo permitido [300, 604800].
- Timeouts para busca de certificados intermediários: valor padrão 20 segundos, intervalo [5, 120].
- Limite máximo de profundidade da cadeia: padrão 5, intervalo [2, 10].
Saída
- Cadeia de certificados (array JSON): array ordenado de certificados digitais desde o certificado do signatário (folha) até a raiz ICP-Brasil (inclusive). O formato e requisitos são idênticos ao item 4 das entradas do caso de uso criar assinatura digital:
- Cada elemento do array é uma string contendo um certificado X.509v3 no formato DER codificado em base64 padrão.
- Posição 0: certificado do signatário.
- Demais posições: certificados intermediários, se existirem, e por fim o certificado da AC Raiz ICP-Brasil.
- A cadeia deve conter pelo menos dois certificados.
- A ordenação deve formar uma cadeia de confiança válida, onde cada certificado é assinado pelo próximo.
- Em caso de falha, retorna uma instância do recurso OperationOutcome detalhando a situação excepcional, conforme perfil e códigos padronizados do guia.
Processo
1 Carga do certificado do signatário
- Decodifique o certificado fornecido (base64 DER) e valide o formato X.509.
- Se inválido, retorne
FORMAT.BASE64-INVALID ou CERT.INVALID-FORMAT.
2 Verificação de elegibilidade ICP-Brasil
- Examine a extensão Certificate Policies (OID 2.5.29.32) do certificado folha.
- Confirme a existência de pelo menos uma política com OID iniciado por
2.16.76.1.
- Se ausente, retorne
CERT.NOT-ICP-BRASIL.
3 Construção da cadeia de certificados
3.1 Inicialize a cadeia com o certificado do signatário e o torne o certificado corrente.
3.2 Para cada certificado corrente, execute as ações seguintes:
3.2.1 Verificação de certificado autoassinado (raiz):
- Se o certificado corrente é autoassinado:
- Verifique se o certificado está presente no cache de consulta do trust store (por hash SHA-256).
- Se presente, a cadeia está completa. Retorne a cadeia como resultado.
- Se não presente, retorne
CERT.NOT-ICP-BRASIL.
3.2.2 Localização do certificado da AC emissora:
- Se o certificado corrente não é autoassinado, localize o certificado digital da AC que o emitiu.
- A localização é feita consultando o cache de consulta do trust store, que contém todos os certificados da ICP-Brasil e é mantido pelo caso de uso de gestão do trust store.
- Execute as estratégias abaixo na ordem de prioridade. Uma estratégia é executada apenas se a anterior não localizar o certificado desejado:
3.2.2.1 Localização por Authority Key Identifier (AKI):
- Se o certificado corrente possui a extensão AKI (OID
2.5.29.35):
- Extraia o
keyIdentifier da AKI.
- Localize no cache de consulta do trust store um certificado cujo SKI (Subject Key Identifier, OID
2.5.29.14) corresponda ao keyIdentifier extraído.
- Se encontrado, valide o certificado (formato, elegibilidade ICP-Brasil, validade temporal) e a assinatura.
- Se válido, adicione o certificado encontrado à cadeia, torne-o o novo certificado corrente e retorne à seção 3.2.
3.2.2.2 Localização por Issuer DN (fallback):
- Extraia o Issuer DN do certificado corrente.
- Se o cache de consulta do trust store contém certificados com Subject DN igual ao Issuer DN:
- Filtre os candidatos pelo período de validade (Not Before / Not After) do certificado corrente.
- Entre os candidatos filtrados, localize aquele que assina o certificado corrente.
- Se encontrado, valide o certificado (formato, elegibilidade ICP-Brasil, validade temporal) e a assinatura.
- Se válido, adicione o certificado encontrado à cadeia, torne-o o novo certificado corrente e retorne à seção 3.2.
3.2.2.3 Localização por Authority Information Access (AIA) (fallback):
- Se o certificado possui a extensão AIA (OID
1.3.6.1.5.5.7.1.1):
- Extraia a URL "CA Issuers" (OID
1.3.6.1.5.5.7.48.2).
- Baixe o certificado da AC a partir da URL (timeout: 20 segundos).
- Valide o certificado baixado (formato, elegibilidade ICP-Brasil, validade temporal).
- Valide se o certificado baixado assina o certificado corrente e se o Issuer DN corresponde ao Subject DN.
- Se válido, armazene no cache (indexado pelo hash SHA-256), adicione o certificado baixado à cadeia, torne-o o novo certificado corrente e retorne à seção 3.2.
- O certificado baixado via AIA é usado para a construção da cadeia atual e não deve ser adicionado permanentemente ao trust store principal.
3.2.3 Falha na localização do certificado da AC emissora:
- Se nenhuma das estratégias anteriores foi bem-sucedida, retorne
CERT.CHAIN-INCOMPLETE.
4 Validação da cadeia
- Confirme que a cadeia está corretamente ordenada e cada certificado é assinado pelo próximo.
- O último certificado deve corresponder a uma AC Raiz ICP-Brasil do cache de consulta do trust store (por hash SHA-256).
- Se a validação falhar, retorne
CERT.CHAIN-VALIDATION-FAILED.
5 Armazenamento em cache
- Se a cadeia foi obtida com sucesso, armazene no cache local, indexada pelo hash SHA-256 do certificado do signatário, com o TTL configurado.
- Consultas subsequentes para o mesmo certificado devem retornar a cadeia do cache, se ainda válida.
6 Retorno da cadeia
- Retorne o array de certificados conforme especificação acima.
Observações
- O serviço não realiza validação de revogação (OCSP/CRL) nesta etapa; a verificação de revogação é responsabilidade do processo de assinatura ou validação.
- O cache deve ser invalidado automaticamente ao expirar o TTL. Recomenda-se persistência local segura para evitar reconstrução desnecessária.
- O processo é determinístico para um mesmo certificado e trust store, salvo alterações em repositórios públicos ou expiracão de certificados intermediários.
- Registros de auditoria devem ser realizados conforme caso de uso de auditoria.
- Nota sobre trust store: Este caso de uso utiliza o trust store gerenciado pelo caso de uso de gerenciamento de trust store. O trust store deve estar disponível localmente antes da execução deste processo.
