Documentação do Oracle Cloud Infrastructure

Definindo TLS/SSL com o OpenSSL

Abrange workflows do OpenSSL para gerar chaves, CSRs, certificados, CAs privadas e validar serviços TLS no Oracle Linux.

Use as ferramentas do OpenSSL disponíveis no Oracle Linux para criar CSRs (Certificate Signing Requests), certificados autoassinados e certificados de CA de propriedade privada. Os procedimentos também mostram como validar e testar certificados configurados para um protocolo para confirmar que os serviços estão configurados corretamente.

Recursos do Comando Openssl

Com o comando openssl, que é incluído no pacote openssl, você pode executar uma grande variedade de funções de criptografia na biblioteca OpenSSL, incluindo o seguinte:

  • Crie e gerencie pares de chaves privadas e públicas.

  • Executar operações criptográficas de chave pública.

  • Criar certificados autoassinados.

  • Criar solicitações de assinatura de certificado (CSRs).

  • Criar listas de revogação de certificados (CRLs).

  • Converta arquivos de certificado entre vários formatos.

  • Calcular resumos de mensagens.

  • Criptografar e descriptografar arquivos.

  • Teste o TLS/SSL do cliente e do servidor com servidores HTTP e SMTP.

  • Verificar, criptografar e assinar e-mail S/MIME.

  • Gere e teste números primos e gere dados pseudo aleatórios.

Sobre Pares de Chaves

Descreve os elementos de um par de chaves pública/privada.

Como primeiro passo para usar qualquer forma de criptografia de chave pública, crie um par de chaves pública/privada. Em seguida, você pode usar a chave privada para criar uma Solicitação de Assinatura de Certificado (CSR) que contenha a chave pública associada. A CSR pode ser usada para obter um certificado assinado de uma CA. Normalmente, as etapas para criar um par de chaves e um CSR ou um certificado autoassinado são executadas como uma operação de etapa única ao usar o OpenSSL para gerar esses arquivos.

Estes são os principais elementos que você precisa considerar ao criar um par de chaves:

Algoritmo

O OpenSSL fornece o uso de algoritmos de chave RSA e ECDSA, sendo as chaves RSA as mais utilizadas. O ECDSA fornece tamanhos de chave muito menores e eficientes que o RSA, juntamente com a segurança correspondente. ECDSA pode ser uma boa escolha para o desempenho. No entanto, alguns ambientes podem não reconhecer as chaves ECDSA.

Tamanho da Chave

O tamanho da chave verifica a complexidade da chave para o algoritmo, que é especificado em bits. Chaves maiores são mais seguras porque são mais complexas e mais difíceis de decifrar. As chaves de tamanho maior também vêm com um impacto de desempenho, porque cada bit de descriptografia requer mais memória e processamento para ser concluído. Portanto, selecionar um tamanho de chave é um equilíbrio entre segurança e desempenho. Os tamanhos das chaves são complexos, pois se relacionam com os algoritmos e cifras que estão sendo usados. Em geral, ao criar chaves RSA, um tamanho de chave é de 2048 bits, enquanto as chaves ECDSA fornecem segurança semelhante usando um tamanho de chave de 256 bits.

Senha

Ao criar uma chave criptografada e protegida com uma cifra, você é solicitado a inserir uma frase-senha que pode ser usada para validar que você pode usar a chave. A criptografia de uma chave com uma frase-senha é opcional, mas recomendada. O uso de uma frase-senha com uma chave pode ser problemático quando o TLS está ativado para um serviço do sistema, pois o serviço não pode ser reiniciado automaticamente sem intervenção do usuário. Muitas vezes, quando os certificados são emitidos para serviços; por conveniência, eles são criados sem frases-senhas. Se uma chave privada for criada sem uma frase-senha, esteja ciente de que qualquer pessoa que obtenha acesso ao arquivo de chave privada pode emular serviços para executar o espionamento do tipo man-in-the-middle. Quando uma chave é protegida com uma frase-senha, você pode selecionar um algoritmo de cifragem a ser usado para criptografar o conteúdo da chave privada. Muitas cifras estão disponíveis para este fim. Para obter uma lista completa de cifras, use o comando openssl list-cipher-commands. A cifra AES é comumente usada para essa finalidade e normalmente é especificada com um tamanho de chave de 128 ou 256 (aes128 ou aes256).

Criando Pares de Chaves

Guia você na geração, proteção e inspeção de pares de chaves OpenSSL.

As instruções a seguir mostram como criar pares de chaves públicas/privadas. Nos exemplos fornecidos, a criação de um par de chaves é tratada como uma operação atômica para que o processo possa ser descrito e os elementos possam ser chamados para uma melhor compreensão. Muitas vezes, este passo é incorporado em outros comandos para a eficiência.

  1. Gerar uma Chave RSA

    Para gerar uma chave RSA, use o comando openssl genrsa, por exemplo:

    sudo openssl genrsa -out private.key 2048

Generating RSA private key, 2048 bit long modulus
...................................................
....................................................
...................................................+++
................................+++
e is 65537 (0x10001)

    Este comando gera uma chave não criptografada no diretório local, chamada private.key. O conteúdo da chave é semelhante ao seguinte exemplo: 

    cat private.key

-----BEGIN RSA PRIVATE KEY-----
...[certificate text]
-----END RSA PRIVATE KEY-----

    Embora o arquivo seja chamado de private.key e o arquivo contenha algum texto que sugira que essa seja apenas a chave privada, a chave pública também é incorporada a esse arquivo. Assim, o único arquivo representa o par de chaves completo. Assim, a obtenção de uma cópia da chave pública é mais fácil porque a chave é armazenada no mesmo arquivo que a chave privada.

  2. Usando uma frase secreta

    Para criar uma chave criptografada com uma frase-senha, execute o mesmo comando, mas especifique uma cifra a ser usada para criptografar a chave, por exemplo: 

    sudo openssl genrsa -aes256 -out private.key 2048

Generating RSA private key, 2048 bit long modulus
............+++
.............................................................+++
e is 65537 (0x10001)
Enter pass phrase for private.key:
Verifying - Enter pass phrase for private.key:

    No exemplo anterior, a cifra AES é usada com uma chave de 256 bits. O comando solicita a inserção de uma frase-senha e sua verificação. O conteúdo do arquivo de chaves indica que a chave está criptografada, conforme mostrado no exemplo a seguir: 

    cat private.key
  
  -----BEGIN RSA PRIVATE KEY-----
  Proc-Type: 4,ENCRYPTED
  DEK-Info: AES-256-CBC,2417E359B45960CD107A390748945752
  
  key-content
  -----END RSA PRIVATE KEY-----
  3. Decriptografando uma chave

    Se você criar um arquivo de chave criptografada e depois decidir que prefere um arquivo que não seja criptografado ou não exija uma frase-senha, poderá descriptografá-lo executando o seguinte comando: 

    sudo openssl rsa -in private.key -out unencrypted.key

Enter pass phrase for private.key:
writing RSA key

    Você é solicitado a inserir a frase-senha na chave criptografada, que é armazenada em private.key, e a versão não criptografada da mesma chave é gravada no arquivo unencrypted.key.

    Todas as chaves OpenSSL são geradas no formato Privacy Enhanced Mail (PEM), que é um formato de texto sem formatação que encapsula o conteúdo da chave como uma string codificada em base64. Os certificados podem ser codificados usando várias convenções de formatação diferentes. Para obter mais informações sobre como alterar o formato de um certificado, consulte Alterando Chave ou Formato de Certificado.

  4. Inspecionar a chave privada

    Você pode exibir o conteúdo de uma chave privada da seguinte forma: 

    sudo openssl rsa -text -in private.key
  5. Exiba a chave pública

    Notavelmente, uma chave privada também contém sua contraparte de chave pública. Este componente de chave pública é usado ao enviar uma CSR ou ao criar um certificado autoassinado. O componente de chave pública pode ser visualizado usando o seguinte comando: 

    sudo openssl rsa -pubout -in private.key

Criando Solicitações de Assinatura de Certificado com o OpenSSL

Explica como criar CSRs com base em chaves privadas e quais informações as CAs exigem.

Uma chave privada pode ser usada para criar uma Solicitação de Assinatura de Certificado (CSR). Uma chave pública e privada pode ser usada para criptografar comunicações. No entanto, um cliente ainda deve validar o certificado público apresentado para uso com comunicação criptografada como proveniente de uma fonte esperada e confiável. Sem alguma forma de validar a chave pública, o cliente pode facilmente sucumbir a ataques de estilo man-in-the-middle que tornariam a criptografia fútil.

Para resolver esse problema, a infraestrutura de chave pública geralmente envolve terceiros, chamados de Autoridades de Certificação (CAs), que podem assinar um certificado como autêntico para uma chave pública específica. Se o cliente tiver uma cópia do certificado da CA, ele poderá validar um certificado para um domínio, com base na assinatura do certificado. A maioria dos sistemas é instalada com alguns certificados de CA confiáveis por padrão. Para verificar os certificados de CA que são confiáveis pelo sistema, use o seguinte comando: 

sudo openssl version -d

Por padrão, esse diretório é /etc/pki/tls e o subdiretório /etc/pki/tls/certs contém todos os certificados confiáveis.

Para obter um certificado assinado de uma CA, uma CSR deve ser gerada usando o componente de chave pública dentro de sua chave privada associada. O CSR é então apresentado à CA, que pode validar as informações na solicitação e usar essas informações para gerar um certificado público válido e assinado. O CSR está associado a um nome de domínio para o host ou hosts nos quais o certificado é usado. A CA usa essas informações para criar um certificado com uma data de expiração especificada.

O exemplo a seguir mostra a sintaxe de comando para criar interativamente um CSR a partir de uma chave privada: 

sudo openssl req -new -key private.key -out domain.example.com.csr

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name (full name) []:.
Locality Name (eg, city) [Default City]:London
Organization Name (eg, company) [Default Company Ltd]:Example Ltd
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:domain.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Os valores padrão podem ser configurados no arquivo /etc/pki/tls/openssl.cnf. O valor Common Name é o mais importante na RSE. Esse valor associa a solicitação de certificado ao nome do host e ao nome do domínio do host no qual o certificado deve ser usado. Se um cliente se conectar a um host que emitiu um certificado para outro domínio, o certificado será inválido.

Você pode gerar um CSR e uma chave privada ao mesmo tempo. Com o seguinte comando, você pode especificar valores para os diferentes campos no CSR na linha de comando: 

sudo openssl req -new -nodes -subj '/CN=domain.example.com/O=Example Ltd/C=GB/L=London' \
  -newkey rsa:3072 -keyout private.key -out domain.example.com.csr

Você pode exibir as informações contidas em um CSR da seguinte forma: 

sudo openssl req -in domain.example.com.csr -noout -text

Depois de ter um CSR, você poderá enviá-lo para uma CA. A CA usa o CSR para gerar um certificado assinado e, em seguida, retorna o certificado com uma cadeia de certificados que pode ser usada para validar o certificado.

Assinando Certificados com OpenSSL

Descreve as opções de uso de CAs comerciais, privadas ou autoassinadas para emitir certificados.

Para ambientes em que você não tem controle sobre os sistemas clientes, sempre use uma CA reconhecida e independente para assinar certificados. OS fornecedores de SO e software negociam com CAs independentes para incluir certificados de validação de CA, juntamente com o software que distribuem. Obter certificados de validação dos principais provedores de CA significa que a maioria dos usuários não precisa gerenciar sua própria lista de certificados de CA confiáveis. Qualquer navegador que visite um site via HTTPS pode validar o certificado público do site combinando a assinatura da CA com os certificados da CA que possui em seu próprio armazenamento.

Se você tiver controle sobre os sistemas cliente, poderá fornecer aos clientes o certificado autoassinado diretamente ou poderá configurar um certificado de CA privado para assinar todos os certificados usados na organização e, em seguida, distribuir o certificado de CA aos clientes. O uso da segunda abordagem valida todos os certificados que são assinados dentro da organização, o que resulta em um controle mais rígido sobre a segurança dos certificados dentro da organização, o que pode resultar em custos de infraestrutura reduzidos.

Criando Certificados Autoassinados para Teste e Desenvolvimento

Fornece orientação para a geração de certificados autoassinados para uso em não produção.

Geralmente, os certificados autoassinados são criados para fins de desenvolvimento e teste. Como esses certificados não são validados por CAs confiáveis, a confiabilidade desses certificados deve ser configurada manualmente. Se a chave privada for comprometida, ela não poderá ser revogada, mas deverá ser removida manualmente da lista de permissões confiáveis. Nunca use esses certificados em ambientes de produção. Um certificado assinado pela CA é sempre preferível a um certificado autoassinado. No entanto, o uso de certificados autoassinados pode ser menos dispendioso e útil para teste e desenvolvimento, sem o incômodo de gerenciar CA privadas ou obter certificados assinados por CA para cada plataforma de teste.

Com o comando openssl, você pode gerar certificados autoassinados que podem ser usados imediatamente. Este comando cria um CSR para a chave privada e, em seguida, gera um certificado X.509 diretamente do CSR, assinando o certificado consigo mesmo.

Por esta razão, o comando é semelhante ao comando que você executaria para criar uma chave privada e CSR, com a exceção de que você também deve especificar o período de validade. Como boa prática, gere apenas um certificado autoassinado pela duração necessária para fins de teste. Dessa forma, se a chave privada for comprometida, o período de validade será limitado, e um novo certificado poderá ser gerado quando o certificado antigo expirar.

Por exemplo, você usaria o seguinte comando para criar um certificado X.509 autoassinado válido por 30 dias:

sudo openssl req -new -x509 -days 30 -nodes -newkey rsa:2048 -keyout private.key \ 
  -out public.cert -subj '/C=US/ST=Ca/L=Sunnydale/CN=www.example.com'

O arquivo private.key gerado contém a chave privada e o arquivo public.cert contém o certificado autoassinado. Normalmente, você nomeia esses arquivos com o mesmo valor do Nome Comum para poder rastrear quais certificados e chaves se aplicam a qual host e nome de domínio.

Você pode definir o valor -newkey para atender aos requisitos de algoritmo personalizado e tamanho da chave. Neste exemplo, o algoritmo é definido como RSA e o tamanho da chave é definido em 2048 bits.

Você pode copiar o arquivo de certificado autoassinado para o armazenamento de certificados confiáveis de qualquer sistema cliente e o sistema cliente valida o certificado como uma correspondência sempre que ele faz uma conexão com o host que o atende.

Você também pode usar o comando keytool para gerar certificados autoassinados, mas o principal objetivo desse comando é instalar e gerenciar certificados digitais JSSE (Java Secure Socket Extension) para uso com aplicativos Java. Consulte Java para obter mais informações.

Criando uma Autoridade de Certificação Privada

Descreve como criar e operar uma hierarquia de CA interna para uso organizacional.

Ao criar uma Autoridade de Certificação (CA) privada, você pode processar CSRs para todos os certificados dentro da organização. Você também pode gerenciar a Lista de Revogação de Certificados (CRL), que os sistemas clientes podem usar para detectar se um certificado ainda é válido ou se foi revogado.

Essa abordagem é melhor do que usar certificados autoassinados porque você pode controlar a revogação. No entanto, o certificado da CA ainda deve ser distribuído para todos os sistemas clientes que precisam validar certificados públicos dentro da organização.

Criar a Raiz da CA

Explica a configuração necessária para gerar e proteger a configuração, as chaves e o certificado da CA raiz.

A Raiz da CA é o certificado fundamental de uma CA e geralmente não é usada para assinar certificados de servidor ou cliente. A Raiz da CA geralmente é usada para assinar um ou mais certificados intermediários para conceder a eles a capacidade de assinar outros certificados. Este modelo significa que, se uma chave privada de Intermediário de CA for comprometida, o Intermediário de CA poderá ser adicionado a uma lista de revogação de certificado e todos os certificados assinados pelo Intermediário serão automaticamente invalidados.

Esse modelo ajuda a proteger a integridade de toda a infraestrutura de chave pública. Sem uma Raiz de CA, não há infraestrutura de chave pública, pois a Raiz de CA é usada para criar a cadeia de confiança que valida todos os certificados na hierarquia. Recomendamos que a Raiz da CA seja criada e mantida em um sistema totalmente isolado com acesso mínimo ou sem acesso à rede e sem acesso direto à Internet. As medidas de segurança implementadas em torno da Raiz da CA são críticas para a segurança de toda a infraestrutura de chave pública. Se a chave privada Root da CA for comprometida, todos os certificados que já tiverem sido assinados por toda a cadeia também poderão ser comprometidos.

Para criar uma Raiz de CA para a organização, você deve criar um par de chaves raiz de acordo com uma configuração definida que o OpenSSL possa usar para gerenciar a configuração da CA e o banco de dados de metadados para certificados emitidos.

Várias etapas estão envolvidas na criação da Raiz da CA, que são descritas nos procedimentos e exemplos a seguir.

Criar uma Estrutura de Diretórios CA

Cria o layout do diretório e os arquivos necessários para as operações da CA raiz.

Todos os certificados e metadados que são gerenciados pela Raiz da CA são armazenados em uma estrutura de diretório específica dentro de alguns arquivos pré-configurados. Crie a estrutura de acordo com requisitos específicos, mas siga estas etapas gerais:

  1. Crie um diretório para armazenar todos os dados relacionados à CA: 
    sudo mkdir /etc/pki/ca

    Você pode armazenar esse diretório em qualquer lugar do sistema. No entanto, ele contém dados confidenciais, portanto, certifique-se de que esteja armazenado em algum lugar com acesso restrito.

  2. Altere para o diretório CA para executar todas as etapas restantes neste procedimento: 
    cd /etc/pki/ca
  3. Crie os subdiretórios necessários.

    Crie diretórios para conter o seguinte: certificados CA, conteúdo do banco de dados CA, Lista de revogação de certificados, todos os certificados recém-emitidos e as chaves privadas: 

    sudo mkdir certs db crl newcerts private
  4. Proteger as chaves privadas.

    Proteja as chaves privadas para garantir que o acesso ao diretório onde elas estão armazenadas seja limitado ao usuário atual: 

    sudo chmod 700 private
  5. Crie os arquivos para o banco de dados CA: 
    sudo touch db/index.txt
openssl rand -hex 16 | sudo tee db/serial
echo 1001 | sudo tee db/crlnumber
Criar um Arquivo de Configuração Raiz da CA

Fornece uma configuração OpenSSL de amostra para emitir certificados da CA raiz.

Crie a configuração Raiz da CA no diretório em que todo o conteúdo relacionado à CA é armazenado. Por exemplo, crie um arquivo no /etc/pki/ca/ca-root.conf e preencha-o com o seguinte conteúdo: 

[default]
name                    = root-ca
domain_suffix           = example.com
aia_url                 = http://$name.$domain_suffix/$name.crt
crl_url                 = http://$name.$domain_suffix/$name.crl
ocsp_url                = http://ocsp.$name.$domain_suffix:9080
default_ca              = ca_default
name_opt                = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
countryName             = "AU"
organizationName        = "Example Org"
commonName              = "Root CA"

[ca_default]
home                    = .
database                = $home/db/index.txt
serial                  = $home/db/serial
crlnumber               = $home/db/crlnumber
certificate             = $home/$name.crt
private_key             = $home/private/$name.key
RANDFILE                = $home/private/random
new_certs_dir           = $home/certs
unique_subject          = no
copy_extensions         = none
default_days            = 3650
default_crl_days        = 30
default_md              = sha256
policy                  = policy_strict

[policy_strict]
# The root CA should only sign intermediary certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = optional
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[policy_loose]
# Allow the intermediary CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` manual page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[req]
# Standard Req options
default_bits            = 4096
encrypt_key             = yes
default_md              = sha256
utf8                    = yes
string_mask             = utf8only
prompt                  = no
distinguished_name      = ca_dn
req_extensions          = ca_ext

[ca_ext]
# Extensions for a the CA root (`man x509v3_config`).
basicConstraints        = critical,CA:true
keyUsage                = critical,keyCertSign,cRLSign
subjectKeyIdentifier    = hash

[intermediary_ext]
# Extensions for an intermediary CA.
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[server_ext]
# Extensions for server certificates.
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[client_ext]
# Extensions for client certificates.
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

[crl_ext]
# Extension for CRLs.
authorityKeyIdentifier=keyid:always

[ocsp]
# Extension for OCSP signing certificates.
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

O exemplo anterior mostra uma configuração que contém muitas entradas opcionais que podem ajudar ao executar diferentes operações com o OpenSSL. Mais importante ainda, a configuração define as extensões que podem ser aplicadas a diferentes tipos de certificado para validar os tipos de operações que são válidos para o certificado. Essa configuração também define políticas diferentes que podem ser aplicadas ao assinar certificados. Por exemplo, você pode usar uma política rigorosa para garantir que um determinado metadados seja especificado; e, se ele corresponder aos valores de CA em um CSR, se o certificado for assinado. Esta política é importante para gerar certificados de CA intermediários. Uma política menos restritiva pode ser aplicada a outros certificados assinados, seja pela CA Root ou por qualquer intermediário.

Veja a seguir as descrições das várias seções deste arquivo de configuração:

[padrão]

A seção padrão define algumas informações básicas de configuração, como URLs, em que informações como o certificado raiz e a lista de revogação publicada desta CA podem ser publicadas. As entradas name e domain_suffix aqui são usadas como variáveis para ajudar a construir alguns desses URLs e também são usadas para nomear e fazer referência a arquivos e certificados-chave. Talvez você queira usar o nome de host do sistema e o domínio do sistema para esses valores. Essa entrada de configuração também faz referência ao local da entrada de configuração da CA padrão em ca_default.

[ca_dn]

Esta seção define alguns valores padrão para certificados que são gerados para o nome distinto desta CA. Esses valores são gravados no CSR e no certificado autoassinado que é gerado dele para o certificado Raiz da CA.

[ca_padrão]

Esta seção fornece a configuração que controla toda a CA. Essas informações fornecidas mapeiam os diretórios que foram criados para esta CA para a configuração, de modo que o OpenSSL possa atualizar corretamente os arquivos e armazenar certificados e chaves nos locais corretos. Esta seção também define alguns valores padrão, como por quantos dias um certificado é válido e por quantos dias a lista de revogação de certificado é válida. Como essa configuração se destina a uma CA raiz, o número de dias para os quais o certificado é válido pode ser definido como 10 anos, porque uma alteração na CA raiz significaria que todos os certificados posteriores na infraestrutura também precisariam ser reemitidos. Você pode exibir todas as opções do arquivo de configuração nas páginas manuais do CA(1).

[estrito_política]

Esta seção descreve uma política rigorosa que deve ser seguida ao assinar alguns certificados, como os certificados de CA intermediários. A política define regras sobre os metadados no certificado. Por exemplo, regras que indicam que o nome do país e o nome organizacional correspondem ao certificado da CA. Outros campos são opcionais, mas um nome comum deve ser fornecido.

[política_solta]

Esta seção é usada para outros certificados assinados por esta CA e seus intermediários, nos quais uma política menos restritiva é permitida. Esta entrada de política torna a maioria dos campos opcionais e requer apenas que o nome comum seja fornecido.

[solicitação]

Esta seção é usada uma vez para criar a solicitação de certificado da CA e define as opções padrão a serem usadas quando a solicitação de certificado é gerada, por exemplo, um tamanho de chave de 4096 bits para a CA raiz. Outra opção aponta para o nome distinto da CA que faz referência à seção ca_dn desse arquivo de configuração para obter os valores padrão a serem usados na solicitação de certificado.

[ca_ext]

Esta seção de extensões define as operações para as quais um certificado é válido. Para a CA raiz, este certificado deve ser válido para assinar todos os certificados de CA intermediários e efetivamente tem direitos completos. Para obter mais informações sobre extensões, consulte a página manual X509V3_CONFIG(5).

[ext_intermediário]

Esta seção é uma configuração de extensão separada para certificados assinados como CAs intermediárias. Este certificado tem os mesmos direitos que a CA raiz, mas não pode assinar certificados para CAs intermediárias adicionais, controladas com o pathlen:0 dentro da opção basicConstraints do certificado.

[ext_servidor]

Esta seção inclui opções típicas de extensão para certificados do lado do servidor, que geralmente são usados para serviços como HTTPS e serviços de correio do lado do servidor, e assim por diante. Esses certificados são emitidos para fins de validação e criptografia, eles não têm direitos de assinatura. A entrada de configuração pode ser referenciada ao assinar um certificado para essa finalidade.

[ext_cliente]

Esta seção inclui certificados do lado do cliente, que geralmente são usados para autenticação remota, em que um usuário pode fornecer um certificado para validar e autenticar o acesso a um sistema. Esses certificados também possuem extensões específicas que controlam o uso. Esta entrada de configuração pode ser usada ao assinar um certificado para certificados do cliente para garantir que as extensões corretas sejam aplicadas ao certificado.

[ext_crl]

Esta extensão é aplicada automaticamente ao criar uma CRL, mas é fornecida para integridade. Consulte Gerenciar uma Lista de Revogação de Certificado

[ocsp]

O On-Line Certificate Status Protocol (OCSP) é uma abordagem diferente para CRLs. Um servidor OCSP pode ser configurado para lidar com solicitações por software cliente para obter o status de um certificado de um recurso que é referenciado em um certificado assinado. Existem extensões especiais para esta finalidade. A página do manual OCSP(1) pode fornecer mais informações. Consulte também Configurar e Executar um Servidor OCSP.

Criar e Verificar o Par de Chaves Raiz da CA

Gera o par de chaves da CA raiz, CSR e certificado autoassinado.

Esta tarefa mostra como criar uma chave privada e uma solicitação de assinatura de certificado para a raiz da CA usando os valores de configuração especificados no arquivo ca-root.conf e salvar a chave privada em private/root-ca.key.

  1. Como essa é a chave mais valiosa de toda a infraestrutura, certifique-se de usar uma frase-senha longa e adequada para protegê-la: 
    sudo openssl req -new -config ca-root.conf -out root-ca.csr -keyout private/root-ca.key
  2. Em seguida, crie um certificado autoassinado usando a CSR e o arquivo ca-root.conf. Tome cuidado para especificar que o certificado deve usar as extensões definidas na seção ca_ext da configuração. 
    sudo openssl ca -selfsign -config ca-root.conf -in root-ca.csr -out root-ca.crt -extensions ca_ext

Using configuration from ca-root.conf
Enter pass phrase for ./private/root-ca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            8f:75:11:1a:8e:33:b2:d1:09:a8:bf:07:9c:67:c8:3e
        Issuer:
            countryName               = AU
            organizationName          = Example Org
            commonName                = Root CA
        Validity
            Not Before: Oct 29 12:23:04 2019 GMT
            Not After : Oct 26 12:23:04 2029 GMT
        Subject:
            countryName               = AU
            organizationName          = Example Org
            commonName                = Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:b9:41:d6:10:36:d4:12:d3:5d:52:29:60:fc:e0:
                    90:34:f6:fb:3e:99:10:33:a1:1d:54:77:3c:11:37:
                    2d:78:c3:3c:3f:40:69:37:fc:de:59:20:c1:1c:07:
                    83:f7:ae:2b:19:03:a7:e8:c6:d6:88:03:b4:ec:60:
                    36:3d:f6:da:59:58:cc:18:18:3e:43:c9:79:11:5b:
                    cf:9e:15:a7:29:fe:dc:4f:7b:0b:93:f0:9a:2b:97:
                    0f:ab:3e:38:7c:e7:c7:d3:5e:34:e2:40:d0:fd:f2:
                    e4:5e:2c:8a:8e:11:83:de:6b:c4:5c:b8:ec:4b:9c:
                    d2:3f:06:3d:53:a6:4b:a6:e3:c6:f6:24:a2:8c:fb:
                    bf:9e:19:d7:60:4b:c5:b6:48:e4:5d:60:4f:2c:47:
                    ca:4a:31:79:bc:7b:5a:25:90:fc:d2:44:a1:79:73:
                    2e:e1:88:a0:73:1f:82:d3:63:3e:67:94:20:f8:be:
                    21:9b:c3:14:4d:3e:9b:19:33:be:9b:cb:e5:54:9f:
                    a7:3f:05:d1:64:56:5f:43:62:65:5b:89:f4:f1:e3:
                    24:e8:1c:d5:03:36:86:ce:9e:76:c7:52:dc:88:f5:
                    d9:87:62:00:82:4d:14:de:a3:60:21:54:12:83:da:
                    8e:8e:5f:63:c3:93:5a:e2:b9:60:16:74:06:c7:46:
                    49:6d:c2:7e:6c:3a:50:3b:bf:c5:d6:20:65:bd:21:
                    a9:ad:b2:1c:4c:13:bf:fd:b8:e1:04:b8:46:c9:6c:
                    29:db:f3:a6:50:3d:2b:9b:83:49:bb:61:c2:8e:94:
                    08:52:84:f2:6d:33:4b:1f:e0:90:ea:a8:ec:d6:ff:
                    97:b8:3d:74:9a:64:d0:f7:22:7d:22:fc:93:47:68:
                    54:63:7c:10:0a:82:2f:84:3f:56:28:cf:8a:03:76:
                    77:b9:db:af:02:6d:b9:36:7e:63:da:f5:d2:a5:6d:
                    54:86:e1:be:f0:e1:54:13:dd:63:0a:53:8e:55:24:
                    90:40:af:f6:38:47:d3:00:0c:ba:66:6a:cc:4b:df:
                    28:fe:02:74:eb:28:15:11:ca:da:a7:86:0f:1f:bd:
                    c4:ac:b9:b1:c7:cc:2a:2a:db:6e:fd:e6:8e:7b:02:
                    17:5e:a7:7d:08:53:e2:a4:69:ca:6b:1f:f1:74:5b:
                    ac:86:2a:f2:b0:80:ea:b7:30:c5:14:c8:12:1e:66:
                    5e:2f:f5:d5:a8:09:39:b4:23:25:fc:ca:35:d5:c0:
                    73:79:a0:8a:12:25:27:ee:f5:ce:9a:97:c0:27:31:
                    ac:21:98:8f:34:25:a5:7a:42:5c:a0:a1:5d:64:39:
                    aa:6a:5e:54:50:5e:ad:c4:fe:c7:93:b1:c0:f7:c9:
                    91:43:93
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier: 
                3C:D9:C3:56:BD:C0:45:83:C8:2B:C7:0F:96:30:CF:2A:55:23:B5:9D
Certificate is to be certified until Oct 26 12:23:04 2029 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
  3. É solicitado que você informe a frase-senha da chave privada para continuar. Depois de serem mostrados os valores do certificado, você será solicitado a assinar o certificado. Depois de assinar o certificado, você poderá confirmá-lo no banco de dados da CA. Os arquivos do banco de dados são atualizados para rastrear esse certificado dentro da infraestrutura de chave pública. Você pode exibir o arquivo db/index.txt para ver a entrada do certificado raiz da CA: 
    sudo cat db/index.txt

V   291026122304Z        8F75111A8E33B2D109A8BF079C67C83E  unknown /C=AU/O=Example Org/CN=Root CA
  4. Os valores exibidos em cada linha no índice do banco de dados incluem:

    • Status (V para válido, R para revogado, E para expirado).

    • Data de expiração no formato YYMMDDHHMMSSZ.

    • Data de revogação ou vazia se não for revogada (neste exemplo de saída, o campo está vazio).

    • Número de série hexadecimal.

    • Localização do arquivo ou unknown, se não for conhecido.

    • Nome distinto.

Criar uma CA Intermediária

Mostra como criar e configurar uma CA intermediária que assina certificados de entidade final.

O próximo passo na criação da infraestrutura é criar uma CA intermediária que possa processar todos os certificados de servidor e cliente. Isso é importante porque, se a chave privada da CA intermediária for comprometida, a CA raiz poderá revogar seu certificado e invalidar qualquer outro certificado emitido por esse intermediário.

Recomendamos que a CA intermediária seja hospedada em um servidor diferente com acesso mais amplo, pois ela lida com a maioria das solicitações de certificado. A CA intermediária é um modelo exato da CA raiz, com a exceção de que seu próprio certificado é assinado pela CA raiz e configurado com as extensões apropriadas para processar solicitações de assinatura.

Criar uma Estrutura de Diretórios CA

Recria o espaço de trabalho da CA no host intermediário.

No host da CA intermediária, execute as mesmas operações que você executou para criar a estrutura do diretório da CA raiz, mas nomeie o diretório pai apropriadamente para que fique claro que a configuração é para um intermediário, por exemplo:

sudo mkdir /etc/pki/ca-intermediary
cd /etc/pki/ca-intermediary/
sudo mkdir certs db crl newcerts private
sudo chmod 700 private
sudo touch db/index.txt
openssl rand -hex 16 | sudo tee db/serial
echo 1001 | sudo tee db/crlnumber
Criar a Configuração de CA Intermediária

Cria uma configuração OpenSSL personalizada para a CA intermediária.

A configuração da CA intermediária é quase idêntica à configuração criada para a raiz da CA, com algumas modificações que a tornam específica para o intermediário. As modificações são indicadas no texto negrito no seguinte exemplo: 

[default]
name                    = sub-ca                           
domain_suffix           = example.com
aia_url                 = http://$name.$domain_suffix/$name.crt
crl_url                 = http://$name.$domain_suffix/$name.crl
ocsp_url                = http://ocsp.$name.$domain_suffix:9080
default_ca              = ca_default
name_opt                = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
countryName             = "AU"
organizationName        = "Example Org"
commonName              = "Intermediary CA"

[ca_default]
home                    = .
database                = $home/db/index.txt
serial                  = $home/db/serial
crlnumber               = $home/db/crlnumber
certificate             = $home/$name.crt
private_key             = $home/private/$name.key
RANDFILE                = $home/private/random
new_certs_dir           = $home/certs
unique_subject          = no
copy_extensions         = none
default_days            = 3650
default_crl_days        = 30
default_md              = sha256
policy                  = policy_strict

[policy_strict]
# The root CA should only sign intermediary certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = optional
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[policy_loose]
# Allow the intermediary CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` manual page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[req]
# Standard Req options
default_bits            = 4096
encrypt_key             = yes
default_md              = sha256
utf8                    = yes
string_mask             = utf8only
prompt                  = no
distinguished_name      = ca_dn
req_extensions          = intermediary_ext

[ca_ext]
# Extensions for a the CA root (`man x509v3_config`).
basicConstraints        = critical,CA:true
keyUsage                = critical,keyCertSign,cRLSign
subjectKeyIdentifier    = hash

[intermediary_ext]
# Extensions for an intermediary CA.
subjectKeyIdentifier = hash
# authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[server_ext]
# Extensions for server certificates.
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[client_ext]
# Extensions for client certificates.
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

[crl_ext]
# Extension for CRLs.
authorityKeyIdentifier=keyid:always

[ocsp]
# Extension for OCSP signing certificates.
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

Na seção intermediary_ext, a linha que contém authorityKeyIdentifier foi comentada porque o intermediário não tem o certificado do emissor disponível. O intermediário não tem conhecimento do emissor do certificado até que o certificado seja assinado. Se você tentar criar o CSR enquanto esta linha ainda estiver incluída na configuração, ela falhará.

Salve o arquivo de configuração como intermediary.conf.

Criar um CSR para a CA Intermediária

Gera a chave privada da CA intermediária e a solicitação de assinatura.

Crie um CSR para o certificado intermediário: 

sudo openssl req -new -config intermediary.conf -out sub-ca.csr -keyout private/sub-ca.key

Este certificado também é um certificado de assinatura, por isso é importante protegê-lo com uma frase-senha para ajudar a evitar seu uso não autorizado e manter a segurança da infraestrutura. Informe a frase-senha quando solicitado.

Criar um Certificado Assinado para a CA Intermediária

Usa a CA raiz para assinar o CSR intermediário com as extensões adequadas.

Copie o sub-ca.csr que você gerou na etapa anterior para o diretório /etc/pki/ca no sistema no qual a CA raiz está hospedada. No host da CA raiz, execute os seguintes comandos para gerar um certificado assinado do CSR e aplicar a extensão de assinatura intermediária: 

cd /etc/pki/ca
sudo openssl ca -config ca-root.conf -in sub-ca.csr -out newcerts/sub-ca.crt \
-extensions intermediary_ext

Você será solicitado a informar a frase-senha da CA raiz. Em seguida, será apresentado o conteúdo do certificado e será solicitado a assiná-lo. Verifique se o conteúdo do certificado faz sentido antes de assiná-lo. Você pode ver que o certificado é emitido pela CA Raiz e contém a CA Intermediária no Assunto. Você também pode ver que as extensões corretas são aplicadas ao certificado.

Após a assinatura do certificado, você será solicitado a atualizar o banco de dados.

O certificado recém-assinado é criado como newcerts/sub-ca.crt.

Criar um arquivo de cadeia de certificados

Combina os certificados raiz e intermediários em uma cadeia implantável.

Como nenhum sistema está ciente do certificado da CA raiz, recomendamos criar uma cadeia de certificados que inclua o certificado público da CA raiz com o certificado da CA intermediária recém-criado. Dessa forma, os hosts só precisam de uma cópia do certificado encadeado para validar quaisquer certificados emitidos pela CA intermediária. Para criar a cadeia de certificados, junte-se aos dois certificados públicos executando o seguinte comando no host da CA raiz: 

sudo sh -c 'cat root-ca.crt newcerts/sub-ca.crt > newcerts/chained-sub-ca.crt'
sudo chmod 444 newcerts/chained-sub-ca.crt

Copie o certificado newcerts/sub-ca.crt e newcerts/chained-sub-ca.crt de volta para o diretório /etc/pki/ca-intermediary/ no host da CA intermediária. Agora você pode usar esse certificado para processar CSRs de servidor e cliente e gerar CRLs.

Quando você retornar um certificado assinado para uma CSR específica, inclua o certificado chained-sub-ca.crt para que ele possa ser instalado no host em que o certificado é usado e distribuído a qualquer cliente que precise validar o certificado assinado.

Processar CSRs e Assinar Certificados

Explica como a CA intermediária assina CSRs de servidor e cliente.

À medida que os sistemas geram CSRs usando o processo descrito em Criando Solicitações de Assinatura de Certificado com OpenSSL, eles devem enviá-las para uma CA a ser assinada.

Todo processamento posterior de CSR para certificados de servidor e de cliente deve ser executado por uma CA intermediária configurada no ambiente ou por uma CA externa de terceiros.

Para processar uma CSR, copie-a para o diretório /etc/pki/ca-intermediary no host da CA intermediária e, em seguida, use o comando openssl CA para assiná-la com a configuração de extensão apropriada.

Por exemplo, para assinar um certificado do lado do servidor para um CSR chamado www.example.com.csr, execute o seguinte comando: 

sudo openssl ca -config intermediary.conf -extensions server_ext -days 375 \
-in www.example.com.csr -out newcerts/www.example.com.crt

Especifique o número de dias para os quais o certificado é válido. Para um certificado do lado do servidor, o número de dias deve ser limitado a um valor muito menor do que a validade de um certificado de CA. É importante selecionar as extensões corretas para aplicar ao certificado. Essas extensões são mapeadas para definições que estão dentro do arquivo de configuração.

Você será solicitado a informar a frase-senha da chave da CA intermediária e, em seguida, será solicitado a assinar o certificado e atualizar o banco de dados.

Devolva o certificado, juntamente com o certificado de CA encadeado, para que eles possam ser distribuídos para validar o certificado.

Gerenciar uma Lista do Certificado de Revogação

Detalha o workflow para rastrear certificados revogados com CRLs.

A lista de revogação de certificados é usada para identificar certificados que foram emitidos por uma CA de assinatura e revogados. A lista também rastreia o motivo pelo qual um certificado foi revogado.

Gerar a CRL

Produz e publica uma CRL atualizada do banco de dados da CA.

Em cada host de CA, você deve criar uma CRL vazia que possa ser atualizada, pois você precisa revogar certificados. Por exemplo, em uma CA intermediária, você usaria o seguinte comando: 

cd /etc/pki/ca-intermediary
sudo openssl ca -config intermediary.conf -gencrl -out crl/sub-ca.crl

Publique a CRL no URL definido no arquivo de configuração para rastrear certificados que foram revogados pela CA. Você deve configurar um web service para atender ao sub-ca.crl, se possível.

Você pode verificar o conteúdo de uma CRL da seguinte forma: 

sudo openssl crl -in crl/sub-ca.crl -noout -text

Se a CRL acabou de ser criada, ela estará vazia. Uma nova CRL deve ser criada periodicamente, com base no valor de configuração definido no arquivo de configuração da CA para default_crl_days. Por padrão, é definido para cada 30 dias.

Revogar um certificado

Mostra como localizar um certificado por número de série e marcá-lo como revogado.

Todo certificado assinado contém o número de série emitido pela CA assinante. É possível visualizar este número de série em um certificado da seguinte forma: 

sudo openssl x509 -serial -noout -in server.crt

Esse número de série identifica o certificado no banco de dados de assinatura de CA e também pode ser usado para identificar o certificado armazenado pela CA que o assinou para que a CA possa revogá-lo.

Na CA em que o certificado foi emitido, você pode encontrar o certificado com o número de série correspondente no diretório certs. Por exemplo, em um host intermediário, para um certificado com o número de série 8F75111A8E33B2D109A8BF079C67C83F, ele seria o seguinte: 

cd /etc/pki/ca-intermediary
sudo ls certs/8F75111A8E33B2D109A8BF079C67C83F*

certs/8F75111A8E33B2D109A8BF079C67C83F.pem

Você também pode verificar os detalhes do certificado no banco de dados da CA: 

sudo grep 8F75111A8E33B2D109A8BF079C67C83F db/index.txt

Para revogar este certificado, a CA assinante deve emitir o seguinte comando: 

sudo openssl ca -config intermediary.conf -revoke certs/8F75111A8E33B2D109A8BF079C67C83F.pem \
-crl_reason keyCompromise

Especifique o motivo para revogar o certificado, pois esse motivo é usado na lista de revogação de certificado. As opções incluem as seguintes: unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, e removeFromCRL. Para obter mais informações, consulte a página do manual CA(1).

Quando um certificado é revogado, o banco de dados da CA é atualizado para refletir essa alteração e o status é definido como R para o certificado listado no arquivo db/index.txt.

O arquivo de banco de dados é utilizado para gerar a CRL toda vez que é criado. Uma boa prática é gerar uma nova CRL assim que você revogar um certificado. Desta forma, esta lista é mantida atualizada. Consulte Gerar a CRL para obter mais informações.

Configurar e Executar um Servidor OCSP

Descreve a emissão de um certificado OCSP e a posição de um servidor OpenSSL OCSP.

O On-Line Certificate Status Protocol (OCSP) oferece uma alternativa às CRLs e inclui seu próprio mecanismo de publicação. OpenSSL inclui uma opção para executar como um servidor OCSP que pode responder a consultas OCSP.

O OCSP é o preferido das CRLs. Normalmente, é uma boa ideia garantir que um servidor OCSP esteja em execução para a CA, especialmente se o URL OCSP aparecer na configuração, pois esse URL está incluído em cada certificado assinado pela CA. Qualquer software cliente pode confirmar o status de revogação de um certificado consultando o servidor OCSP.

Para qualquer autoridade de certificação, crie uma chave e CSR para o servidor OCSP: 

sudo openssl req -new -newkey rsa:2048 -subj "/C=AU/O=Example Org/CN=OCSP Responder" \
-keyout private/ocsp.key -out ocsp.csr

Crie um certificado assinado do arquivo CSR ocsp.csr: 

sudo openssl ca -config intermediary.conf -extensions ocsp -days 187 -in ocsp.csr \
-out newcerts/ocsp.crt

Como o certificado OCSP é responsável por tratar a revogação, ele não pode ser revogado. Portanto, é uma boa prática definir o período de validade do certificado para um período gerenciável, mas relativamente curto. Neste exemplo, o período de validade foi definido como 187 dias, o que significa que ele precisa ser atualizado a cada 6 meses.

Para executar um servidor OCSP na CA atual, você pode usar a ferramenta fornecida no OpenSSL. Por exemplo, você pode usar o seguinte comando: 

sudo openssl ocsp -port 9080 -index db/index.txt -rsigner newcerts/ocsp.crt \
-rkey private/ocsp.key -CA sub-ca.crt -text

O comando especifica o arquivo CA db/index.txt diretamente, o que significa que, conforme os certificados são revogados, o servidor OCSP toma conhecimento deles automaticamente. Ao executar o comando, é solicitada a frase-senha da chave OCSP. O servidor continua a ser executado até que você termine o processo ou escape usando uma sequência de controle, como Ctrl-C.

Você pode testar o serviço verificando o arquivo ocsp.crt. Use o comando openssl da seguinte forma para executar uma consulta OCSP: 

sudo openssl ocsp -issuer sub-ca.crt -CAfile chained-sub-ca.crt -cert newcerts/ocsp.crt \
-url http://127.0.0.1:9080
                        
Response verify OK
newcerts/ocsp.crt: good
        This Update: Oct 30 15:48:11 2019 GMT

A resposta no exemplo anterior indica se a verificação foi bem-sucedida e fornece um status de good se o certificado não tiver sido revogado. Um status revoked será retornado se tiver sido revogado.

Depurando e Testando Certificados com OpenSSL

Fornece comandos de diagnóstico e solução de problemas para verificar certificados, chaves e pontos finais TLS.

Veja a seguir alguns exemplos de como usar comandos OpenSSL para trabalhar com certificados existentes para depurar e testar a infraestrutura. Os exemplos fornecidos aqui não são abrangentes e destinam-se a complementar as páginas manuais do OpenSSL existentes.

Examinando Certificados

Mostra como inspecionar detalhes de certificados, impressões digitais e números de série.

  1. Exiba as informações contidas em um certificado X.509: 
    sudo openssl x509 -text -noout -in server.crt
  2. Exibir a impressão digital SHA1 de um certificado: 
    sudo openssl x509 -sha1 -noout -fingerprint -in server.crt
  3. Exiba o número de série de um certificado assinado: 
    sudo openssl x509 -serial -noout -in server.crt

Verificar se uma Chave Privada Corresponde a um Certificado

Confirma que um certificado, chave ou CSR compartilham o mesmo módulo.

  1. As partes do módulo e do exponente público da chave e do certificado devem corresponder. Estes valores são muitas vezes longos e difíceis de verificar. A maneira mais fácil de comparar o módulo na chave e no certificado é criar um hash SHA256 de cada um e compará-los, por exemplo: 
    sudo openssl x509 -noout -modulus -in server.crt | openssl sha256
sudo openssl rsa -noout -modulus -in server.key | openssl sha256
  2. Você também pode verificar o módulo em um CSR para ver se ele corresponde a uma chave ou certificado, da seguinte forma: 
    sudo openssl req -noout -modulus -in server.csr | openssl sha256

Alterando a Chave ou o Formato do Certificado

Converte certificados e pacotes entre os formatos PEM, DER e PKCS.

  1. Converta um certificado raiz em um formulário que pode ser publicado em um site para download por um navegador: 
    sudo openssl x509 -in cert.pem -out rootcert.crt
  2. Converta um certificado codificado base64 (também conhecido como PEM ou RFC 1421) para o formato DER binário: 
    sudo openssl x509 -in cert.pem -outform der -out certificate.der
  3. Converta os certificados codificados em base64 para uma entidade e sua CA em um único certificado de formato PKCS7: 
    sudo openssl crl2pkcs7 -nocrl -certfile entCert.cer -certfile CACert.cer -out certificate.p7b

Verificar consistência e validade do certificado

Executa comandos de verificação para garantir a cadeia de certificados corretamente e permanecer válido.

Verifique um certificado incluindo a autoridade de assinatura, a cadeia de assinatura e o período de validade:
sudo openssl verify cert.pem

Decriptografando Chaves e Adicionando ou Removendo Frases Passadas

Demonstra como separar ou aplicar frases-senhas a chaves privadas.

  1. Se você criar um arquivo de chave criptografada e decidir que o arquivo não é criptografado ou não requer uma frase-senha, poderá descriptografá-lo usando o seguinte comando: 
    sudo openssl rsa -in private.key -out unencrypted.key
        
Enter pass phrase for private.key:
writing RSA key

    Você é solicitado a inserir a frase-senha na chave criptografada, que é armazenada em private.key, e a versão não criptografada da mesma chave é gravada no arquivo unencrypted.key.

  2. Para criptografar uma chave não criptografada e adicionar uma frase-senha para protegê-la, execute o seguinte comando: 
    sudo openssl rsa -aes256 -in unencrypted.key -out private.key

    Neste exemplo anterior, a cifra AES é usada com uma chave de 256 bits. O comando solicita a inserção de uma frase-senha e a sua verificação. O novo arquivo de chave criptografada é gravado em private.key.

    Observação

    Você pode adicionar ou remover uma frase-senha da chave privada a qualquer momento sem afetar sua contraparte de chave pública. A adição de uma frase-senha protege a chave privada do uso por um usuário não autorizado ou mal-intencionado, mas vem com um inconveniente adicional, pois os serviços que usam a chave privada sempre exigem intervenção manual para iniciar ou reiniciar. Se você remover a frase-senha de uma chave, certifique-se de que ela esteja armazenada com permissões rigorosas e que não seja copiada para sistemas que não a exijam.

Usando OpenSSL para Testar Serviços Configurados SSL/TLS

Fornece comandos de cliente e servidor para validar a conectividade TLS.

  1. Teste um certificado autoassinado configurando um servidor que escuta na porta 443: 
    sudo openssl s_server -accept 443 -cert cert.pem -key prikey.pem -www
  2. Teste o lado cliente de uma conexão. Este comando retorna informações sobre a conexão, incluindo o certificado. Após a conexão ser estabelecida, você poderá inserir manualmente solicitações ou comandos HTTP diretamente no prompt. 
    sudo openssl s_client -connect server:443 -CAfile cert.pem
  3. Extraia um certificado de um servidor: 
    sudo echo | openssl s_client -connect server:443 2>/dev/null | \
sed -ne '/BEGIN CERT/,/END CERT/p' |sudo tee svrcert.pem

Usando o OpenSSL para Criptografia e Validação de Arquivos

Mostra como criptografar, descriptografar, assinar e verificar arquivos com OpenSSL.

Você também pode usar o OpenSSL para criptografar ou descriptografar qualquer tipo de arquivo e criar compilações que possam ser assinadas e usadas para validar o conteúdo e a origem de um arquivo. A seguir estão alguns exemplos de como você pode utilizar o comando openssl.

  1. Criptografar um arquivo usando PBKDF2: 
    openssl aes-256-cbc -e -salt -pbkdf2 -iter 10000 -in file -out file.enc
  2. Decriptografe um arquivo criptografado usando PBKDF2: 
    openssl aes-256-cbc -d -salt -pbkdf2 -iter 10000 -in file.enc -out file.dec
  3. Criar uma compilação SHA256 de um arquivo: 
    sudo openssl dgst -sha256 file
  4. Assine a compilação do arquivo SHA256 usando a chave privada armazenada no arquivo prikey.pem: 
    sudo openssl dgst -sha256 -sign prikey.pem -out file.sha256 file
  5. Verifique a compilação do arquivo assinado usando a chave pública armazenada no arquivo pubkey.pem: 
    sudo openssl dgst -sha256 -verify pubkey.pem -signature file.sha256 file

Mais informações sobre o OpenSSL

Lista as principais páginas man do OpenSSL para referência de comando mais profunda.

Para obter mais informações sobre o OpenSSL, consulte as páginas de manual openssl(1), ciphers(1), dgst(1), enc(1), req(1), s_client(1), s_server(1), verify(1) e x509(1).