Tutoriais de VPS
Corrigir curl 60 SSL certificate problem no VPS (2026): CA, cadeia e verificação de hostname
O navegador funciona, mas curl falha ao validar certificados? Diferencie CA não confiável, cadeia incompleta, hostname errado e arquivo CA inválido; corrija o ambiente real mantendo TLS.
curl no VPS mostra curl: (60) SSL certificate problem para uma API HTTPS que abre no navegador? Não acrescente -k a todos os scripts. O cliente não validou o certificado; pode falhar confiança local, cadeia do servidor, hostname ou relógio.
Confira conexão real, certificados e qual lado corrigir. Serve para APIs, instalação e automação. A falha TLS ocorre antes do processamento HTTP; diferencie de respostas 401, 403 e 404.
Confira no mesmo VPS, contêiner e usuário; substitua o domínio:
curl --version
date -u
curl -v --connect-timeout 10 --max-time 30 https://api.example.com/
Veja backend TLS, endereço, certificados e proxy. Builds diferentes usam armazenamentos CA distintos. O host funcionar não comprova contêiner ou SDK. Retire Authorization, Cookie, credenciais de proxy e URLs sensíveis antes de compartilhar -v.
| Mensagem ou sintoma | O que conferir | Correção comum |
|---|---|---|
unable to get local issuer certificate | Origem da CA e intermediários | Completar cadeia ou configurar CA correta |
certificate has expired | Validade e hora atual | Certificado correto ou ajuste de relógio |
| Hostname diferente | URL, DNS, SAN e SNI | Domínio e certificado corretos |
| Autoassinado ou CA interna | Fonte confiável definida | CA verificada para a chamada |
| Arquivo CA ilegível ou inválido | Caminho, permissões e formato | Corrigir arquivo; pode ser erro 77 |
A orientação de verificação do curl inclui cadeia e hostname da URL. Navegador e curl podem diferir em confiança, cache e complemento da cadeia. Abrir no navegador não descarta problema do servidor.
Com OpenSSL, confira handshake e certificados:
openssl s_client -connect api.example.com:443 \
-servername api.example.com -showcerts \
-verify_hostname api.example.com -verify_return_error </dev/null
-servername envia SNI e -verify_hostname verifica hostname: são ações distintas. -showcerts mostra certificados, sem comprovar validação. s_client pode continuar após erro por padrão; -verify_return_error interrompe aqui o handshake quando falha.
Confira nomes, emissor e validade do certificado final e intermediários necessários. Sites públicos normalmente enviam final e intermediários; a raiz costuma vir do cliente. Dois certificados ou nome fullchain.pem não comprovam configuração.
Se é seu Nginx, configure cadeia completa conforme o emissor, confira sintaxe, recarregue e repita. Para emissão ou renovação, veja diagnóstico do Let's Encrypt.
Certificado de api.example.com acessado por https://服务器IP/ pode falhar sem SAN correspondente ao IP. Alterar Host HTTP não muda o nome validado da URL.
Para conectar diretamente a um servidor, mantenha domínio e altere resolução só da conexão:
curl --resolve api.example.com:443:203.0.113.10 \
https://api.example.com/
Troque o IP documental pelo destino confirmado. --resolve não desativa verificação; o domínio continua definindo TLS. Se só um proxy confia no certificado de origem, cliente direto pode falhar. Confira o projeto de confiança com Cloudflare 525 / 526 e certificados de origem.
Se vários sites HTTPS normais falham com hora e nomes corretos, confira pacote CA ausente ou antigo e caminhos personalizados no sistema ou imagem.
Em Debian / Ubuntu com apt, repare ou atualize conforme manutenção:
sudo apt update
sudo apt install --reinstall ca-certificates
sudo update-ca-certificates
O manual update-ca-certificates explica confiança do sistema. Não é universal para qualquer sistema ou backend. O contêiner precisa do próprio pacote; inclua a correção no build.
Confira também --cacert, CURL_CA_BUNDLE, SSL_CERT_FILE e SSL_CERT_DIR. Entenda qual aplicação atendem antes de corrigir; não limpe configuração de produção sem avaliar. Python, Java e Node.js podem não reutilizar as CA do curl.
Obtenha e verifique a CA por canal confiável, sem confiar cegamente em certificado baixado da conexão falha. Para uma chamada:
curl --cacert /path/to/verified-root-ca.pem https://internal.example.com/
A cadeia e o hostname continuam verificados; isso não valida nome errado ou certificado vencido. Use certificado PEM adequado, não chave privada, site ou página de erro. O usuário de execução precisa ler o caminho. --cacert depende do backend e das opções do curl.
Adicionar CA interna global amplia confiança: siga o processo da organização. Para uma aplicação, considere configuração CA independente suportada e registre a rotação.
-k / --insecure pula verificação. Só mostra que a conexão continua sem essa etapa, sem distinguir intermediário ausente, CA não confiável ou site errado. Não mantenha como solução em produção, instalação ou tarefas agendadas.
Repita o comando real sem -k no ambiente usado. Confirme TLS e depois HTTP e resposta esperados. Um 401 ou 404 posterior exige autenticação ou rotas, não mais alterações de CA.
O artigo original relata 6 testes locais em macOS com curl 8.7.1 (SecureTransport) e OpenSSL 3.6.0: intermediários ausentes, CA não confiável e hostname errado causaram curl 60; cadeia completa e CA indicada retornaram 200; arquivo CA ausente causou 77; OpenSSL validou cadeia e nome. Foram usados certificados temporários e loopback sem alterar confiança do sistema. Não cobrem renovação pública, pacotes Ubuntu, proxies, imagens de contêiner ou SDKs reais.