Certificado de chave pública - Public key certificate

Certificado de chave pública de * .comifuro.net, emitido por Let's Encrypt

Na criptografia , um certificado de chave pública , também conhecido como certificado digital ou certificado de identidade , é um documento eletrônico usado para provar a propriedade de uma chave pública . O certificado inclui informações sobre a chave, informações sobre a identidade de seu proprietário (chamado de assunto) e a assinatura digital de uma entidade que verificou o conteúdo do certificado (chamado de emissor). Se a assinatura for válida e o software que examina o certificado confiar no emissor, ele poderá usar essa chave para se comunicar com segurança com o assunto do certificado. Em criptografia de e-mail , assinatura de código e sistemas de assinatura eletrônica, o assunto de um certificado é normalmente uma pessoa ou organização. No entanto, no Transport Layer Security (TLS), o assunto de um certificado é normalmente um computador ou outro dispositivo, embora os certificados TLS possam identificar organizações ou indivíduos, além de sua função principal na identificação de dispositivos. O TLS, às vezes chamado por seu nome antigo Secure Sockets Layer (SSL), é notável por fazer parte do HTTPS , um protocolo para navegar com segurança na web .

Em um esquema típico de infraestrutura de chave pública (PKI), o emissor do certificado é uma autoridade de certificação (CA), geralmente uma empresa que cobra dos clientes a emissão de certificados para eles. Em contraste, em um esquema de rede de confiança , os indivíduos assinam as chaves uns dos outros diretamente, em um formato que desempenha uma função semelhante a um certificado de chave pública.

O formato mais comum para certificados de chave pública é definido por X.509 . Como o X.509 é muito geral, o formato é ainda mais restrito por perfis definidos para certos casos de uso, como Public Key Infrastructure (X.509) conforme definido no RFC  5280 .

Tipos de certificado

As funções de certificado raiz, certificado intermediário e certificado de entidade final como na cadeia de confiança .

Certificado de servidor TLS / SSL

No TLS (uma substituição atualizada do SSL), um servidor é necessário para apresentar um certificado como parte da configuração da conexão inicial. Um cliente se conectando a esse servidor executará o algoritmo de validação do caminho de certificação :

  1. O assunto do certificado corresponde ao nome do host (ou seja, nome do domínio) ao qual o cliente está tentando se conectar;
  2. O certificado é assinado por uma autoridade de certificação confiável.

O nome do host principal ( nome de domínio do site) é listado como o nome comum no campo Assunto do certificado. Um certificado pode ser válido para vários nomes de host (vários sites). Esses certificados são comumente chamados de certificados de Nome Alternativo do Assunto (SAN) ou Certificados de Comunicações Unificadas (UCC) . Esses certificados contêm o campo Nome alternativo do assunto , embora muitas CAs também os coloquem no campo Nome comum do assunto para compatibilidade com versões anteriores. Se alguns dos nomes de host contiverem um asterisco (*), um certificado também pode ser chamado de certificado curinga .

Um servidor TLS pode ser configurado com um certificado autoassinado. Quando for esse o caso, os clientes geralmente não conseguirão verificar o certificado e encerrarão a conexão, a menos que a verificação do certificado seja desabilitada.

De acordo com os aplicativos, os certificados SSL podem ser classificados em três tipos:

  • SSL de validação de domínio;
  • SSL de validação da organização;
  • SSL de validação estendida.

Certificado de cliente TLS / SSL

Os certificados do cliente são menos comuns do que os certificados do servidor e são usados ​​para autenticar o cliente que se conecta a um serviço TLS, por exemplo, para fornecer controle de acesso. Como a maioria dos serviços fornece acesso a indivíduos, em vez de dispositivos, a maioria dos certificados de cliente contém um endereço de e-mail ou nome pessoal em vez de um nome de host. Além disso, como a autenticação geralmente é gerenciada pelo provedor de serviços, os certificados de cliente geralmente não são emitidos por uma CA pública que fornece certificados de servidor. Em vez disso, a operadora de um serviço que requer certificados de cliente geralmente operará sua própria CA interna para emiti-los. Certificados de cliente são suportados por muitos navegadores da web, mas a maioria dos serviços usa senhas e cookies para autenticar usuários, em vez de certificados de cliente.

Os certificados de cliente são mais comuns em sistemas RPC , onde são usados ​​para autenticar dispositivos para garantir que apenas dispositivos autorizados possam fazer certas chamadas RPC.

Certificado de email

No protocolo S / MIME para e-mail seguro, os remetentes precisam descobrir qual chave pública usar para um determinado destinatário. Eles obtêm essas informações de um certificado de e-mail. Algumas autoridades de certificação confiáveis ​​publicamente fornecem certificados de e-mail, mas mais comumente S / MIME é usado ao se comunicar dentro de uma determinada organização, e essa organização executa sua própria CA, que é confiável para os participantes desse sistema de e-mail.

Certificado EMV

Os cartões de pagamento EMV são pré-carregados com um certificado do emissor do cartão, assinado pela autoridade de certificação EMV para validar a autenticidade do cartão de pagamento durante a transação de pagamento. O certificado EMV CA é carregado em terminais de cartão ATM ou POS e é usado para validar o certificado do emissor do cartão.

Certificado de assinatura de código

Os certificados também podem ser usados ​​para validar assinaturas em programas para garantir que não foram violados durante a entrega.

Certificado qualificado

Um certificado que identifica um indivíduo, normalmente para fins de assinatura eletrônica . Estes são mais comumente usados ​​na Europa, onde o regulamento eIDAS os padroniza e exige o seu reconhecimento.

Certificado raiz

Um certificado autoassinado usado para assinar outros certificados. Também chamada de âncora de confiança ou raiz de confiança .

Certificado intermediário

Um certificado usado para assinar outros certificados. Um certificado intermediário deve ser assinado por outro certificado intermediário ou um certificado raiz.

Entidade final ou certificado folha

Qualquer certificado que não pode ser usado para assinar outros certificados. Por exemplo, certificados de servidor e cliente TLS / SSL, certificados de e-mail, certificados de assinatura de código e certificados qualificados são todos certificados de entidade final.

Certificado baseado em função

Definido na Política de Certificação X.509 para a Autoridade de Certificação Federal Bridge, os Certificados com base em funções "identificam uma função específica em nome da qual o assinante está autorizado a agir, em vez do nome do assinante e são emitidos no interesse de apoiar práticas comerciais aceitas . "

Certificado de Grupo

Definido na Política de Certificação X.509 para a Autoridade de Certificação Federal Bridge, para "casos em que há várias entidades atuando em uma capacidade e onde o não repúdio para transações não é desejado."

Certificado autoassinado

Um certificado com um assunto que corresponde ao seu emissor e uma assinatura que pode ser verificada por sua própria chave pública. A maioria dos tipos de certificado pode ser autoassinada. Certificados autoassinados também são chamados de certificados de óleo de cobra para enfatizar sua falta de confiança.

Campos comuns

Esses são alguns dos campos mais comuns em certificados. A maioria dos certificados contém vários campos não listados aqui. Observe que, em termos de representação X.509 de um certificado, um certificado não é "plano", mas contém esses campos aninhados em várias estruturas dentro do certificado.

  • Número de série : usado para identificar exclusivamente o certificado nos sistemas de uma CA. Em particular, isso é usado para rastrear informações de revogação.
  • Assunto : a entidade a que pertence um certificado: uma máquina, um indivíduo ou uma organização.
  • Emissor : a entidade que verificou as informações e assinou o certificado.
  • Antes : A primeira hora e data em que o certificado é válido. Normalmente definido para algumas horas ou dias antes do momento em que o certificado foi emitido, para evitar problemas de distorção do relógio .
  • Não depois : a hora e a data após as quais o certificado não é mais válido.
  • Uso da chave : os usos criptográficos válidos da chave pública do certificado. Os valores comuns incluem validação de assinatura digital, codificação de chave e assinatura de certificado.
  • Uso estendido de chave : os aplicativos nos quais o certificado pode ser usado. Os valores comuns incluem autenticação de servidor TLS, proteção de e-mail e assinatura de código.
  • Chave pública : uma chave pública pertencente ao assunto do certificado.
  • Algoritmo de assinatura : contém um algoritmo de hash e um algoritmo de criptografia. Por exemplo, "sha256RSA", em que sha256 é o algoritmo de hash e RSA é o algoritmo de criptografia.
  • Assinatura : O corpo do certificado é hash (o algoritmo de hash no campo "Algoritmo de assinatura" é usado) e o hash é criptografado (o algoritmo de criptografia no campo "Algoritmo de assinatura" é usado) com a chave privada do emissor.

Certificado de amostra

Este é um exemplo de certificado SSL / TLS decodificado recuperado do site SSL.com. O nome comum (CN) do emissor é mostrado como SSL.com EV SSL Intermediate CA RSA R3, identificando-o como um certificado de validação estendida (EV). As informações validadas sobre o proprietário do site (SSL Corp) estão localizadas no Subjectcampo. O X509v3 Subject Alternative Namecampo contém uma lista de nomes de domínio cobertos pelo certificado. Os campos X509v3 Extended Key Usagee X509v3 Key Usagemostram todos os usos apropriados.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3
        Validity
            Not Before: Apr 18 22:15:06 2019 GMT
            Not After : Apr 17 22:15:06 2021 GMT
        Subject: C=US, ST=Texas, L=Houston, O=SSL Corp/serialNumber=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Private Organization/street=3100 Richmond Ave/jurisdictionST=Nevada/jurisdictionC=US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:ad:0f:ef:c1:97:5a:9b:d8:1e ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD

            Authority Information Access: 
                CA Issuers - URI:http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt
                OCSP - URI:http://ocsps.ssl.com

            X509v3 Subject Alternative Name: 
                DNS:www.ssl.com, DNS:answers.ssl.com, DNS:faq.ssl.com, DNS:info.ssl.com, DNS:links.ssl.com, DNS:reseller.ssl.com, DNS:secure.ssl.com, DNS:ssl.com, DNS:support.ssl.com, DNS:sws.ssl.com, DNS:tools.ssl.com
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.1
                Policy: 1.2.616.1.113527.2.5.1.1
                Policy: 1.3.6.1.4.1.38064.1.1.1.5
                  CPS: https://www.ssl.com/repository

            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl

            X509v3 Subject Key Identifier: 
                E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 87:75:BF:E7:59:7C:F8:8C:43:99 ...
                    Timestamp : Apr 18 22:25:08.574 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:40:51:53:90:C6:A2 ...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB ...
                    Timestamp : Apr 18 22:25:08.461 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:43:80:9E:19:90:FD ...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 55:81:D4:C2:16:90:36:01:4A:EA ...
                    Timestamp : Apr 18 22:25:08.769 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:C1:3E:9F:F0:40 ...
    Signature Algorithm: sha256WithRSAEncryption
         36:07:e7:3b:b7:45:97:ca:4d:6c ...

Uso na União Europeia

Na União Europeia, as assinaturas eletrônicas (avançadas) em documentos jurídicos são comumente executadas usando assinaturas digitais com certificados de identidade que os acompanham. No entanto, apenas assinaturas eletrônicas qualificadas (que requerem o uso de um provedor de serviços de confiança qualificado e um dispositivo de criação de assinatura) recebem o mesmo poder que uma assinatura física.

Autoridades de certificação

O procedimento de obtenção de um certificado de chave pública

No modelo de confiança X.509 , uma autoridade de certificação (CA) é responsável por assinar certificados. Esses certificados atuam como uma introdução entre duas partes, o que significa que uma CA atua como um terceiro confiável. Uma CA processa solicitações de pessoas ou organizações que solicitam certificados (chamados de assinantes), verifica as informações e, potencialmente, assina um certificado de entidade final com base nessas informações. Para desempenhar essa função com eficácia, uma CA precisa ter um ou mais certificados raiz amplamente confiáveis ​​ou certificados intermediários e as chaves privadas correspondentes. As CAs podem alcançar essa ampla confiança tendo seus certificados raiz incluídos em softwares populares ou obtendo uma assinatura cruzada de outra CA que delegue confiança. Outras CAs são confiáveis ​​em uma comunidade relativamente pequena, como uma empresa, e são distribuídas por outros mecanismos, como a Diretiva de Grupo do Windows .

As autoridades de certificação também são responsáveis ​​por manter as informações de revogação atualizadas sobre os certificados que emitiram, indicando se os certificados ainda são válidos. Eles fornecem essas informações por meio do Protocolo de Status de Certificado Online (OCSP) e / ou Listas de Revogação de Certificado (CRLs). Algumas das maiores autoridades de certificação do mercado incluem IdenTrust , DigiCert e Sectigo .

Programas raiz

Alguns softwares importantes contêm uma lista de autoridades de certificação confiáveis ​​por padrão. Isso torna mais fácil para os usuários finais validar certificados e mais fácil para pessoas ou organizações que solicitam certificados saber quais autoridades de certificação podem emitir um certificado que será amplamente confiável. Isso é particularmente importante em HTTPS, onde um operador de site geralmente deseja obter um certificado que seja confiável para quase todos os visitantes em potencial de seu site.

As políticas e processos que um provedor usa para decidir em quais autoridades de certificação seu software deve confiar são chamados de programas raiz. Os programas raiz mais influentes são:

Navegadores diferentes do Firefox geralmente usam os recursos do sistema operacional para decidir quais autoridades de certificação são confiáveis. Assim, por exemplo, o Chrome no Windows confia nas autoridades de certificação incluídas no Microsoft Root Program, enquanto no macOS ou iOS, o Chrome confia nas autoridades de certificação no Apple Root Program. O Edge e o Safari também usam seus respectivos armazenamentos confiáveis ​​de sistema operacional, mas cada um está disponível apenas em um único sistema operacional. O Firefox usa o armazenamento confiável do Mozilla Root Program em todas as plataformas.

O Mozilla Root Program é operado publicamente e sua lista de certificados é parte do navegador de código aberto Firefox, por isso é amplamente usado fora do Firefox. Por exemplo, embora não haja um programa Linux Root comum, muitas distribuições Linux, como o Debian, incluem um pacote que copia periodicamente o conteúdo da lista confiável do Firefox, que é então usado pelos aplicativos.

Os programas raiz geralmente fornecem um conjunto de finalidades válidas com os certificados que incluem. Por exemplo, algumas CAs podem ser consideradas confiáveis ​​para a emissão de certificados de servidor TLS, mas não para certificados de assinatura de código. Isso é indicado com um conjunto de bits de confiança em um sistema de armazenamento de certificado raiz.

Certificados e segurança do site

O uso mais comum de certificados é para sites baseados em HTTPS . Um navegador da web valida que um servidor HTTPS da web é autêntico, para que o usuário possa se sentir seguro de que sua interação com o site não tem intrusos e que o site é quem afirma ser. Essa segurança é importante para o comércio eletrônico . Na prática, um operador de site obtém um certificado solicitando a uma autoridade de certificação uma solicitação de assinatura de certificado . A solicitação de certificado é um documento eletrônico que contém o nome do site, informações da empresa e a chave pública. O fornecedor do certificado assina a solicitação, produzindo assim um certificado público. Durante a navegação na web, este certificado público é servido a qualquer navegador da web que se conecta ao site e prova ao navegador que o provedor acredita ter emitido um certificado para o proprietário do site.

Por exemplo, quando um usuário se conecta a https://www.example.com/com seu navegador, se o navegador não fornecer nenhuma mensagem de aviso de certificado, o usuário pode estar teoricamente certo de que interagir com https://www.example.com/é equivalente a interagir com a entidade em contato com o endereço de e-mail listado no registrador público em "example.com", embora esse endereço de e-mail não possa ser exibido em nenhum lugar do site. Nenhuma outra garantia de qualquer tipo está implícita. Além disso, a relação entre o comprador do certificado, o operador do site e o gerador do conteúdo do site pode ser tênue e não é garantida. Na melhor das hipóteses, o certificado garante a exclusividade do site, desde que o próprio site não tenha sido comprometido (hackeado) ou o processo de emissão do certificado subvertido.

Um provedor de certificados pode optar por emitir três tipos de certificados, cada um exigindo seu próprio grau de rigor de verificação. Por ordem crescente de rigor (e naturalmente, custo) são eles: Validação de Domínio, Validação de Organização e Validação Estendida. Esses rigores são vagamente aceitos pelos participantes voluntários no Fórum CA / Navegador .

Níveis de validação

Validação de domínio

Um provedor de certificado emitirá um certificado validado por domínio (DV) para um comprador se o comprador puder demonstrar um critério de verificação: o direito de gerenciar administrativamente o (s) domínio (s) DNS afetado (s).

Validação da organização

Um provedor de certificado emitirá um certificado de classe de validação de organização (OV) para um comprador se o comprador puder atender a dois critérios: o direito de gerenciar administrativamente o nome de domínio em questão e, talvez, a existência real da organização como uma entidade legal. Um provedor de certificado publica seus critérios de verificação OV por meio de sua política de certificado .

Validação estendida

Para adquirir um certificado de validação estendida (EV), o comprador deve persuadir o fornecedor do certificado de sua identidade legal, incluindo verificações manuais por um ser humano. Assim como acontece com os certificados OV, um provedor de certificados publica seus critérios de verificação de EV por meio de sua política de certificados .

Até 2019, os principais navegadores, como Chrome e Firefox, geralmente ofereciam aos usuários uma indicação visual da identidade legal quando um site apresentava um certificado EV. Isso foi feito mostrando o nome legal antes do domínio e uma cor verde brilhante para destacar a alteração. A maioria dos navegadores desaprovou esse recurso, não fornecendo nenhuma diferença visual para o usuário no tipo de certificado usado. Essa mudança ocorreu após preocupações de segurança levantadas por especialistas forenses e tentativas bem-sucedidas de adquirir certificados EV para se passar por organizações famosas, provando a ineficiência desses indicadores visuais e destacando possíveis abusos.

Fraquezas

Um navegador da web não avisará o usuário se um site da web apresentar repentinamente um certificado diferente, mesmo se esse certificado tiver um número menor de bits de chave, mesmo se tiver um provedor diferente, e mesmo se o certificado anterior tiver uma data de expiração longe no futuro. Quando os provedores de certificados estão sob a jurisdição de governos, esses governos podem ter a liberdade de ordenar que o provedor gere qualquer certificado, como para fins de aplicação da lei. Os fornecedores subsidiários de certificados por atacado também têm a liberdade de gerar qualquer certificado.

Todos os navegadores da web vêm com uma extensa lista integrada de certificados raiz confiáveis , muitos dos quais são controlados por organizações que podem não ser familiares para o usuário. Cada uma dessas organizações é livre para emitir qualquer certificado para qualquer site da web e tem a garantia de que os navegadores da web que incluem seus certificados raiz o aceitarão como genuíno. Nesse caso, os usuários finais devem confiar no desenvolvedor do software do navegador para gerenciar sua lista interna de certificados e nos provedores de certificados para se comportar corretamente e informar o desenvolvedor do navegador sobre certificados problemáticos. Embora incomum, houve incidentes em que certificados fraudulentos foram emitidos: em alguns casos, os navegadores detectaram a fraude; em outros, algum tempo se passou antes que os desenvolvedores de navegador removessem esses certificados de seu software.

A lista de certificados integrados também não se limita àqueles fornecidos pelo desenvolvedor do navegador: os usuários (e até certo ponto os aplicativos) são livres para estender a lista para fins especiais, como intranets corporativas. Isso significa que se alguém obtiver acesso a uma máquina e puder instalar um novo certificado raiz no navegador, esse navegador reconhecerá os sites que usam o certificado inserido como legítimos.

Para comprovar a segurança , essa confiança em algo externo ao sistema tem a conseqüência de que qualquer esquema de certificação de chave pública deve se basear em alguma suposição de configuração especial, como a existência de uma autoridade de certificação .

Utilidade versus sites inseguros

Apesar das limitações descritas acima, o TLS com autenticação de certificado é considerado obrigatório por todas as diretrizes de segurança sempre que um site hospeda informações confidenciais ou realiza transações materiais. Isso ocorre porque, na prática, apesar dos pontos fracos descritos acima, os sites protegidos por certificados de chave pública ainda são mais seguros do que os sites http: // não protegidos .

Padrões

A Divisão de Segurança Informática do Instituto Nacional de Padrões e Tecnologia ( NIST ) fornece documentos de orientação para certificados de chave pública:

  • SP 800-32 Introdução à Tecnologia de Chave Pública e à Infraestrutura Federal de PKI
  • SP 800-25 Agência Federal de Uso de Tecnologia de Chave Pública para Assinaturas Digitais e Autenticação

Veja também

Referências