O que é um certificado SSL curinga e como implementá-lo [2 métodos]

Principais conclusões

• Um certificado SSL wildcard protege o teu domínio principal e um número ilimitado dos seus subdomínios utilizando uma única chave criptográfica.
• Elimina o trabalho administrativo repetitivo, protegendo automaticamente qualquer nova área de preparação ou portal que construa sem necessitar de um novo ficheiro de segurança.
• A instalação de um curinga manualmente requer a execução de comandos de terminal e o gerenciamento de renovações de 90 dias, enquanto a Cloudways lida com a verificação e as renovações automáticas totalmente em segundo plano.

Fazer crescer um sítio Web significa quase sempre adicionar subdomínios. Cria uma loja, um portal privado ou uma área de teste para testar coisas. Por si só, estas secções separadas são óptimas. No entanto, se as juntares todas, a sua segurança torna-se uma enorme dor de cabeça administrativa.

Os ficheiros SSL básicos apenas bloqueiam um endereço específico. Isso obriga-te a gerar, carregar e controlar um ficheiro de segurança completamente separado para cada nova secção que criares. Esquece apenas um ciclo de renovação e o teu tráfego cai porque os browsers bloqueiam ativamente a ligação.

É exatamente nesta altura que os proprietários de sítios começam a perguntar sobre os certificados wildcard para ver se realmente resolvem o problema.

Abaixo, abordamos o que é o wildcard SSL e como ele funciona. Também mostramos como configurá-lo manualmente em um servidor, além de como o Cloudflare Enterprise Add-on da Cloudways automatiza todo o processo para você.

O que é um certificado SSL curinga e como ele funciona?

Um certificado wildcard é um tipo único de ficheiro de segurança digital. Protege o seu site principal e vários subdomínios simultaneamente.

Normalmente, tens de verificar e instalar um ficheiro separado para cada ponto final no teu servidor. Um certificado ssl wildcard contorna totalmente esse processo repetitivo. Utiliza uma chave criptográfica para verificar toda a estrutura do seu domínio de primeiro nível de uma só vez.

Isto altera a forma como o teu servidor autentica as ligações e reduz significativamente o teu volume de trabalho administrativo diário.

Para compreender exatamente como funciona um wildcard ssl, tens de olhar para dois componentes técnicos específicos. Baseia-se num carácter especial de asterisco para a sua estrutura de nomes e num campo oculto chamado Nome Alternativo do Assunto (SAN) para processar o código.

Primeiro, vamos ver como o asterisco lida com a atribuição de nomes.

Automatiza as renovações do teu Wildcard SSL

Pára de atualizar os registros DNS a cada 90 dias. Hospeda seu aplicativo no Cloudways para provisionar e renovar automaticamente os certificados curinga do Let’s Encrypt totalmente em segundo plano.

Aprende mais

Protegendo subdomínios com o caractere Asterisco (*)

Os ficheiros SSL normais só funcionam para um endereço Web exato. Digamos que compraste um certificado para blog.example.com. Se colocares esse mesmo ficheiro em shop.example.com, o Chrome ou o Safari bloquearão o site.

O browser vê que os nomes são diferentes e dá um erro.

Um certificado ssl curinga usa uma solução inteligente para corrigir essa incompatibilidade. Coloca um asterisco diretamente no nome de domínio para que ele seja lido como *.example.com. Esse símbolo de asterisco funciona como um “pega-tudo”.

Essencialmente, força o browser a aceitar qualquer coisa que esteja mesmo em frente ao teu domínio principal.

Finalmente, deixas de ter de registar cada novo subdomínio que crias. Um ficheiro protege o teu servidor de teste ativo hoje e qualquer novo portal de cliente que possas criar no próximo mês. Salta completamente a configuração extra do servidor.

Configuração do nome alternativo do sujeito (SAN)

O asterisco lida com o truque de nomeação na superfície. No entanto, o ficheiro de certificado real tem de processar esse símbolo de estrela através de uma parte específica do código. Isto acontece no campo Subject Alternative Name.

Os engenheiros costumam chamar-lhe apenas a extensão SAN. Os ficheiros de segurança mais antigos apenas analisavam uma única linha de código para verificar um sítio Web. Os navegadores Web modernos exigem um sistema muito mais robusto para verificar vários endereços de uma só vez.

Quando um provedor cria um certificado ssl curinga hoje, toda a configuração real acontece dentro deste campo SAN. Programa a extensão para conter duas entradas de domínio completamente diferentes.

A primeira entrada protege o teu domínio de raiz nua, como exemplo.com. A segunda entrada é a versão curinga escrita como *.exemplo.com.

Ambas as entradas são absolutamente necessárias. Um navegador da Web trata o teu domínio próprio e um subdomínio como dois sites completamente diferentes.

Ao colocar o nome da raiz e o asterisco no campo SAN, o ficheiro garante que toda a tua rede passa a verificação de segurança em simultâneo.

Comparação de tipos de SSL: Único, multi-domínio e curinga

Quando configuras o SSL, tens normalmente três opções principais para escolher. Um certificado wildcard é ótimo para poupar tempo, mas não é a única forma de bloquear um site. Muitas pessoas ainda usam ficheiros padrão de domínio único ou tentam agrupar tudo numa configuração de vários domínios.

Para perceber porque é que um wildcard ganha frequentemente para sites em crescimento, tens de ver onde é que os outros dois ficam aquém. Vamos começar por ver como se compara com um certificado básico de domínio único.

Certificados de domínio único vs. certificados curinga

Um ficheiro de domínio único faz exatamente o que o seu nome sugere. Protege um endereço Web exato. Se protegeres example.com, a cobertura termina aí. A maioria das Autoridades de Certificação oferece a versão www gratuitamente, mas esse é o limite absoluto.

Se construíres shop.example.com mais tarde, o teu ficheiro de segurança original não funcionará. Tens de comprar um certificado novo e instalá-lo de raiz.

Esta regra rígida é perfeitamente adequada para um blogue pessoal básico. Mas para um site em crescimento, gerir ficheiros individuais torna-se rapidamente um pesadelo. É exatamente aqui que a configuração do wildcard ganha:

• Domínio único: Requer uma nova compra, uma nova validação e uma nova configuração de servidor para cada subdomínio que criares.
• Wildcard: Protege o seu site principal uma vez. Qualquer novo subdomínio que inicies mais tarde recebe proteção automática instantaneamente, sem qualquer trabalho extra.

Certificados multi-domínio (SAN) vs. certificados curinga

Os certificados multi-domínio oferecem uma abordagem ligeiramente diferente. Permitem-te agrupar vários endereços Web diferentes num único ficheiro. Mas a forma como funcionam é bastante rigorosa.

Quando compras um, tens de escrever o nome exato de cada um dos endereços que pretendes proteger, nesse preciso momento. Se quiseres que cubra example.com, blog.example.com e um site totalmente separado, como another-site.com, tens de listar os três antes de fazeres a compra.

A Autoridade de Certificação insere esses nomes específicos no código. Isto cria uma enorme dor de cabeça se o teu site continuar a crescer:

• Os ficheiros multi-domínio obrigam-te a voltar atrás. Se criares um novo site de teste no próximo mês, o teu ficheiro atual não o cobrirá. Na verdade, terás de voltar à Autoridade de Certificação, reemitir todo o certificado com o novo nome e carregá-lo novamente no teu servidor.
• Os certificados wildcard mantêm-te em movimento. Graças ao asterisco, qualquer novo subdomínio obtém proteção instantânea no momento em que entra em funcionamento. Nunca terás de reeditar o ficheiro ou mexer nas definições do teu servidor.

Os ficheiros multi-domínio fazem sentido se tiveres sítios web de raiz completamente diferentes e os quiseres gerir em conjunto. Mas se estiveres apenas a adicionar subdomínios a uma marca principal, um wildcard poupa-te horas de trabalho repetitivo.

Instalação manual de um certificado SSL curinga em um servidor

Obter o certificado wildcard é apenas o começo. Colocá-lo no teu servidor é onde tens de pôr as mãos na massa. Se o teu alojamento web não tratar automaticamente da segurança, tens de ser tu a fazer a instalação.

Isso significa abrir a linha de comando do teu servidor.

Para este passo a passo, usaremos o VPS da DigitalOcean. No entanto, tem em mente que estes mesmos passos se aplicam a quase todos os servidores Linux normais.

Para o certificado em si, utilizaremos o Let’s Encrypt. É uma opção completamente gratuita. Para obteres o nosso ficheiro wildcard, só precisas de executar uma ferramenta básica de linha de comandos chamada Certbot.

Passo 1: Instala o Certbot e o Nginx no teu servidor

Primeiro, faça login no seu servidor como o usuário root. Se estiveres a seguir na DigitalOcean, abre a Launch Console a partir do teu painel de controlo.

Deves certificar-te de que o teu servidor tem as listas de pacotes mais recentes antes de instalares o que quer que seja. Escreve este comando e carrega em Enter:

sudo apt update

Quando a atualização estiver concluída, instala o programa Certbot:

sudo apt install certbot

Em seguida, instala o Nginx (o servidor Web que vamos utilizar para encaminhar o nosso tráfego):

sudo apt install nginx

Etapa 2: Inicia o pedido de curinga

Com o Certbot instalado, estás pronto para pedir o certificado wildcard.

Executa o seguinte comando na tua consola. Para este tutorial, estamos a utilizar o nosso próprio domínio, mas certifica-te de que o trocas pelo teu nome de domínio registado:

sudo certbot certonly --manual --preferred-challenges=dns -d "*.yourdomain.com"

Nota: O * funciona como um wildcard, dizendo ao Let’s Encrypt que queres proteger todos os subdomínios possíveis sob essa raiz.

Assim que carregares em Enter, o Certbot pedir-te-á alguns detalhes antes de poder gerar as tuas chaves de segurança:

Endereço de e-mail: Escreve o teu e-mail e carrega em Enter.

Termos de serviço: Quando te perguntar se concordas com os termos, escreve Y e carrega em Enter.

Partilha de dados: Pode perguntar-te se queres partilhar o teu e-mail com a EFF. Escreve N (ou Y) e carrega em Enter.

Passo 3: Passa o desafio DNS

Assim que a tua conta é registada, o Certbot gera o “Desafio DNS”. Como estás a pedir um wildcard, tens de provar que controlas realmente todo o domínio, adicionando um registo específico às tuas definições de DNS.

O terminal faz uma pausa e emite uma mensagem semelhante a esta:

O Certbot dá-te duas informações cruciais:

• O teu nome: _acme-challenge.whichserversize.net
• O valor: Uma longa sequência de caracteres aleatórios (por exemplo, Okh–KqT…).

Não carregues ainda em Enter no teu terminal. Se carregares em “Enter” antes de o registo estar disponível na Internet, a validação falhará e terás de começar de novo.

Em vez disso, abre um novo separador do browser e inicia sessão no teu fornecedor de serviços de registo de domínios ou de DNS. No nosso exemplo, o domínio é gerido pela Cloudflare.

• No teu painel de controlo do Cloudflare, clica no teu domínio.

• Clica em Registos DNS.

• Clica no botão + Adicionar registo.

• Altera a lista pendente Tipo para TXT.
• Cola o Nome (_acme-challenge) e o Valor exatamente como aparecem no teu terminal.

• Clica em Guardar.

Passo 4: Gera os ficheiros de certificado

As alterações de DNS geralmente levam um ou dois minutos para se propagar pela web. Dá-lhe cerca de 60 segundos, depois volta ao teu terminal DigitalOcean e carrega em Enter.

O Certbot vai procurar na Internet, encontrar esse registo TXT e verificar a tua propriedade. Assim que passar, verás uma mensagem de sucesso a confirmar que o teu certificado está ativo.

A mensagem de sucesso diz-te exatamente onde estão os teus novos ficheiros (normalmente num diretório como /etc/letsencrypt/live/whichserversize.net/). O teu servidor tem agora oficialmente as chaves criptográficas necessárias para proteger o teu domínio principal e quaisquer subdomínios.

Passo 5: Atualizar a configuração do teu servidor Web

Colocar os ficheiros no teu servidor é ótimo, mas o teu site ainda não os pode utilizar. Tens de dizer ao teu servidor Web exatamente onde encontrá-los e garantir que ele está à escuta de tráfego seguro.

Abre o teu ficheiro de configuração Nginx predefinido no editor de texto do terminal:

sudo nano /etc/nginx/sites-available/default

Utiliza as teclas de setas para ires até ao bloco server { e procura a secção # SSL configuration. Tens de fazer duas coisas aqui:

1. Adiciona os teus certificados: Cola estas duas linhas logo abaixo do cabeçalho de configuração SSL:
ssl_certificate /etc/letsencrypt/live/whichserversize.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/whichserversize.net/privkey.pem;

2. Abrir a porta 443: Logo abaixo de onde colaste isso, verás duas linhas que dizem ao Nginx para ouvir o tráfego SSL. Elas estão “comentadas” com um símbolo #. Apaga o # para que fiquem assim:
listen 443 ssl default_server;
listen [::]:443 ssl default_server;

Prima Ctrl+O e prima Enter para guardar e, em seguida, prima Ctrl+X para sair do editor.

Finalmente, testa a tua configuração, abre a tua firewall e reinicia o servidor:

sudo nginx -t

Se o teste for bem-sucedido, basta reiniciar o Nginx (sudo systemctl restart nginx). O teu certificado wildcard está agora totalmente instalado e a proteger a tua rede.

Passo 6: Verifica o teu Wildcard SSL no browser

Para verificar se o teu certificado wildcard está a funcionar, temos de sair do terminal e ir para o nosso browser.

Como instalámos um wildcard(*.whichserversize.net), podemos agora inventar qualquer subdomínio que queiramos, apontá-lo para o endereço IP do nosso servidor e ele ficará seguro instantaneamente.

Para testares, vamos:

• Vai para as definições de DNS no Cloudflare.
• Adiciona um registo A.
• Define o Nome para teste (ou qualquer subdomínio que pretendas).
• Aponta para o endereço IP do teu servidor. Nós vamos apontá-lo para o IPV4 do nosso droplet da DigitalOcean. (Nota: Se usares o Cloudflare, alterna o estado do Proxy para“DNS only” / Grey Cloud para que possas ver o certificado Let’s Encrypt diretamente).

• Agora, acede a https://test.whichserversize.net. E como podemos ver o ícone do cadeado seguro ao lado do nosso URL, parabéns, isso significa que a nossa configuração manual do wildcard SSL está 100% concluída.

Automatizando a instalação do Wildcard SSL com a Cloudways

Embora o método manual faça o trabalho, tem uma enorme desvantagem oculta: os certificados curinga manuais não se renovam automaticamente.

A cada 90 dias, tens de iniciar sessão no teu servidor, executar o Certbot, atualizar o teu DNS Cloudflare e reiniciar o Nginx. Se falhares essa janela, todos os subdomínios que possuis exibirão instantaneamente um aviso“Not Secure” aos teus visitantes.

Gerir a infraestrutura de servidores de três em três meses é uma enorme dor de cabeça.

Na Cloudways, substituímos esse processo de terminal complexo por um painel simples. Lidamos com a validação do Let’s Encrypt, configuramos seu servidor e automatizamos as renovações de 90 dias completamente em segundo plano.

Aqui está como implantar um SSL curinga no seu servidor Cloudways em apenas alguns cliques.

Passo 1: Navega até à Gestão de SSL

Faz login na sua conta Cloudways e abre o aplicativo onde seu site está hospedado.

Na barra lateral esquerda, clica em Certificado SSL.

Etapa 2: Solicita o certificado curinga

Fazemos a integração direta com o Let’s Encrypt para fornecer certificados gratuitos diretamente a partir do painel de controlo.

• Certifica-te de que Let’s Encrypt está selecionado no menu pendente.
• Introduz o teu endereço de e-mail.
• Introduz o teu nome de domínio com o prefixo wildcard (por exemplo, *.whichserversize.net).
• Marca a caixa que diz Aplicar curinga.

Pára aí mesmo e não cliques em nenhum botão. Logo abaixo da caixa de seleção, a tela exibe o registro CNAME exato que você precisa para configurar seu DNS. Ele fornece o Nome (_acme-challenge) e a URL de destino específica (a URL do seu aplicativo Cloudways). Deixa essa guia do navegador aberta.

Passo 3: Adiciona o registo CNAME ao Cloudflare

Agora, passa para o teu fornecedor de domínios para adicionares esse registo CNAME às tuas definições de DNS. Estamos a usar o Cloudflare.

• Abre o teu painel de controlo do Cloudflare e vai aos teus Registos DNS.
• Adiciona um novo registo CNAME.
• Define o Nome como _acme-challenge.
• Cola o URL de destino fornecido na tela do Cloudways no campo Valor/destino.
• Crucial: Se estiveres a utilizar o Cloudflare, certifica-te de que o estado do Proxy está definido como “Apenas DNS” (Nuvem Cinzenta) para este registo específico.
• Clica em Guardar.

Porquê um CNAME?

Ao apontar este registo para a Cloudways permanentemente, dás permissão aos nossos servidores para responder ao desafio do Let’s Encrypt DNS. Isso nos permite renovar automaticamente seu certificado curinga inteiramente em segundo plano.

Passo 4: Verifica o DNS e termina a instalação

Volta para o painel de controle da Cloudways. Dá ao DNS cerca de 60 segundos para se propagar e, em seguida, clica no botão Verificar DNS.

Assim que o DNS for verificado, verás uma notificação de sucesso aparecer no canto superior direito. Também vais reparar que o botão Instalar certificado está agora azul e ativo.

Clica em Instalar certificado.

Nos bastidores, comunicamos instantaneamente com o Let’s Encrypt, descarregamos as tuas chaves criptográficas e configuramos o teu servidor automaticamente.

Assim que a instalação terminar, o painel de controlo será atualizado para mostrar o teu certificado ativo e a sua próxima data de expiração. Mais importante ainda, verás que a opção Renovação automática está activada por predefinição.

Desde que deixes esse registo CNAME nas tuas definições de DNS, o teu domínio principal e todos os subdomínios actuais ou futuros permanecem completamente seguros e nunca mais terás de renovar manualmente o certificado.

Transferindo Wildcard SSL para a borda com o Cloudflare Enterprise

O método Let’s Encrypt acima automatiza SSLs curinga diretamente no seu servidor de origem. À medida que os teus subdomínios geram mais tráfego, tratar cada ligação segura localmente consome os recursos do teu servidor.

Se estiveres a executar subdomínios críticos para o negócio, podes descarregar este trabalho inteiramente usando o Cloudways Cloudflare Enterprise Add-on.

Em vez de processar os handshakes SSL localmente, o add-on implementa um SSL wildcard de nível empresarial na extremidade da rede. Isto protege os teus subdomínios mais perto dos teus utilizadores, tornando as ligações mais rápidas e reduzindo a carga de processamento no teu servidor de origem.

Para além do SSL wildcard, o add-on aplica instantaneamente uma Firewall de Aplicação Web (WAF) empresarial, otimização global de imagens e limitação de taxas para proteger a tua largura de banda de scrapers maliciosos.

Também utiliza o Argo Smart Routing para encaminhar o teu tráfego através dos caminhos mais rápidos disponíveis, ao mesmo tempo que fornece uma atenuação avançada contra vários tipos de ataques DDoS para manter toda a tua rede online.

Recorrer diretamente à Cloudflare para obter estas funcionalidades empresariais exige um contrato anual personalizado que, normalmente, custa milhares de dólares por mês.

Graças à nossa integração, obtém acesso a essa infraestrutura por uma fração do preço padrão do Cloudflare Enterprise, a partir de apenas US$ 4,99 por domínio por mês, diretamente do seu painel de controle da Cloudways.

Nota: Temos um guia detalhado que te orienta nas etapas completas de ativação do addon Cloudflare Enterprise no Cloudways.

Transfere o processamento de SSL para a borda da rede

Pára de desperdiçar recursos do servidor em handshakes SSL locais. Encaminha seus subdomínios através do Cloudflare Enterprise Add-on da Cloudways para criptografia de borda, WAF avançado e mitigação de DDoS.

Aprende mais

Terminar!

Proteger um site em crescimento não tem de significar gerir uma enorme folha de cálculo de certificados SSL. Ao utilizar um certificado wildcard, pode proteger o seu domínio raiz e um número ilimitado de subdomínios com uma única chave criptográfica.

Embora possas instalar certificados Let’s Encrypt manualmente num VPS, o ciclo de renovação de 90 dias torna-se rapidamente um fardo administrativo repetitivo. Esquecer-se de atualizar um registo DNS TXT significa avisos instantâneos de “Não seguro” em toda a sua rede.

Ao hospedar seu aplicativo na Cloudways, você elimina esse risco completamente. Nossa plataforma lida com a verificação de DNS, configura o servidor e automatiza suas renovações de curinga em segundo plano. Você obtém segurança de nível empresarial para toda a sua rede sem ter que tocar em uma linha de comando.