v1.0.0 Diretrizes para validação de certificados digitais no Open Finance Brasil

1. Objetivo

Esta página estabelece os requisitos mínimos para adoção de mecanismos de verificação da validade dos certificados digitais utilizados pelos participantes do Open Finance Brasil, em consonância com a regulamentação vigente e com o Manual de Segurança do Open Finance. Esses requisitos devem assegurar segurança, continuidade operacional e resiliência na validação de certificados digitais.

Nota
A introdução expressa desses requisitos no Manual de Segurança ocorreu com a IN BCB nº 720, de 2 de abril de 2026, que divulgou a versão 5.0 do manual e definiu vigência específica, a partir de 3 de novembro de 2026, para os itens 3.28 a 3.30 e 6.18.

2. Contexto

Os participantes do Open Finance Brasil são responsáveis por consumir e expor APIs protegidas por mutual TLS (mTLS), utilizando certificados digitais emitidos por autoridades certificadoras homologadas para o ecossistema.

Essas obrigações se aplicam sempre que o participante atuar em conexões mTLS no âmbito do Open Finance, seja no papel de cliente (consumindo APIs de outros participantes), seja no papel de servidor (expondo APIs a outros participantes). Em ambos os casos, a forma como a instituição valida e trata certificados digitais tem impacto direto na estabilidade, na segurança e na disponibilidade do ecossistema como um todo.

Durante o handshake mTLS, tanto o servidor quanto o cliente podem verificar o status de revogação dos certificados apresentados, recorrendo a serviços de OCSP e/ou LCR disponibilizados pelas autoridades certificadoras. Quando esses serviços sofrem instabilidade, a validação on-line pode falhar; se cliente ou servidor não possuírem mecanismos de contingência, o handshake pode ser interrompido, gerando indisponibilidade entre instituições.

Embora as ACs operem os serviços de validação (OCSP e LCR), a continuidade das jornadas de negócio e a experiência dos clientes finais dependem diretamente da forma como cada participante implementa sua arquitetura de validação e seus mecanismos de resiliência.

Esta página descreve as obrigações dos participantes em relação a:

• Uso e validação de certificados digitais;

• Implementação de mecanismos de fallback e resiliência;

• Monitoramento e gestão de incidentes relacionados à validação.

3. Escopo

Estes parâmetros aplicam-se às instituições participantes do Open Finance sempre que utilizarem certificados digitais para assinatura de mensagens e comunicação segura com APIs usadas para os compartilhamentos de dados e de serviços no âmbito do Open Finance, observadas as exceções previstas no Manual de Segurança.

Aplicam-se tanto às instituições atuando no papel de cliente quanto no papel de servidor em conexões mTLS.

4. Diretrizes Gerais

A seleção e a implementação dos mecanismos de verificação de validade de certificados devem observar os seguintes princípios:

• Segurança: Não aceitar, de forma inadvertida, certificados inválidos ou revogados nos fluxos mTLS, tanto ao consumir quanto ao expor APIs.

• Resiliência: Minimizar o impacto de falhas temporárias dos serviços das ACs (OCSP/LCR) sobre as APIs de negócio, por meio de mecanismos de fallback e desenho arquitetural adequado.

• Proporcionalidade: Adotar mecanismos de validação compatíveis com o risco das jornadas e com a arquitetura do participante, sem comprometer segurança e continuidade operacional.

• Demonstrabilidade: Ser capaz de demonstrar às instâncias competentes da governança do Open Finance e ao Banco Central que a solução adotada é funcional, resiliente e aderente às orientações do ecossistema.

A conformidade com os SLAs de disponibilidade das APIs é responsabilidade da instituição participante. Por esse motivo, indisponibilidades temporárias dos serviços das autoridades certificadoras não isentam a instituição participante da obrigação de manter arquitetura de validação intrinsecamente resiliente.

5. Mecanismo Primário de Validação de Certificados

Cada participante deve definir e implementar um mecanismo primário de validação de certificados, que pode incluir, entre outros:

• consulta direta a serviços OCSP das autoridades certificadoras;

• uso de LCR providas pelas autoridades certificadoras;

• recursos nativos de HSMs, appliances de segurança, proxies de mTLS ou gateways de API que encapsulem a lógica de validação.

Não é imposto um único modelo obrigatório de validação para todos os participantes. Essa flexibilidade é importante para evitar:

• customizações arriscadas em componentes críticos de segurança;

• incompatibilidade com ferramentas amplamente utilizadas no mercado;

• custos e complexidade desproporcionais em relação ao benefício marginal.

Contudo, a ausência de modelo único não elimina a obrigação de resiliência.

6. Obrigatoriedade de Mecanismos de Fallback (Resiliência)

Independentemente do mecanismo primário escolhido, cada participante é responsável por garantir mecanismos de resiliência em caso de falhas ou degradação dos serviços de validação das autoridades certificadoras.

No Open Finance Brasil, a conformidade com os SLAs de disponibilidade das APIs é responsabilidade de cada participante. Por esse motivo, indisponibilidades temporárias ou eventuais dos serviços de revogação disponibilizados pelas autoridades certificadoras — como OCSP, LCR/CRL ou equivalentes — não isentam o participante do cumprimento das métricas de disponibilidade exigidas pelo ecossistema e não podem ser utilizadas como justificativa para a indisponibilidade da API de negócio.

Cada participante deve implementar e manter arquitetura de validação intrinsecamente resiliente a falhas de componentes individuais, como indisponibilidade temporária de OCSP, devendo ainda monitorar continuamente disponibilidade, latência, taxa de erro e capacidade dos mecanismos adotados e implementar mecanismos de continuidade (fallback) que assegurem a operação das APIs durante indisponibilidades do serviço primário.

São considerados mecanismos aderentes, utilizados isoladamente ou em combinação:

6.1 Verificação via LCR (CRL)

Uso da LCR como fonte complementar ou alternativa de informação de revogação quando o mecanismo primário estiver indisponível ou instável.

A verificação via LCR consiste em processo robusto de download e checagem de listas de certificados revogados, com validação offline e alta disponibilidade. Como a LCR é publicada com frequência mínima regulada pelo ITI, o participante pode manter cópias locais atualizadas para reduzir a dependência de consultas externas em tempo real.

6.2 OCSP Stapling

Utilização de OCSP Stapling, quando suportado pela pilha tecnológica, para reduzir a dependência de consultas em tempo real.

Quando a instituição receptora da conexão receber uma resposta OCSP stapled válida, íntegra, vigente, emitida por respondedor autorizado e compatível com o certificado apresentado, a decisão de aceitação do certificado não deve depender de nova consulta síncrona ao respondedor OCSP. A indisponibilidade de consulta online adicional não deve, por si só, motivar a rejeição da conexão durante o período de validade da resposta stapled.

6.3 Cache de respostas OCSP / informações de revogação

Armazenamento temporário, seguro e controlado de respostas válidas ou informações de revogação, respeitando sua validade e a estratégia de risco da instituição.

6.4 Soft-fail controlado

Adoção de critérios controlados de soft-fail em que a indisponibilidade temporária do provedor de validação não interrompe imediatamente todas as operações, desde que a instituição utilize resultados recentes e válidos de consultas anteriores ou mecanismos alternativos compatíveis com sua estratégia de risco.

6.5 Combinações síncronas ou assíncronas

Utilização combinada de OCSP, LCR, cache e outros mecanismos, de forma a garantir continuidade operacional sem comprometer os requisitos de segurança. Arquiteturas híbridas podem, por exemplo, utilizar OCSP como método primário, seguido de cache local e verificação via LCR como camada adicional de redundância.

Os requisitos operacionais mínimos aplicáveis a cada mecanismo, inclusive quanto à atualização das informações, tolerância a falhas e alternativa mínima esperada, estão consolidados na Tabela de Parâmetros Mínimos desta página.

7. Ordem de preferência para fallback

Recomenda-se que os participantes adotem mecanismos de fallback que reduzam a dependência direta de consultas OCSP on-line, priorizando soluções mais estáveis e previsíveis. Nesse contexto, a verificação via LCR deve ser tratada como o mecanismo preferencial de fallback.

Essa preferência decorre do fato de que:

• a LCR é publicada em frequência mínima regulada pelo ITI;

• o participante pode manter cópias locais atualizadas;

• a estratégia reduz dependência de chamadas externas em tempo real; e

• o modelo é mais previsível do ponto de vista operacional.

7.1 Quando o uso de LCR não for viável

Quando a instituição, por restrições técnicas ou operacionais, não conseguir utilizar LCR, recomenda-se a adoção, na seguinte ordem de prioridade:

1. OCSP Stapling + cache + soft-fail controlado;

2. outros processos híbridos baseados nos mecanismos aceitos pelo ecossistema.

7.2 Observação importante sobre OCSP Stapling

O uso isolado de OCSP Stapling melhora latência, privacidade e reduz parcialmente a dependência do respondedor OCSP, mas não resolve integralmente o problema de disponibilidade. Em cenários de indisponibilidade prolongada do serviço OCSP, as respostas stapled expiram; sem LCR, cache estruturado ou critérios de soft-fail bem definida, a instituição continua sujeita a falhas de handshake e interrupções de conectividade. Por isso, o OCSP Stapling não deve ser utilizado isoladamente como única estratégia de resiliência.

8. Tabela de Parâmetros Mínimos

A adoção do mecanismo primário e do mecanismo alternativo de verificação deve observar os requisitos mínimos desta tabela, em atendimento aos parâmetros de governança aplicáveis ao Manual de Segurança.

9. Monitoramento e Gestão de Incidentes pelo Participante

Os participantes devem estruturar o monitoramento e a resposta a incidentes relacionados à validação de certificados de forma compatível com o Manual de Monitoramento do Open Finance, inclusive quanto à necessidade de tratamento tempestivo de desconformidades identificadas no ecossistema.

Cada participante deve:

• monitorar os fluxos de validação de certificados em sua infraestrutura, incluindo falhas de conexão com serviços OCSP/LCR, aumento anormal de latência e taxas de erro acima dos padrões habituais;

• manter registros (logs) que permitam analisar falhas de handshake mTLS, erros de validação de certificados e acionamento de mecanismos de fallback;

• manter procedimentos internos de resposta a incidentes que permitam acionar rapidamente os mecanismos de contingência;

• iniciar tratativas com as autoridades certificadoras e seguir os fluxos de comunicação do ecossistema quando houver incidentes relevantes com potencial de impacto sistêmico.

10. Soluções Alternativas e Demonstração de Conformidade

Participantes que utilizem mecanismos de validação diferentes dos modelos aqui descritos devem:

• informar formalmente o método adotado à instância competente da governança do Open Finance;

• comprovar, por documentação técnica e, quando necessário, por evidências práticas, que:

  • o mecanismo é funcional;

  • garante resiliência adequada a falhas dos serviços das autoridades certificadoras;

  • atende aos objetivos de segurança, continuidade e integridade do Open Finance.

Essa flexibilidade permite acomodar inovações tecnológicas sem abrir mão de um nível mínimo de robustez e transparência.

11. Evidências Mínimas de Conformidade

Cada instituição participante deve ser capaz de demonstrar, no mínimo:

• o mecanismo primário adotado;

• o mecanismo alternativo adotado;

• os parâmetros de atualização das informações;

• os parâmetros de TTL, expiração e descarte de informações armazenadas em cache;

• os parâmetros de tolerância a falhas;

• os testes realizados para verificar o funcionamento do fallback;

• os registros de monitoramento e logs de incidentes relacionados à validação de certificados.

12. Conformidade e Evolução das Obrigações

As obrigações aqui descritas podem evoluir ao longo do tempo em função:

• de dados de monitoramento do ecossistema;

• de experiências com incidentes reais;

• da evolução tecnológica das soluções de segurança;

• de novos parâmetros e orientações publicados pela Estrutura de Governança com fundamento no item 6.18 do Manual de Segurança v5.

Essa evolução deve preservar o equilíbrio entre segurança, resiliência, proporcionalidade e viabilidade de implementação.