Como criar um certificado SSL autoassinado para o Apache no Ubuntu 18.04

Uma versão anterior deste tutorial foi escrita por Justin Ellingwood.

Introdução

O TLS, ou segurança de camada de transporte e seu antecessor, o SSL, que significa camada de socket segura, são protocolos Web usados para envolver o tráfego normal em um pacote protegido e criptografado.

Ao usar essa tecnologia, os servidores podem enviar tráfego com segurança entre servidores e clientes sem a possibilidade de mensagens serem interceptadas por agentes externos. O sistema de certificados também ajuda os usuários a verificar a identidade dos sites com os quais eles estão se conectando.

Neste guia, mostraremos como configurar um certificado SSL autoassinado para uso com um servidor Web Apache no Ubuntu 18.04.

Pré-requisitos

Antes de começar, você deve ter um usuário não-raiz configurado com privilégios sudo. Você pode aprender como configurar esse tipo de usuário seguindo nossa Configuração inicial de servidor com o Ubuntu 18.04.

Você também precisará ter o servidor Web Apache instalado. Se você quiser instalar uma pilha LAMP (Linux, Apache, MySQL, PHP) inteira no seu servidor, você pode seguir nosso guia sobre como configurar o LAMP no Ubuntu 18.04. Se você quiser apenas o servidor web Apache, pule os passos referentes ao PHP e MySQL.

Quando tiver completado os pré-requisitos, continue abaixo.

Passo 1 — Criando o certificado SSL

O TLS/SSL funciona usando uma combinação de um certificado público e uma chave privada. A chave SSL é mantida em segredo no servidor. Ela é usada para criptografar o conteúdo enviado para clientes. O certificado SSL é compartilhado publicamente com qualquer um que solicitar o conteúdo. Ele pode ser usado para decifrar o conteúdo assinado pela chave SSL associada.

Podemos criar um par chave autoassinada e certificado com o OpenSSL em um único comando:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

Uma séria de questões será feita a você. Antes de passarmos por isso, vamos ver o que está acontecendo no comando que estamos emitindo:

• openssl: esta é a ferramenta básica de linha de comando para criação e gerenciamento de certificados OpenSSL, chaves e outros arquivos.
• req: este subcomando especifica que queremos usar o gerenciamento X.509 de solicitação de assinatura de certificado (CSR). O “X.509” é um padrão de infraestrutura de chave pública aderido pelo SSL e o TLS para seu gerenciamento de chaves e certificados. Queremos criar um novo cert X.509, então estamos usando este subcomando.
• -x509: isso modifica ainda mais o subcomando anterior dizendo ao utilitário que queremos criar um certificado autoassinado em vez de gerar uma solicitação de assinatura de certificado, como normalmente aconteceria.
• -nodes: isso diz ao OpenSSL para pular a opção de proteger nosso certificado com uma frase secreta. Precisamos que o Apache consiga ler o arquivo, sem a intervenção do usuário, quando o servidor for iniciado. Uma frase secreta impediria que isso acontecesse porque teríamos que digitá-la após cada reinício.
• -days 365: esta opção define a duração do tempo em que o certificado será considerado válido. Aqui, nós configuramos ela para um ano.
• -newkey rsa:2048: isso especifica que queremos gerar um novo certificado e uma nova chave ao mesmo tempo. Não criamos a chave necessária para assinar o certificado em um passo anterior, então precisamos criá-la junto com o certificado. A porção rsa:2048 diz a ele para criar uma chave RSA que seja de 2048 bits.
• -keyout: esta linha diz ao OpenSSL onde colocar o arquivo gerado de chave privada que estamos criando.
• -out: isso diz ao OpenSSL onde colocar o certificado que estamos criando.

Como mostrado acima, essas opções criarão tanto um arquivo de chave como um certificado. Algumas perguntas sobre nosso servidor serão feitas para incorporar as informações corretamente no certificado.

Preencha os prompts devidamente. A linha mais importante é aquela que solicita o Nome comum (por exemplo, o servidor FQDN ou o SEU nome). Você precisa digitar o nome do domínio associado ao seu servidor ou, mais provável, o endereço IP público do seu servidor.

A totalidade dos prompt se parecerá com isto:

Output
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name (eg, section) []:Ministry of Water Slides
Common Name (e.g. server FQDN or YOUR name) []:server_IP_address
Email Address []:admin@your_domain.com

Ambos os arquivos que você criou serão colocados nos subdiretórios apropriados em /etc/ssl.

Passo 2 — Configurando o Apache para usar o SSL

Criamos nossos arquivos de chave e certificado no diretório /etc/ssl. Agora, precisamos modificar nossa configuração do Apache para aproveitarmos melhor o mesmo.

Vamos fazer alguns ajustes na nossa configuração:

1. Criaremos um snippet de configuração para especificar configurações padrão robustas do SSL.
2. Vamos modificar o arquivo SSL Apache Host Virtual incluso para apontar para nossos certificados SSL gerados.
3. (Recomendado) Modificaremos o arquivo de Host Virtual não criptografado para redirecionar automaticamente as solicitações para o Host Virtual criptografado.

Quando terminarmos, devemos ter uma configuração SSL segura.

Criando um snippet de configuração do Apache com configurações de criptografia robustas

Primeiro, vamos criar um snippet de configuração do Apache que defina algumas configurações do SSL. Isso irá configurar o Apache com uma série de criptografia SSL forte e habilitar algumas funcionalidades avançadas que irão ajudar a manter nosso servidor seguro. Os parâmetros que vamos definir podem ser usados por qualquer Host Virtual habilitando o SSL.

Crie um novo snippet no diretório /etc/apache2/conf-available. Vamos nomear o arquivo ssl-params.conf para deixar seu objetivo claro:

sudo nano /etc/apache2/conf-available/ssl-params.conf

Para configurar o Apache SSL com segurança, utilizaremos as recomendações de Remy van Elst presentes no site Cipherli.st. Este site foi projetado para fornecer configurações de criptografia de fácil acesso para softwares populares.

[<$>note ]As configurações sugeridas no site mostrado acima oferecem uma segurança robusta. De vez em quando, isso acontece ao custo de maior compatibilidade com o cliente. Se você precisa dar suporte a clientes antigos, existe uma lista alternativa que pode ser acessada clicando no link na página rotulada “Sim, dê-me uma criptografia que funciona com o software legado / velho.” Essa lista pode ser substituída pelos itens copiados abaixo.

A escolha de qual configuração você usa dependerá em grande parte do que você precisa suportar. Ambas fornecerão uma ótima segurança. <$>

Para nossos propósitos, podemos copiar as configurações fornecidas em sua totalidade. Vamos fazer apenas uma pequena mudança. Vamos desativar o cabeçalho Strict-Transport-Security (HSTS).

O pré-carregamento do HSTS proporciona maior segurança, mas pode ter consequências consideráveis se for habilitado acidentalmente ou de maneira incorreta. Neste guia, não habilitaremos essas configurações, mas você pode modificar isso caso tenha certeza de que você entenda as implicações.

Antes de decidir, leia com cuidado Segurança de transporte estrito HTTP, ou HSTS, mais especificamente sobre a funcionalidade “pré-carregamento”

Cole a configuração no arquivo ssl-params.conf que abrimos:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder On
# Disable preloading HSTS for now.  You can use the commented out header line that includes
# the "preload" directive if you understand the implications.
# Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
# Requires Apache >= 2.4.11
SSLSessionTickets Off

Salve e feche o arquivo quando você terminar.

Modificando o arquivo padrão de Host Virtual SSL do Apache

Em seguida, vamos modificar o /etc/apache2/sites-available/default-ssl.conf, o arquivo padrão de Host Virtual SSL do Apache Se estiver usando um arquivo de bloco de servidor diferente, substitua seu nome nos comandos abaixo.

Antes de continuar, vamos voltar para o arquivo de Host Virtual SSL original:

sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak

Agora, abra o arquivo de Host Virtual SSL para fazer ajustes:

sudo nano /etc/apache2/sites-available/default-ssl.conf

Dentro, com a maioria dos comentários removidos, o arquivo de Host Virtual deve se parecer com isso por padrão:

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerAdmin webmaster@localhost

                DocumentRoot /var/www/html

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on

                SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
                SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

                <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
                                SSLOptions +StdEnvVars
                </Directory>

        </VirtualHost>
</IfModule>

Vamos fazer alguns pequenos ajustes no arquivo. Vamos definir as coisas normais que gostaríamos de ajustar em um arquivo de Host Virtual (endereço de e-mail do ServerAdmin, ServerName, etc., e ajustar as diretivas do SSL para que apontem para nossos arquivos de certificado e chave.

Após fazer essas alterações, seu bloco de servidor deve se parecer com este:

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerAdmin your_email@example.com
                ServerName server_domain_or_IP

                DocumentRoot /var/www/html

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on

                SSLCertificateFile      /etc/ssl/certs/apache-selfsigned.crt
                SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key

                <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
                                SSLOptions +StdEnvVars
                </Directory>

        </VirtualHost>
</IfModule>

Salve e feche o arquivo quando você terminar.

(Recomendado) Modificando o arquivo de host HTTP para redirecionar para HTTPS

Da forma em que se encontra, o servidor fornecerá tanto tráfego HTTP não criptografado quanto HTTPS criptografado. Para maior segurança, é recomendável redirecionar na maioria dos casos o HTTP para HTTPS automaticamente. Se não quiser ou precisar dessa funcionalidade, você pode pular essa seção com segurança.

Para ajustar o arquivo de Host Virtual não criptografado para redirecionar todo o tráfego a ser criptografado pelo SSL, podemos abrir o arquivo /etc/apache2/sites-available/000-default.conf:

sudo nano /etc/apache2/sites-available/000-default.conf

Lá, dentro dos blocos de configuração VirtualHost, precisamos adicionar uma diretiva Redirect, que direciona todo o tráfego para a versão SSL do site:

<VirtualHost *:80>
        . . .

        Redirect "/" "https://your_domain_or_IP/"

        . . .
</VirtualHost>

Salve e feche o arquivo quando você terminar.

Passo 3 — Como ajustar o Firewall

Se você tem o firewall ufw ativado, conforme recomendado pelos guias de pré-requisitos, pode ser necessário ajustar as configurações para permitir o tráfego SSL. Felizmente, o Apache registra alguns perfis com o ufw na instalação.

Podemos ver os perfis disponíveis digitando:

sudo ufw app list

Você deve ver uma lista como essa:

Output
Available applications:
  Apache
  Apache Full
  Apache Secure
  OpenSSH

Você pode verificar a configuração atual digitando:

sudo ufw status

Se você permitiu apenas o tráfego HTTP regular mais cedo, seu resultado pode se parecer com este:

Output
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Apache                     ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Apache (v6)                ALLOW       Anywhere (v6)

Para também admitir o tráfego HTTPS, podemos permitir o perfil “Apache Full” e então excluir a permissão de perfil redundante “Apache”:

sudo ufw allow 'Apache Full'
sudo ufw delete allow 'Apache'

Agora, seu status deve se parecer com este:

sudo ufw status

Output
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Apache Full                ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Apache Full (v6)           ALLOW       Anywhere (v6)

Passo 4 — Habilitando as alterações no Apache

Agora que fizemos nossas alterações e ajustamos nosso firewall, é possível habilitar os módulos SSL e de cabeçalhos no Apache, habilitar nosso Host Virtual pronto para o SSL e reiniciar o Apache.

Podemos habilitar o mod_ssl, o módulo SSL do Apache e o mod_headers, necessário para algumas das configurações no nosso snippet SSL, com o comando a2enmod:

sudo a2enmod ssl
sudo a2enmod headers

Em seguida, podemos habilitar nosso Host Virtual SSL com o comando a2ensite:

sudo a2ensite default-ssl

Também precisaremos habilitar nosso arquivo ssl-params.conf, para que leia nos valores que definirmos:

sudo a2enconf ssl-params

Neste ponto, nosso site e os módulos necessários estão habilitados. Devemos verificar e garantir que não haja erros de sintaxe em nossos arquivos. Podemos fazer isso digitando:

sudo apache2ctl configtest

Se tudo for bem-sucedido, você receberá um resultado que se parecerá com este:

Output
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

A primeira linha é apenas uma mensagem informando que a diretiva ServerName não está definida globalmente. Se você quiser se livrar dessa mensagem, é possível definir o ServerName como o nome do domínio do seu servidor ou o endereço IP em /etc/apache2/apache2.conf. Isso é opcional, uma vez que a mensagem não causará problemas.

Se seu resultado tiver Syntax OK, seu arquivo de configuração não possui erros de sintaxe. Podemos reiniciar com segurança o Apache para implementar nossas alterações:

sudo systemctl restart apache2

Passo 5 — Testando a criptografia

Agora, estamos prontos para testar nosso servidor SSL.

Abra seu navegador Web e digite https:// seguido pelo nome do domínio ou endereço IP do seu servidor na barra de endereço:

https://server_domain_or_IP

Pelo fato do certificado que criamos não ser assinado por uma das autoridades de certificado confiáveis do seu navegador, você provavelmente verá um aviso assustador como o que está abaixo:

Isso é esperado e é normal. Só estamos interessados no aspecto de criptografia do nosso certificado, não na validação de terceiros da autenticidade do nosso host. Em todo caso, clique em “ADVANCED” e então no link fornecido para prosseguir para seu host:

Você deve ser levado para seu site. Se você olhar na barra de endereço do navegador, será possível ver um cadeado com um “x” sobre ele. Neste caso, isso significa apenas que o certificado não pode ser validado. Ela ainda está criptografando sua conexão.

Se você configurou o Apache para redirecionar HTTP para HTTPS, também é possível verificar se o redirecionamento está funcionando corretamente:

http://server_domain_or_IP

Se o resultado for o mesmo ícone, isso significa que seu redirecionamento funcionou corretamente.

Passo 6 — Mudando para um redirecionamento permanente

Se seu redirecionamento funcionou corretamente e você tem certeza de que quer permitir apenas o tráfego criptografado, você deve modificar novamente o Host Virtual do Apache não criptografado para tornar o redirecionamento permanente.

Abra mais uma vez o arquivo de configuração do bloco do seu servidor:

sudo nano /etc/apache2/sites-available/000-default.conf

Encontre a linha Redirect que adicionamos mais cedo. Adicione permanent a essa linha. Isso muda o redirecionamento de uma redirecionamento temporário 302 para um redirecionamento permanente 301:

<VirtualHost *:80>
        . . .

        Redirect permanent "/" "https://your_domain_or_IP/"

        . . .
</VirtualHost>

Salve e feche o arquivo.

Verifique sua configuração quanto a erros de sintaxe:

sudo apache2ctl configtest

Quando estiver pronto, reinicie o Apache para tornar o redirecionamento permanente:

sudo systemctl restart apache2

Conclusão

Você configurou seu servidor Apache para usar uma criptografia robusta para conexões com clientes. Isso permitirá que você atenda aos pedidos com segurança e impedirá que agentes externos leiam seu tráfego.