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: