Configurar o SSL/TLS em Amazon Linux 2 - Amazon Elastic Compute Cloud
Pré-requisitosEtapa 1: habilitar o TLS no servidorEtapa 2: obter um certificado assinado por uma CAEtapa 3: testar e intensificar a configuração de segurançaSolução de problemas

Configurar o SSL/TLS em Amazon Linux 2

O Secure Sockets Layer/Transport Layer Security (SSL/TLS) cria um canal criptografado entre um servidor Web e um cliente Web que protege os dados em trânsito contra espionagem. Este tutorial explica como adicionar suporte manualmente para SSL/TLS em uma instância do EC2 com o Amazon Linux 2 e o servidor Web do Apache. Este tutorial pressupõe que você não esteja usando um balanceador de carga. Se você estiver usando Elastic Load Balancing, poderá optar por configurar o descarregamento do SSL no balanceador de carga, usando, em vez disso, um certificado do AWS Certificate Manager.

Por motivos históricos, a criptografia na Web é conhecida simplesmente como SSL. Embora os navegadores da Web ainda ofereçam suporte ao SSL, o protocolo sucessor, o TLS, é menos vulnerável a ataques. O Amazon Linux 2 desativa o suporte no lado do servidor para todas as versões do SSL por padrão. Órgãos de normas de segurança consideram o TLS 1.0 não seguro. O TLS 1.0 e TLS 1.1 foram formalmente preteridos em março de 2021. Este tutorial contém orientações baseadas exclusivamente na ativação do TLS 1.2. O TLS 1.3 foi finalizado em 2018 e está disponível no Amazon Linux 2, desde que a biblioteca TLS subjacente (OpenSSL neste tutorial) seja compatível e esteja habilitada. Os clientes devem ser compatíveis com o TLS 1.2 ou posterior até 28 de junho de 2023. Para obter mais informações sobre os padrões de criptografia atualizados, consulte RFC 7568 e RFC 8446.

Este tutorial refere-se à criptografia da Web moderna simplesmente como TLS.

Importante

Esses procedimentos são destinados ao Amazon Linux 2. Também supomos que você esteja começando com uma nova instância do Amazon EC2. Se você estiver tentando configurar uma instância do EC2 executando uma distribuição diferente ou uma instância executando uma versão antiga do Amazon Linux 2, alguns procedimentos deste tutorial poderão não funcionar. Para o Amazon Linux AMI, consulte Configurar o SSL/TLS no Amazon Linux. Para o Ubuntu, consulte a seguinte documentação da comunidade: Open SSL on Ubuntu (Open SSL no Ubuntu). Para o Red Hat Enterprise Linux, consulte: Como configurar o Servidor Web Apache HTTP. Para outras distribuições, consulte a documentação específica.

nota

Você também pode usar o AWS Certificate Manager (ACM) para o AWS Nitro Enclaves, que é uma aplicação de enclave que permite usar certificados SSL/TLS públicos e privados com suas aplicações Web e servidores em execução em instâncias do Amazon EC2 com o AWSEnclaves Nitro. O Nitro Enclaves é uma capacidade do Amazon EC2 que habilita a criação de ambientes computacionais isolados para proteger e processar com segurança dados altamente sigilosos, como certificados SSL/TLS e chaves privadas.

O ACM for Nitro Enclaves funciona com nginx em execução em sua instância do Linux do Amazon EC2 para criar chaves privadas, distribuir certificados e chaves privadas, além de gerenciar renovações de certificados.

Para usar o ACM for Nitro Enclaves, é necessário usar uma instância do Linux habilitada para enclave.

Para mais informações, consulte O que é o AWS Nitro Enclaves? e AWS Certificate Manager for Nitro Enclaves no Guia do usuário do AWS Nitro Enclaves.

Pré-requisitos

Antes de começar este tutorial, conclua as seguintes etapas:

  • Execute uma instância do Amazon Linux 2 baseada em EBS. Para obter mais informações, consulte Etapa 1: executar uma instância.

  • Configure seus grupos de segurança para permitir que sua instância aceite conexões nas seguintes portas TCP:

    • SSH (porta 22)

    • HTTP (porta 80)

    • HTTPS (porta 443)

    Para obter mais informações, consulte Autorizar tráfego de entrada para suas instâncias do Linux.

  • Instale o servidor da Web Apache. Para obter instruções passo a passo, consulte Tutorial: Instalar um servidor Web LAMP no Amazon Linux 2. Somente o pacote httpd e suas dependências são necessários e, portanto, você pode ignorar as instruções que envolvem PHP e MariaDB.

  • Para identificar e autenticar sites, a infraestrutura de chave pública (PKI) do TLS depende do Sistema de Nomes de Domínio (DNS). Para usar sua instância do EC2 para hospedar um site público, você precisará registrar um nome de domínio para seu servidor da Web ou transferir um nome de domínio existente para o host do Amazon EC2. Há vários serviços de registro de domínio e de hospedagem DNS de terceiros disponíveis para isso, ou você pode usar o Amazon Route 53.

Etapa 1: habilitar o TLS no servidor

Opção: concluir este tutorial usando a automação

Para concluir este tutorial usando o AWS Systems Manager Automation em vez das tarefas a seguir, execute o documento de automação.

Este procedimento o auxilia no processo de configuração do TLS no Amazon Linux 2 com um certificado digital autoassinado.

nota

Um certificado autoassinado é aceitável para testes, mas não para produção. Quando você expõe seu certificado autoassinado na Internet, os visitantes de seu site recebem avisos de segurança.

Para habilitar o TLS em um servidor

  1. Conecte-se à sua instância e confirme se o Apache está em execução.

    [ec2-user ~]$ sudo systemctl is-enabled httpd

    Se o valor retornado não for "habilitado", inicie o Apache e configure-o para iniciar sempre que o sistema for inicializado.

    [ec2-user ~]$ sudo systemctl start httpd && sudo systemctl enable httpd

  2. Para garantir que todos os pacotes de software estejam atualizados, execute uma atualização rápida de software em sua instância. Esse processo pode levar alguns minutos, mas é importante ter certeza de que você tem as atualizações de segurança e correções de bug mais recentes.

    nota

    A opção -y instala as atualizações sem solicitar confirmação. Para examinar as atualizações antes da instalação, você pode omitir essa opção.

    [ec2-user ~]$ sudo yum update -y

  3. Agora que sua instância está atualizada, adicione o suporte ao TLS instalando o módulo mod_ssl do Apache.

    [ec2-user ~]$ sudo yum install -y mod_ssl

    Sua instância agora possui os seguintes arquivos que você usará para configurar seu servidor seguro e criar um certificado para teste:

    • /etc/httpd/conf.d/ssl.conf

      O arquivo de configuração para mod_ssl. Contém as diretrizes que informam ao Apache onde encontrar chaves de criptografia e certificados, as versões do protocolo TLS a serem permitidas e as cifras de criptografia a serem aceitas.

    • /etc/pki/tls/certs/make-dummy-cert

      Um script para gerar um certificado X.509 autoassinado e uma chave privada para o seu host de servidor. Esse certificado é útil para testar se o Apache está configurado corretamente para usar o TLS. Como não oferece prova de identidade, ele não deve ser usado na produção. Caso contrário, avisos nos navegadores da Web serão exibidos.

  4. Execute o script para gerar um certificado fictício autoassinado e uma chave para teste.

    [ec2-user ~]$ cd /etc/pki/tls/certs
sudo ./make-dummy-cert localhost.crt

    Isso gera um novo arquivo localhost.crt no diretório /etc/pki/tls/certs/. O nome do arquivo especificado corresponde ao padrão atribuído na diretiva SSLCertificateFile em /etc/httpd/conf.d/ssl.conf.

    Esse arquivo contém um certificado autoassinado e a chave privada do certificado. O Apache requer que o certificado e a chave estejam no formato PEM, que consiste em caracteres ASCII codificados em Base64 enquadrados pelas linhas "BEGIN" e "END", como neste exemplo.

    -----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD2KKx/8Zk94m1q
3gQMZF9ZN66Ls19+3tHAgQ5Fpo9KJDhzLjOOCI8u1PTcGmAah5kEitCEc0wzmNeo
BCl0wYR6G0rGaKtK9Dn7CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vr
GvwnKoMh3DlK44D9dX7IDua2PlYx5+eroA+1Lqf32ZSaAO0bBIMIYTHigwbHMZoT
...
56tE7THvH7vOEf4/iUOsIrEzaMaJ0mqkmY1A70qQGQKBgBF3H1qNRNHuyMcPODFs
27hDzPDinrquSEvoZIggkDMlh2irTiipJ/GhkvTpoQlv0fK/VXw8vSgeaBuhwJvS
LXU9HvYq0U6O4FgD3nAyB9hI0BE13r1HjUvbjT7moH+RhnNz6eqqdscCS09VtRAo
4QQvAqOa8UheYeoXLdWcHaLP
-----END PRIVATE KEY-----                    

-----BEGIN CERTIFICATE-----
MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy
...
z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0
CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vrGvwnKoMh3DlK44D9dlU3
WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak
3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg==
-----END CERTIFICATE-----

    Os nomes de arquivos e as extensões são uma conveniência e não têm efeito na função. Por exemplo, você pode chamar um certificado de cert.crt, cert.pem ou de um outro nome de arquivo qualquer, desde que a diretiva relacionada no arquivo ssl.conf use o mesmo nome.

    nota

    Ao substituir os arquivos TLS padrão por seus próprios arquivos personalizados, verifique se eles estão no formato PEM.

  5. Abra o arquivo /etc/httpd/conf.d/ssl.conf usando seu editor de texto preferido (como o vim ou o nano) como usuário raiz e comente a seguinte linha: porque o certificado fictício autoassinado também contém a chave. Se você não assinalar o comentário desta linha antes de concluir a próxima etapa, o serviço do Apache não conseguirá ser iniciado.

    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

  6. Reinicie o Apache.

    [ec2-user ~]$ sudo systemctl restart httpd
    nota

    Verifique se a porta TCP 443 está acessível em sua instância do EC2, conforme descrito anteriormente.

  7. Seu servidor da Web do Apache agora deve oferecer suporte a HTTPS (HTTP seguro) por meio da porta 443. Teste-o digitando o endereço IP ou o nome do domínio totalmente qualificado de sua instância do EC2 em uma barra de URL de um navegador com o prefixo https://.

    Como você está se conectando a um site com um certificado de host autoassinado não confiável, o navegador poderá exibir uma série de avisos de segurança. Ignore os avisos e continue para o site.

    Se a página de teste padrão do Apache for aberta, a configuração do TLS no servidor estará correta. Todos os dados que passam entre o navegador e o servidor agora estão criptografados.

    nota

    Para impedir que os visitantes do site encontrem telas de avisos, você precisa obter um certificado assinado por uma CA confiável que, além de criptografar, também autentique você publicamente como o proprietário do site.

Etapa 2: obter um certificado assinado por uma CA

Você pode seguir este processo para obter um certificado assinado por uma CA:

  • Gere uma solicitação de assinatura de certificado (CSR) a partir de uma chave privada

  • Enviar a CSR para uma autoridade de certificação (CA)

  • Obtenha um certificado de host assinado

  • Configure o Apache para usá-lo

Um certificado de host TLS X.509 autoassinado é idêntico em termos criptológicos a um certificado assinado por uma CA. A diferença é social, não matemática. Uma CA promete validar, no mínimo, a propriedade de um domínio antes de emitir um certificado para um candidato. Cada navegador da Web contém uma lista de CAs confiáveis pelo fornecedor do navegador para fazer isso. Primariamente, um certificado X.509 consiste em uma chave pública, que corresponde à chave privada do servidor, e uma assinatura pela CA que é vinculada criptograficamente à chave pública. Quando um navegador se conecta a um servidor da Web por meio de HTTPS, o servidor apresenta um certificado ao navegador para verificação em sua lista de CAs confiáveis. Se o assinante estiver na lista ou for acessível por meio de uma cadeia de confiança que consiste em outros assinantes confiáveis, o navegador negociará um canal rápido de dados criptografados com o servidor e carregará a página.

Geralmente, os certificados são caros devido ao trabalho envolvido na validação das solicitações, portanto, vale a pena comparar os preços. Algumas CAs oferecem certificados de nível básico gratuitamente. Entre essas CAs, a mais notável é o projeto Let's Encrypt, que também oferece suporte à automação de criação de certificados e ao processo de renovação. Para obter mais informações sobre como usar um certificado Let’s Encrypt, consulte Obtenção do Certbot.

Se você planeja oferecer serviços de nível comercial, o AWS Certificate Manager é uma boa opção.

É importante ter um certificado de host subjacente. Desde 2019, grupos governamentais e do setor recomendam usar um tamanho de chave (módulo) mínimo de 2.048 bits para chaves de RSA para a proteção de documentos até 2030. O tamanho do módulo padrão gerado pela OpenSSL no Amazon Linux 2 é de 2048 bits, que é adequada para ser usada em um certificado assinado por uma CA. No procedimento a seguir, uma etapa opcional é fornecida para aqueles que desejam uma chave personalizada, por exemplo, uma com módulo maior ou que usa um algoritmo diferente de criptografia.

Importante

As instruções para adquirir certificados de host assinados pela CA não funcionarão, a menos que você possua um domínio DNS registrado e hospedado.

Para obter um certificado assinado por uma CA

  1. Conecte-se à sua instância e navegue até /etc/pki/tls/private/. Este é o diretório onde você armazenará a chave privada do servidor para TLS. Se você preferir usar uma chave de host existente para gerar a CSR, vá para a Etapa 3.

  2. (Opcional) Gerar uma nova chave privada. Estes são alguns exemplos de configurações de chave. Qualquer uma das chaves resultantes funciona com seu servidor Web, mas elas variam no grau e no tipo de segurança que elas implementam.

    • Exemplo 1: criar uma chave host de RSA padrão. O arquivo resultante, custom.key, é uma chave privada de RSA de 2048 bits.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key

    • Exemplo 2: criar uma chave de RSA mais forte com um módulo maior. O arquivo resultante, custom.key, é uma chave privada de RSA de 4096 bits.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096

    • Exemplo 3: criar uma chave de RSA de 4096 bits criptografada com proteção por senha. O arquivo resultante, custom.key, é uma chave privada de RSA de 4096 bits criptografada com a cifra AES-128.

      Importante

      A criptografia da chave fornece maior segurança, mas como uma chave criptografada requer uma senha, os serviços que dependem dela não podem ser iniciados automaticamente. Sempre que usar essa chave, você precisará fornecer a senha (no exemplo anterior, "abcde12345") por meio de uma conexão SSH.

      [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096

    • Exemplo 4: criar uma chave usando uma cifra não RSA. A criptografia RSA pode ser relativamente devagar devido ao tamanho de suas chaves públicas, que são baseadas no produto de dois números primos grandes. No entanto, é possível criar chaves para TLS que usam códigos não RSA. As chaves baseadas em matemática de curvas elípticas são menores e computacionalmente mais rápidas para fornecer um nível de segurança equivalente.

      [ec2-user ~]$ sudo openssl ecparam -name prime256v1 -out custom.key -genkey

      O resultado é uma chave privada de curva elíptica de 256 bits que usa prime256v1, uma "curva nomeada" compatível com OpenSSL. A força de criptografia é um pouco maior que uma chave de RSA de 2048 bits, de acordo com o NIST.

      nota

      Nem todas as CAs fornecem o mesmo nível de suporte para chaves baseadas em curvas elípticas como para chaves de RSA.

    Verifique se a nova chave privada tem a propriedade e permissões altamente restritivas (owner=root, group=root, leitura/gravação para o proprietário somente). O comando será o mostrado no exemplo a seguir.

    [ec2-user ~]$ sudo chown root:root custom.key
[ec2-user ~]$ sudo chmod 600 custom.key
[ec2-user ~]$ ls -al custom.key

    Os comandos anteriores produzem o resultado a seguir.

    -rw------- root root custom.key

    Depois de criar e configurar uma chave satisfatória, você pode criar uma CSR.

  3. Crie uma CSR usando sua chave preferida. O exemplo a seguir usa custom.key.

    [ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem

    A OpenSSL abre uma caixa de diálogo e solicita a informação exibida na tabela a seguir. Todos os campos, exceto Common Name (Nome comum), são opcionais para um certificado de host básico validado por domínio.

    Nome Descrição Exemplo
    Nome do país A abreviação ISO de duas letras para seu país. US (=Estados Unidos)
    Nome do estado ou província O nome do estado ou província onde sua organização está localizada. Este nome não pode ser abreviado. Washington
    Nome da localidade A localização de sua organização, como uma cidade. Seattle
    Nome da organização A razão social completa da sua organização. Não abrevie o nome de sua organização. Corporação de exemplo
    Nome da unidade organizacional Informações organizacionais adicionais, se houver. Departamento de exemplo
    Nome comum

    Esse valor deve corresponder exatamente ao endereço Web que você espera que os usuários digitem em um navegador. Geralmente, isso significa um nome de domínio com um nome de host ou alias prefixados na forma www.example.com. Para teste com um certificado autoassinado e nenhuma resolução DNS, o nome comum pode consistir apenas no nome do host. As CAs também oferecem certificados mais caros que aceitam nomes curingas como *.example.com.

    		 www.example.com
    Endereço de e-mail O endereço de e-mail do administrador do servidor. someone@example.com

    Finalmente, a OpenSSL solicita uma senha de desafio opcional. Essa senha se aplica somente à CSR e às transações entre você e sua CA, portanto, siga as recomendações da CA sobre este e o outro campo opcional, nome da empresa opcional. A senha de desafio da CSR não tem nenhum efeito sobre a operação do servidor.

    O arquivo resultante csr.pem contém sua chave pública, a assinatura digital de sua chave pública e os metadados que você inseriu.

  4. Envie a CSR a uma CA. Geralmente, isso consiste em abrir seu arquivo de CSR em um editor de texto e copiar o conteúdo em um formulário da Web. Neste momento, pode ser solicitado que você forneça um ou mais nomes alternativos da entidade (SANs) para serem colocados no certificado. Se www.example.com for o nome comum, example.com seria um bom SAN e vice-versa. Um visitante de seu site que digitar qualquer um desses nomes verá uma conexão livre de erros. Se o formulário da Web de sua CA permitir, inclua o nome comum na lista de SANs. Algumas CAs o incluem automaticamente.

    Depois que sua solicitação é aprovada, você recebe um novo certificado de host assinado pela CA. Você também pode receber uma instrução para fazer download de um arquivo de certificado intermediário que contém os certificados adicionais necessários para concluir a cadeia de confiança da CA.

    nota

    Sua CA pode enviar a você arquivos em vários formatos com várias finalidades. Para este tutorial, você deve usar apenas um arquivo de certificado em formato PEM, que geralmente (mas nem sempre) é identificado por uma extensão de arquivo .pem ou .crt. Se você não tiver certeza sobre qual arquivo usar, abra os arquivos com um editor de texto e localize um que contenha um ou mais blocos com a linha a seguir.

    - - - - -BEGIN CERTIFICATE - - - - -

    O arquivo também deve terminar com a linha a seguir.

    - - - -END CERTIFICATE - - - - -

    Você também pode testar um arquivo na linha de comando da forma a seguir.

    [ec2-user certs]$ openssl x509 -in certificate.crt -text

    Verifique se as linhas aparecem no arquivo. Não use os arquivos que terminam com .p7b, .p7c ou extensões de arquivo semelhantes.

  5. Coloque o novo certificado assinado pela CA e quaisquer certificados intermediários no diretório /etc/pki/tls/certs.

    nota

    Há várias maneiras para fazer upload do novo certificado para a instância do EC2, mas a maneira mais simples e informativa é abrir um editor de texto (vi, nano, bloco de notas etc.) no seu computador local e na sua instância e, em seguida, copiar e colar os conteúdos do arquivo entre eles. Você precisa de permissões raiz [sudo] ao realizar essas operações na instância do EC2. Dessa forma, você vê imediatamente se há algum problema de permissão ou de caminho. No entanto, tenha cuidado para não adicionar mais linhas ao copiar o conteúdo ou ao alterá-lo de alguma maneira.

    No diretório /etc/pki/tls/certs, verifique se a propriedade do arquivo, o grupo e as configurações de permissão correspondem aos padrões altamente restritivos do Amazon Linux 2 (owner=root, group=root, leitura/gravação para o proprietário somente). O exemplo a seguir mostra os comandos a serem usados. 

    [ec2-user certs]$ sudo chown root:root custom.crt
[ec2-user certs]$ sudo chmod 600 custom.crt
[ec2-user certs]$ ls -al custom.crt

    Esses comandos devem produzir o resultado a seguir. 

    -rw------- root root custom.crt

    As permissões para o arquivo de certificado intermediário são menos estritas (owner=root, group=root, proprietário pode gravar, grupo pode ler, mundo pode ler). O exemplo a seguir mostra os comandos a serem usados. 

    [ec2-user certs]$ sudo chown root:root intermediate.crt
[ec2-user certs]$ sudo chmod 644 intermediate.crt
[ec2-user certs]$ ls -al intermediate.crt

    Esses comandos devem produzir o resultado a seguir.

    -rw-r--r-- root root intermediate.crt

  6. Coloque a chave privada que você usou para criar o CSR no diretório /etc/pki/tls/private/.

    nota

    Há várias maneiras para fazer upload da chave personalizada para a instância do EC2, mas a maneira mais simples e informativa é abrir um editor de texto (vi, nano, bloco de notas etc.) no seu computador local e na sua instância e, em seguida, copiar e colar os conteúdos do arquivo entre eles. Você precisa de permissões raiz [sudo] ao realizar essas operações na instância do EC2. Dessa forma, você vê imediatamente se há algum problema de permissão ou de caminho. No entanto, tenha cuidado para não adicionar mais linhas ao copiar o conteúdo ou ao alterá-lo de alguma maneira.

    No diretório /etc/pki/tls/private, use os comandos a seguir para verificar se a propriedade do arquivo, o grupo e as configurações de permissão correspondem aos padrões altamente restritivos do Amazon Linux 2 (owner=root, group=root, leitura/gravação para o proprietário somente).

    [ec2-user private]$ sudo chown root:root custom.key
[ec2-user private]$ sudo chmod 600 custom.key
[ec2-user private]$ ls -al custom.key

    Esses comandos devem produzir o resultado a seguir.

    -rw------- root root custom.key

  7. Edite /etc/httpd/conf.d/ssl.conf para refletir seu novo certificado e arquivos de chave.

    1. Forneça o caminho e o nome do arquivo do certificado de host assinado por CA na diretiva SSLCertificateFile do Apache:

      SSLCertificateFile /etc/pki/tls/certs/custom.crt

    2. Se você receber um arquivo de certificado intermediário (intermediate.crt neste exemplo), forneça o caminho e o nome do arquivo usando a diretiva SSLCACertificateFile do Apache:

      SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
      nota

      Algumas CAs combinam os certificados de host e os certificados intermediários em um único arquivo, o que torna a diretriz SSLCACertificateFile desnecessária. Consulte as instruções fornecidas pela CA.

    3. Forneça o caminho e o nome do arquivo da chave privada (custom.key neste exemplo) na diretiva SSLCertificateKeyFile do Apache:

      SSLCertificateKeyFile /etc/pki/tls/private/custom.key

  8. Salve o /etc/httpd/conf.d/ssl.conf e reinicie o Apache.

    [ec2-user ~]$ sudo systemctl restart httpd

  9. Teste seu servidor inserindo seu nome de domínio em uma barra de URL do navegador com o prefixo https://. Seu navegador deve carregar a página de teste via HTTPS sem gerar erros.

Etapa 3: testar e intensificar a configuração de segurança

Depois que o SSL/TLS estiver operacional e exposto ao público, você precisará testar se ele é realmente seguro. É fácil fazer isso usando serviços online, como o Qualys SSL Labs que executa uma análise completa e gratuita de sua configuração de segurança. Com base nos resultados, você pode decidir intensificar a configuração de segurança padrão controlando quais protocolos você aceita, quais cifras você prefere e quais você exclui. Para obter mais informações, consulte como a Qualys formula suas pontuações.

Importante

Os testes no mundo real são cruciais para a segurança do servidor. Pequenos erros de configuração podem resultar em rupturas de segurança sérias e em perda de dados. Como as práticas de segurança recomendadas são alteradas constantemente em resposta a pesquisas e a ameaças emergentes, auditorias periódicas da segurança são essenciais para uma boa administração do servidor.

No site Qualys SSL Labs, digite o nome do domínio totalmente qualificado de seu servidor no formato www.example.com. Depois de dois minutos, você recebe uma classificação (de A a F) para seu site e um detalhamento dos resultados. A tabela a seguir resume o relatório de um domínio com configurações idênticas à configuração padrão do Apache no Amazon Linux 2 e um certificado padrão do Certbot.

Classificação geral B
Certificado 100%
Suporte ao protocolo 95%
Troca de chaves 70%
Intensidade da cifra 90%

Embora a visão geral mostre que a configuração é mais sólida, o relatório detalhado sinaliza vários possíveis problemas, listados aqui em ordem de gravidade:

✗ A codificação RC4 é compatível com o uso por determinados navegadores mais antigos. Uma cifra é o núcleo matemático de um algoritmo de criptografia. A RC4, uma cifra rápida usada para criptografar fluxos de dados TLS, é conhecida por ter várias fraquezas sérias. A menos que você tenha boas razões para oferecer suporte a navegadores legados, você deve desabilitar isso.

✗ Versões antigas do TLS são compatíveis. A configuração é compatível com o TLS 1.0 (já obsoleto) e o TLS 1.1 (em um caminho para a reprovação). Apenas o TLS 1.2 é recomendado desde 2018.

✗ O sigilo de encaminhamento não é totalmente compatível. O sigilo encaminhado é um recurso de algoritmos que criptografam usando chaves de sessão temporárias (efêmeras) derivadas da chave privada. Na prática, isso significa que os atacantes não podem descriptografar dados HTTPS mesmo que tenham a chave privada de longo prazo de um servidor Web.

Para corrigir e preparar futuramente a configuração do TLS

  1. Abra o arquivo de configuração /etc/httpd/conf.d/ssl.conf em um editor de texto e comente as seguintes linhas digitando “#” no início delas.

    #SSLProtocol all -SSLv3

  2. Adicione a seguinte diretiva:

    #SSLProtocol all -SSLv3
SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

    Essa diretiva desabilita explicitamente as versões 2 e 3 do SSL, bem como as versões 1.0 e 1.1 do TLS. O servidor agora se recusa a aceitar conexões criptografadas com clientes que não estejam usando o TLS 1.2. A expressão detalhada na diretriz transmite mais claramente, para um leitor humano, para que o servidor está configurado.

    nota

    Desabilitar as versões 1.0 e 1.1 do TLS dessa forma bloqueia o acesso ao seu site de uma pequena porcentagem de navegadores da Web desatualizados.

Para modificar a lista de cifras permitidas

  1. No arquivo de configuração /etc/httpd/conf.d/ssl.conf, localize a seção com a diretiva SSLCipherSuite e comente a linha existente ao inserir "#" no início dela.

    #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

  2. Especifique conjuntos de criptografia explícitos e uma ordem de cifra que priorize o sigilo antecipado e evite cifras inseguras. A diretiva SSLCipherSuite usada aqui é baseada na saída do gerador de configuração SSL do Mozilla, que adapta uma configuração TLS ao software específico em execução no seu servidor. (Para mais informações, consulte o recurso útil do Mozilla segurança/TLS do lado do servidor.) Primeiro, determine suas versões do Apache e do OpenSSL usando os comandos a seguir.

    [ec2-user ~]$ yum list installed | grep httpd

[ec2-user ~]$ yum list installed | grep openssl

    Por exemplo, se a informação exibida for Apache 2.4.34 e OpenSSL 1.0.2, insira esses valores no gerador. Se você escolher o modelo de compatibilidade "moderno", isso criará uma diretiva SSLCipherSuite que impõe a segurança de forma agressiva, mas ainda funciona para a maioria dos navegadores. Se o software não oferecer suporte à configuração moderna, você poderá atualizá-lo ou escolher a configuração "intermediária".

    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:
ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

    As cifras selecionadas têm ECDHE em seus nomes, o que significa Elliptic Curve Diffie-Hellman Ephemeral (Curva elíptica de Diffie-Hellman efêmera). O termo ephemeral (efêmera) indica forward secrecy. Como subproduto, essas cifras não são compatíveis com RC4.

    Recomendamos que você use uma lista explícita de cifras em vez de confiar em padrões ou em diretrizes concisas cujo conteúdo não é visível.

    Copie a diretiva gerada em /etc/httpd/conf.d/ssl.conf.

    nota

    Embora sejam mostradas em várias linhas aqui para facilitar a leitura, a diretriz deve estar em uma única linha quando copiada para /etc/httpd/conf.d/ssl.conf com apenas dois pontos (sem espaços) entre os nomes das cifras.

  3. Por fim, remova o comentário da linha a seguir, excluindo o "#" no início dela.

    #SSLHonorCipherOrder on

    Essa diretriz força o servidor a preferir cifras de alta classificação incluindo (neste caso) aquelas que oferecem suporte a forward secrecy. Com essa diretriz ativada, o servidor tenta estabelecer uma conexão altamente segura antes de voltar a usar cifras permitidas com menos segurança.

Depois de concluir esses dois procedimentos, salve as alterações em /etc/httpd/conf.d/ssl.conf e reinicie o Apache.

Se você testar o domínio novamente no Qualys SSL Labs, você verá que a vulnerabilidade do RC4 e outros avisos desapareceram e o resumo se parece ao exemplo a seguir.

Classificação geral A
Certificado 100%
Suporte ao protocolo 100%
Troca de chaves 90%
Intensidade da cifra 90%

Cada atualização do OpenSSL apresenta novas cifras e retira o suporte às cifras antigas. Mantenha sua instância do EC2 do Amazon Linux 2 atualizada e fique atento às notificações de segurança da OpenSSL e às notícias sobre novas descobertas em segurança na imprensa técnica.

Solução de problemas

  • Meu servidor da web do Apache não inicia, a menos que eu digite uma senha.

    Esse é comportamento esperado se você tiver instalado uma chave privada de servidor criptografada e protegida por senha.

    Você pode remover a criptografia e a solicitação de senha da chave. Supondo que você tenha uma chave de RSA privada criptografada chamada custom.key no diretório padrão, e que a senha seja abcde12345, execute os comandos a seguir na sua instância do EC2 para gerar uma versão descriptografada da chave:

    [ec2-user ~]$ cd /etc/pki/tls/private/
[ec2-user private]$ sudo cp custom.key custom.key.bak
[ec2-user private]$ sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt 
[ec2-user private]$ sudo mv custom.key.nocrypt custom.key
[ec2-user private]$ sudo chown root:root custom.key
[ec2-user private]$ sudo chmod 600 custom.key
[ec2-user private]$ sudo systemctl restart httpd

    O Apache agora deve iniciar sem solicitar uma senha a você.

  • Obtenho erros ao executar sudo yum install -y mod_ssl.

    Quando estiver instalando os pacotes necessários para SSL, você verá erros como os exibidos a seguir.

    Error: httpd24-tools conflicts with httpd-tools-2.2.34-1.16.amzn1.x86_64
Error: httpd24 conflicts with httpd-2.2.34-1.16.amzn1.x86_64

    Geralmente, isso significa que sua instância do EC2 não está executando o Amazon Linux 2. Este tutorial comporta somente instâncias recentemente criadas em uma AMI oficial do Amazon Linux 2.