Saltar para o conteúdo 
O seu certificado expirou ou está prestes a expirar? Neste guia, mostrar-lhe-ei especificamente como Renovar o certificado SSL manual e automaticamente - incluindo armadilhas típicas, ferramentas e definições adequadas.
Guiá-lo-ei através do alojamento, dos servidores personalizados e do WordPress para o ajudar a evitar interrupções, aumentar a segurança e proteger as conversões - do CSR ao HSTS, do Let's Encrypt ao Wildcard.
Pontos centrais
- Automático Extend: Ativar a opção hoster, verificar o estado
- Manual Renovar: Criar CSR, instalar, testar cadeia
- WordPress seguro: Aplicar HTTPS, utilizar plugins
- Erro evitar: .well-known, cadeia, redireccionamentos
- Precaução encontrar: Monitorização, Cronjobs, HSTS
Porque é que os certificados SSL expiram e o que isso significa para si
Cada certificado tem um prazo de validade fixo, para os certificados públicos um máximo de 397 dias. Após a expiração, o browser bloqueia a ligação, os visitantes vêem avisos e, frequentemente, saltam. Isto prejudica a confiança, a conversão e a visibilidade nos motores de busca. Eu evito este risco, vigiando atempadamente a data de expiração e planeando a renovação. Quem renova atempadamente fica em conformidade com a lei e mantém as transmissões de dados protegidas.
Ativar a renovação automática com o fornecedor de alojamento
Muitos painéis de alojamento oferecem ativação com um clique para Renovação automática. Ativo a opção por domínio, verifico a validação armazenada (HTTP-01/DNS-01) e depois verifico a validade no bloqueio do browser. Com vários domínios e subdomínios, poupo muito tempo e evito lacunas entre dois certificados. Para um arranque básico seguro, a opção compacta 5 passos para um sítio Web seguro. Depois disso, limito-me a estar atento aos avisos de expiração do alojamento e a testar regularmente a acessibilidade HTTPS.
Também me asseguro de que o Contacto por correio eletrónico está atualizado na conta de alojamento para que as mensagens de expiração e de erro sejam recebidas. Se a renovação automática for executada através do ACME, tenho em conta Limites da taxa da AC e, se disponível, utilizo um ambiente de teste para não me bloquear inadvertidamente. Para a validação do DNS-01, planeio TTLs para que as entradas se propaguem rapidamente. Existe Registos da CAA na zona, verifico se a minha autoridade de certificação é permitida nessa zona - caso contrário, a renovação falhará apesar da renovação automática.
Para configurações multi-domínio ou wildcard, verifico se o hoster suporta a opção Atualização automática do DNS suportado. Sem uma ligação API, defino processos claros: Quem cria os registos TXT, quem controla a resolução e quando são novamente removidos? Este trabalho preparatório garante que a renovação automática não falha devido a obstáculos organizacionais.
Extensão manual: Do CSR à instalação
Para requisitos especiais, servidores de raiz ou autoridades de certificação específicas, renovo manualmente. Em primeiro lugar, crio uma nova CSR com uma chave adequada (RSA 2048+ ou ECDSA), incluindo os nomes comuns corretos/nomes alternativos do assunto. Inicio o pedido de renovação no portal da CA, confirmo o controlo do domínio (por exemplo, HTTP-01 via .well-known ou DNS-01 via TXT) e aguardo a emissão. Em seguida, descarrego o certificado e os certificados intermédios e verifico a cadeia localmente. Guardo o certificado, a chave e o certificado intermédio no painel de alojamento (por exemplo, Plesk ou cPanel) e testo o Cadeia com um controlo SSL.
Normalmente utilizo Novas chaves em cada renovação, a fim de manter as normas de criptografia actualizadas. Para o ECDSA, por exemplo, utilizo uma curva como a prime256v1; para o RSA, escolho pelo menos 2048 bits. O CSR contém sempre todos os nomes de anfitrião que pretendo proteger, incluindo Domínio de base e www (por exemplo, example.tld e www.example.tld). Planeio a instalação de modo a que o novo certificado esteja pronto antes de o antigo expirar; muitos servidores permitem-no Substituição sem falhas com um recarregamento sem tempo de inatividade.
Após a instalação, testo a entrega com www e sem www, via IPv4 e IPv6e verifico a cadeia completa. Se a cadeia não estiver correta, importo o intermédio adequado da AC. Certifico-me de que o servidor é apenas recarregar (recarregar a configuração), não reinicie o hard para que as ligações activas não sejam canceladas.
Prática de servidor: Apache, Nginx e IIS em resumo
Com Apache Guardo os caminhos no vHost: SSLCertificateFile (certificado do servidor), SSLCertificateKeyFile (chave privada) e - dependendo da versão - SSLCertificateChainFile ou um ficheiro de cadeia completa. Após a troca, verifico a configuração e recarrego-a. Para Nginx Defino ssl_certificate (cadeia completa) e ssl_certificate_key (chave). Testo a configuração, recarrego-a e depois verifico o tratamento de HTTP/2/HTTP/3 e SNI através de vários nomes de servidores.
Em IIS Importo o certificado para o armazenamento de certificados (computador) e vinculo-o ao site. É importante que para cada nome de anfitrião SNI se vários certificados estiverem a ser executados no mesmo IP. Para configurações automatizadas do Windows, programo um cliente ACME para tratar da renovação e da vinculação. Em todos os casos, documento os caminhos, as permissões dos ficheiros (chave apenas para o processo do servidor Web) e o procedimento exato para que a próxima data de renovação decorra sem problemas.
SSL no WordPress: Configurar, aplicar e alargar automaticamente
Com o WordPress, mantenho-o simplesAtivo o Let's Encrypt no alojamento, aplico HTTPS através de um plugin (por exemplo, Really Simple SSL) e verifico os widgets de conteúdo misto. Se o WordPress for executado no seu próprio servidor, utilizo o Certbot, incluindo um cronjob para renovação automática. Em configurações multisite, vale a pena utilizar um certificado wildcard para proteger coletivamente os subdomínios. Utilizo este tutorial para um início rápido: SSL grátis no WordPress. Em seguida, verifico o símbolo do cadeado no navegador e a data de expiração do certificado nas ferramentas do WordPress.
Após a mudança, substituo ligações http difíceis na base de dados para que as imagens, os scripts e os estilos sejam carregados de forma limpa através de HTTPS. Também verifico os plug-ins de cache e as integrações de CDN para garantir que tratam corretamente a variante HTTPS. Importante: Ao forçar o HTTPS, presto atenção aos redireccionamentos limpos (uma cadeia 301) para que os sinais de SEO não sejam diluídos e não sejam criados loops intermináveis.
Nos meus próprios servidores, pretendo usar o Certbot-Renewal como Cronjob e armazenar ganchos de correio que recarregam o Nginx/Apache após uma renovação bem sucedida. Em ambientes WordPress geridos, utilizo as funções de renovação automática do hoster e verifico regularmente se os desafios .well-known estão acessíveis - especialmente quando os plugins de segurança ou as regras WAF são rigorosamente aplicados.
Evitar erros típicos: Validação, cadeia, redireccionamentos
Muitas vezes o Validaçãose o ficheiro HTTP-01 em /.well-known/pki-validation/ não estiver acessível. Para a renovação, desactivei brevemente redireccionamentos agressivos (por exemplo, de não-wwww para www) ou regras que bloqueiam o acesso. Se faltarem certificados intermédios, os navegadores rejeitam o certificado; importo a cadeia completa. Se existirem vários certificados num IP, o SNI tem de estar ativo, caso contrário o servidor entregará o certificado errado. Elimino as caches após cada alteração para poder ver o estado real e atual.
Outros riscos típicos de tropeçar: A Registo AAAA (IPv6) aponta para um servidor diferente de A (IPv4), o desafio falha. Ou o WAF bloqueia o acesso a .well-known. Com o DNS-01, TTLs altos causam atrasos; eu os defino temporariamente como mais baixos. Existir Registos da CAA sem aprovação da CA utilizada, cancelo a renovação até que a entrada seja corrigida. Em ambientes de contentor ou chroot, presto atenção às montagens e permissões corretas para que o servidor Web ou o cliente ACME possa efetivamente entregar os ficheiros de desafio.
Comparação de alojamento: Quem renova de forma mais fiável?
Presto atenção a um Intuitivo interface, renovação automática para todos os domínios e suporte rápido. Isto poupa-me tempo de manutenção e reduz significativamente o tempo de inatividade. Para os fornecedores com integração Let's Encrypt, defino a opção de renovação automática uma vez e verifico a acessibilidade através da monitorização HTTPS. Existem instruções claras para o All-Inkl que tornam a ativação muito rápida: Let's Encrypt no All-Inkl. O quadro seguinte mostra os aspectos a que atribuo especial importância na comparação.
| Fornecedor de alojamento | Renovação automática | Superfície | Suporte | Avaliação |
|---|---|---|---|---|
| webhoster.de | Sim | Muito intuitivo | Rápido | 1º lugar |
| All-Inkl | Sim | Simples | Bom | 2º lugar |
| Europa anfitriã | Parcialmente | Médio | Médio | 3º lugar |
| Alojamento web SSD | Parcialmente | Médio | Médio | 4º lugar |
Também verifico se o fornecedor APIs de DNS para DNS-01 (importante para curingas), fornece informações de registo para validações falhadas e se os certificados podem ser convenientemente exportados como uma cadeia completa. Um bom painel mostra Certificados expirados O sistema começa numa fase inicial, permite direitos granulares (por exemplo, apenas a gestão de SSL) e documenta cada passo. Isto poupa tempo e evita que o conhecimento fique ligado a pessoas individuais.
Reconhecer os processos e preveni-los de forma proactiva
Posso ver o estado em qualquer altura através do Castelo-no navegador, os detalhes do certificado fornecem informações sobre a validade e o emissor. Também defino notificações no painel de alojamento e configuro uma monitorização que avisa da expiração. Os meus próprios servidores recebem um cron job que executa o Certbot regularmente e verifica os registos. No WordPress, mantenho-me informado sobre as notificações dos plugins de segurança e verifico a consola em busca de conteúdos mistos. Esta combinação evita tempos de inatividade e mantém a encriptação ativa sem interrupções.
Para o Controlo técnico Utilizo verificações simples: Recuperar as datas de expiração do certificado, verificar a cadeia e o suporte do protocolo (TLS 1.2/1.3). Na monitorização, planeio níveis de aviso (por exemplo, 30, 14 e 7 dias antes da expiração) e verifico se os ganchos de recarga foram realmente activados após uma renovação bem sucedida. Isto permite-me reconhecer os problemas numa fase inicial - antes de os visitantes verem as páginas de aviso.
Afinação da segurança após a renovação
Após a renovação, tiro o máximo partido do TLS e ativo TLS 1.3 (para além da 1.2), desativar protocolos antigos e cifras desactualizadas. O HSTS com max-age suficientemente longo vincula os clientes ao HTTPS e reduz as superfícies de ataque. O grampeamento OCSP reduz as latências e alivia o respondedor OCSP da CA. Se utilizar RSA, escolha 2048 bits ou mude para ECDSA para obter um melhor desempenho, se necessário. No final, valido a configuração com um teste SSL e analiso de perto os protocolos e as definições criptográficas.
Prefiro cifra moderna com Forward Secrecy e ativo o ALPN para que o HTTP/2 e o HTTP/3 sejam utilizados de forma eficiente. Se disponível, defino paralelamente Certificados ECDSA e RSA Desta forma, os clientes modernos obtêm a variante ECDSA de alto desempenho, enquanto os clientes mais antigos permanecem compatíveis através do RSA. Aumento o HSTS gradualmente (por exemplo, nos primeiros dias, depois semanas) para evitar cimentar permanentemente as configurações incorrectas. Verifico ativamente o agrafamento OCSP após o recarregamento para que os clientes não tenham quaisquer latências de rede adicionais.
Resumo do procedimento prático
Começo por verificar o estado, tomo nota das Data de expiração e decidir: deixar a renovação automática ativa ou renovar manualmente. Para a renovação automática, verifico o caminho de validação (HTTP-01/DNS-01) e testo a acessibilidade do desafio. Para a renovação manual, crio o CSR, peço o certificado à autoridade de certificação e instalo o certificado e a cadeia. Em seguida, imponho o HTTPS, elimino as caches e verifico o conteúdo misto. Por fim, configuro a monitorização e as notificações para nunca mais falhar um prazo.
Casos especiais: Curinga, multi-domínio e tipos de validação
Se tiver muitos subdomínios, utilizo um Cartão selvagem-certificate (*.domain.tld) e poupo-me a certificados separados. Para vários domínios completamente diferentes, confio em certificados SAN/UCC que resumem vários nomes de anfitriões. Os certificados DV são suficientes para a maioria dos projectos, os OV/EV fornecem uma verificação de identidade adicional - útil para lojas ou portais com dados sensíveis. Presto atenção aos limites de tempo de execução e planeio a renovação de modo a que não haja intersecção durante o pico de funcionamento. Para a validação do DNS em zonas produtivas, trabalho com convenções de nomenclatura claras, para que possa encontrar rapidamente as entradas novamente e Alterar pode.
Em Cartão selvagem é importante: a validação é efectuada exclusivamente através do DNS-01, pelo que utilizo actualizações automáticas do DNS ou janelas de manutenção dedicadas. Em ambientes com vários domínios, certifico-me de que todas as variantes estão na lista SAN (incluindo subdomínios que foram adicionados ao longo do ano). Para configurações de balanceadores de carga, planeio o Distribuição dos novos certificados para todos os nós e, em seguida, testar cada VIP/região separadamente. Com equipas em mudança, é útil ter uma documentação clara sobre quem recebe que segredos (chaves) e quando, e como são armazenados de forma segura.
ACME e ambientes complexos: CDN, WAF e proxies inversos
Devo utilizar CDN ou um WAF, certifico-me de que a validação chega à Origem: ou tenho os pedidos de desafio respondidos no Edge (se suportados) ou executo desvios direcionados para /.well-known/ on. Para o HTTP-01, pode haver um redireccionamento para HTTPS, mas o desafio deve ser acessível sem cabeçalhos de autenticação, limites de taxa ou bloqueios geográficos. Para o DNS-01, testo se a entrada TXT está disponível em todo o mundo e se nenhuma configuração de horizonte dividido está a interferir com a avaliação.
Atrás Proxies inversos Verifico os cabeçalhos mais atrás (X-Forwarded-Proto) para que a aplicação reaja corretamente ao HTTPS e não gere quaisquer erros de conteúdo misto. Para renovações com tempo de inatividade zero, eu rolo os certificados passo a passo primeiro um nó, depois os outros - para poder voltar atrás rapidamente em caso de problemas sem arriscar todas as ligações.
Plano de emergência: cancelamento, perda de chaves e substituição rápida
Se houver um Fuga de chaves ou um compromisso, revogo imediatamente o certificado e emito um novo com novas chaves. Eu mantenho um Lista de controlo pronto: Acesso ao portal da AC, procedimento de revogação, geração de novas chaves, distribuição rápida e recarregamento. Em seguida, verifico o agrafamento e as caches OCSP para remover as cadeias antigas das caches. Registo a causa, a hora e as contramedidas na documentação - isto facilita as auditorias e evita recorrências.
Brevemente resumido
Renovo os certificados atempadamente, verifico o Renovação automática-e manter a validação acessível. Nos casos em que a renovação automática não funciona, faço a renovação manualmente: gero o CSR, aplico, instalo a cadeia, testo o HTTPS. Protejo o WordPress com HTTPS forçado e monitorização, os meus próprios servidores são controlados por cronjobs e Certbot. Evito erros mantendo-me atento ao desafio .well-known, aos certificados intermédios, ao SNI e às regras de reencaminhamento. Com este processo, a encriptação permanece ativa, os utilizadores confiam no sítio e a visibilidade não sofre com os avisos de expiração.
