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.
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).
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.
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?
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).
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.
O certificado assinado então será instalado no servidor web, garantindo o acesso seguro a clientes que estão fazendo acesso ao mesmo
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.
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).
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.
Copyright © 1999-2020 - Gleydson Mazioli da Silva