Autenticação SSL

Autenticação SSL

Como um ponto importante da segurança da informação entre consumidor e servidor Webservice, a autenticação serve como uma forma de assegurar que o consumidor do serviço, quem envia as informações ao webservice, é realmente a empresa que deseja escriturar, e que a conexão é segura e privada.

Requisitos para autenticação

Para poder realizar o processo de autenticação, é necessário que possuir um certificado eCNPJ válido, assinado por uma empresa autorizada pela ICP-Brasil.

No Brasil, todas as empresas emissoras de certificados devem ser previamente autorizadas pela Autoridade Certificadora Raiz. Apenas certificados que possuam o topo da cadeia de autorização como ICP-Brasil serão aceitos.

Entre as empresas autorizadas ACRaiz estão:

  • Serpro
  • Caixa Econômica
  • Serasa Experian
  • Receita Federal
  • Certisign
  • Imprensa Oficial
  • AC-Jus
  • AC-Pr 
  • Casa da Moeda do Brasil

Além de ser autorizado por uma das instituições acima listadas, também é necessário que o certificado seja um eCNPJ, a diferença entre este e um certificado convencional é:

  • A permissão para uso como chave autenticadora
  • Campo OID 2.16.76.1.33 com o número do CNPJ da empresa

Processo para autenticação

Ao enviar o certificado para autenticação, as seguintes validações são feitas em dois processos:

Primeiro Processo

  • O dia da autenticação é válida para a data de validade do certificado
  • Chave de assinatura pública é autorizada para o certificado em questão
  • Topo da cadeia de autorização é a ICP-Brasil
  • Se o certificado possui autorização para ser usado como chave autenticadora
  • Se o certificado possui o OID com uma numeração
  • Se todos os certificados da cadeia de autorização atende todos os 5 requisitos acima

Segundo Processo

Uma vez realizada estas seis etapas, o certificado é encaminhado a nossa aplicação para as seguintes validações:

  • Se o número informado no OID 2.16.76.1.33 é um CNPJ válido.
  • Se o CNPJ é de um contribuinte autorizado pela prefeitura em questão, ou se o certificado é de terceiros autorizado pelo contribuinte e pela prefeitura.
  • Se o cadastro do contribuinte em questão está ativo.
  • Se o cadastro do contribuinte em questão possui autorização para emissão de NFSe.

Caso o certificado passe por todo o processo de autenticação, a mensagem é encaminhada a aplicação para validação e processamento. Caso a o processo de autenticação falhe em algum ponto, duas situações distintas podem acontecer:

  • Caso o certificado seja barrado por um motivo do primeiro processo, a requisição será sumariamente rejeitada, e será repassado ao cliente consumidor o status de conexão recusada (erro HTTP 400). Como solução para este estágio, é preciso verificar a lista de validações e confirmar se foram atentidos todos os requisitos necessários.
  • Caso o certificado seja barrado por um motivo do segundo processo, a requisição será aceita (HTTP 200) porém, o conteúdo da resposta será um erro descrito com mais informações sobre a razão do erro. Os códigos possíveis são:
    • S02 - Emissor de certificado não autorizado 
    • S03 - Certificado expirado 
    • S04 - Certificado não autorizado como transmissor 
    • S05 - Certificado não autorizado como emissor 
    • S06 - Não foi possível interpretar o certificado 
    • S07 - Certificado inválido 
    • S09 - Certificado e informações no XML não coincidem. 
    • S13 - Contribuinte não identificado 
    • S14 - Contribuinte ainda não autorizado 
    • S15 - Contribuinte não autorizado a emitir NFSe

Detalhes técnicos

Para enviar o certificado como chave de autenticação, é necessário se utilizar de uma biblioteca que ofereça suporte a tal funcionalidade, entre as bibliotecas mais populares sobre o assunto está a OpenSSL, biblioteca gratuita e de código fonte aberto facilmente implementável em qualquer estrutura ou framework.

O certificado deverá ser utilizado no momento do estabelecimento da conexão, e em grande maioria das bibliotecas é necessário que se tenha disponível:

  • o certificado em arquivo no formato PEM ou formato DER
  • a chave privada do certificado
  • os certificados da hierarquia até a ICP-Brasil no formato PEM ou formato DER

Certificado no formato PEM ou formato DER

O formato DER constitui o certificado disposto dentro de um arquivo binário, geralmente com extensão .cer, .der ou .crt. Para fins de transmissão, este formato não é o recomendável, por não ser otimizado e possuir sequências de caracteres impróprios para o cabeçalho do protocolo HTTP.

O formato PEM constitui o certificado disposto dentro de um arquivo de texto convencional, geralmente com a extensão .pem, e dentro dele, uma string no formato Base64 contendo 61 caracteres por linha, dispostas na quantidade de linhas necessárias, neste formato também é necessário que a string tenha em seu começo “-----BEGIN CERTIFICATE-----” e no final da string “-----END CERTIFICATE-----”. Este é o formato mais apropriado para transmissão, e em grande maioria das bibliotecas, caso o arquivo seja informado no formato DER, é feita a tradução para o formato PEM para depois realizar a transmissão.

Certificados de hierarquia

Todos certificados emitidos possuem em suas informações, o nome da instituição ou do proprietário responsável por assiná-lo, e assim sucessivamente até o topo da cadeia, no caso de certificados emitidos aqui no Brasil, a ICP-Brasil.

Para poder realizar a autenticação é necessário que todos os estágios até o topo da cadeia esteja presente. Estes certificados devem estar no formato PEM ou no formato DER e devem ser informados a biblioteca no momento da conexão, ou configurados previamente para que possam ser acessados.

Para fins de organização, é recomendável que cada arquivo esteja disposto em um arquivo individual, porém algumas bibliotecas requisitam que os arquivos estejam em um único arquivo concatenado sequencialmente. Caso isso seja requisitado, é necessário que estes certificados estejam ordenados corretamente, uma inversão ou sequenciamento incorreto torna a cadeia inválida.

Caso válido:

  1. Cliente Consumidor
  2. Filial da empresa X
  3. Matriz da empresa X 
  4. Serpro Filial
  5. Sepro Matriz
  6. ICP Brasil

Caso inválido:

  1. Cliente Consumidor
  2. ICP Brasil
  3. Sepro Filial
  4. Sepro Matriz
  5. Filial da empresa X
  6. Matriz da empresa X

Documentação de Ajuda

Como informação auxiliar, segue alguns endereços com mais informações sobre o assunto, ou com algumas ferramentas que podem auxiliar.

Em português

  1. Utilizando certificados digitais para autenticação de usuários (MSDN) 
  2. Uso de eCPF e eCNPJ para autenticação (MSDN)
  3. Como chamar um webservice utilizando um certificado (Microsoft Support)
  4. Autenticação de usuários com certificados digitais (Java)
  5. Webservice com certificação digital (Java)
  6. Autenticação SOAP utilizando certificado (PHP)

Em inglês

  1. OpenSSL Documentation
  2. OpenSSL Common Commands
  3. OpenSSL FAQ
  4. OpenSC Project - Authentication with x509 certificates
  5. Survival Guide - SSL / TLS and x509 Certificates
  6. Java - Using SSL Authentication in Java Clients
Tem mais dúvidas? Envie uma solicitação

0 Comentários

Por favor, entre para comentar.
Powered by Zendesk