Introdução a Certificados

Certificados X509

Certificados X509 tem basicamente a função de permitir a navegação segura de protocolos de internet (como web, email, XMPP, VPN, etc). Certificados podem também garantir a segurança de documentos (via assinatura digital) e da comunicação de aplicativos que também ficam desconectados da internet (como entre microserviços).

Certificados também podem identificar a validade de usuários (ao invés de hosts), permitindo que os mesmos tenham a identidade confirmada (equivalente a um CPF digital). Ele basicamente opera segundo o padrão de chave pública e chave privada: A chave privada fica de posse do usuário ou servidor, e a pública pode ser distribuida a sistemas na internet ou carregada pelo cliente para garantir uma segura negociação de conexão entre o cliente e servidor.

De onde vem os certificados? eles podem ser emitidos por uma entidade certificadora credenciada (que chamamos de CA) ou eles podem ser gerados por você (neste caso chamados de certificados auto-assinados). Toda emissão de certificado passa por um criterioso processo de validação e emissão (conforme o tipo de certificado comprado) desta forma, quando um certificado é assinado por uma CA confiável, seu site, e-mail, etc nao emitirão qualquer alerta sobre a identidade do sistema que está acessando, pois ele validará a autenticidade de quem emitiu e do certificado.

Validade de Certificados

Existe uma camada adicional de segurança de certificados, que identificam o período que ele é válido: O certificado permite uma data inicial e final de validade. É claro que o padrão assume que falhas de sistemas e humanas podem ocorrer, e por isso foi criado um certificado especial, agregado ao principal chamado de Lista de Revogação de Certificados (CRL).

CA Intermediária

Uma CA intermediária, é basicamente um certificado criado pelo certificado raíz, que pode criar novos certificados. A validação é feita usando uma cadeia de validação de confiança.

OBS - A versão 3 do X509 suportar estruturas de autenticação da cadeia de confiança, como bridges e mesh.

Como é gerado um Certificado assinado por CA?

Quando acessa sites como o Página Oficial do guia Foca GNU/Linux pelo seu navegador, provavelmente observará que é mostrado um cadeado ao lado da URL, e não é emitido qualquer alerta sobre a confiança do certificado. Esse cadeado indica que o site foi autenticado por uma CA válida (como CertSign, AlphaSSL, LetsEncript), e está dentro da validade. Mas qual é o passo a passo para que isso aconteça?

  1. A primeira etapa é gerar um par de chaves, que ficará em sua posse. A partir dessas chaves, emitiremos um tipo especial de certificado, chamado de Requisição de Assinatura de Certificado (CSR - Certificate signing request).

  2. Após isso, o CSR deverá ser enviado para a entidade certificadora escolhida. A CSR contém os dados pessoais do requerente preenchidos no certificados e o subject (domínio) que o certificado protegerá. Após a validação e comprovação de autenticidade dos dados, a CA lhe enviará o certificado assinado pela chave privada da CA, com um prazo de validade determinado.

  3. O certificado assinado então será instalado no servidor web, garantindo o acesso seguro a clientes que estão fazendo acesso ao mesmo

Tipos de certificados e suas extensões

Os tipos mais comuns e extensões de certificados seguem abaixo:

  • .pem – É um dos mais comuns, e geralmente começam com "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----". O PEM (Privacy-enhanced Electronic Mail) Basicamente é um certificado DER com encode Base64.

  • .cer, .crt, .der – Geralmente em formato DER binário, mas também usando Base64 como encoder are common too (see .pem above)

  • .p7b, .p7c – Dados estruturados e assinados PKCS#7 sem dados, apenas certificados ou CRLs.

  • .p12 – O PKCS#12, poder conter certificados público ou privados e chaves (protegidos por senha).

  • .pfx – Veio antes do PKCS#12 (geralmente contém dados no formato PKCS#12, geralmente usado no IIS.

A estrutura básica de um certificado?

Um certificado X509 padrão possui a seguinte estrutura:

    Certificate
        Version Number
        Serial Number
        Signature Algorithm ID
        Issuer Name
        Validity period
            Not Before
            Not After
        Subject name
        Subject Public Key Info
            Public Key Algorithm
            Subject Public Key
        Issuer Unique Identifier (optional)
        Subject Unique Identifier (optional)
        Extensions (optional)
            ...
    Certificate Signature Algorithm
    Certificate Signature
Entre os campos acima, os mais importantes são:
  • Issuer Name - Nome da CA que emitiu o certificado

  • Subject - Endereço solicitante do certificado

  • Validity - Validade do certificado. O Not Before impede que o certificado seja usado antes da data determinada. O Not After impede que ele seja usado após a data determinada.

  • Extensions - Estrutura documentada na RFC 1422, indicando que extensões podem ser usadas, geralmente contémum conjunto de valores que são classificados como criticos ou não-criticos. Caso seja encontrado uma extensão crítica faltando, o processamento será finalizado. Erros não-críticos podem ser ignorados se não forem reconhecidos (mesmo assim são processados como válidos).

Extensões para uso em certificados

Basicamente as extensões do SSLv3 são divididos em:

  • Politicas Básicas - São usados para indicar se o certificado pertemce a uma CA

  • Uso da Chave - Prove a especificação de operações de criptografia que podem ser feitas usando a chave pública contida no certificado: por exemplo, pode indicar que a chave pode ser usads para assinatura mas não para criptografia.

  • Uso de chave Extendido - É usado tipicamente nos últimos certificados emitidos na cadeia, para indicar o propósito de uma chave ocntendo o certificado.

O RFC 5280 traz detalhes e exemplos específicos do certificado contendo ambos keyUsage e extendedKeyUsage.