curl: (60) SSL certificate problem 해결

Problem

curl이 curl: (60) SSL certificate problem: unable to get local issuer certificate로 멈추고 진행을 거부합니다. 종료 코드 60은 CURLE_PEER_FAILED_VERIFICATION — curl이 인증서를 받았지만 그것을 신뢰하는 인증기관까지 이어지는 체인을 만들지 못한 것입니다. 인증서 자체는 대개 멀쩡합니다. 빠진 것은 연결 고리입니다: 서버가 자기 인증서를 공개 루트로 이어줄 중간 인증서를 안 보냈거나, 내 컴퓨터에 체인을 완성할 루트(또는 중간)가 없거나, 나와 서버 사이의 무언가가 인증서를 내가 신뢰하지 않는 CA가 서명한 것으로 바꿔치기한 것입니다. 관건은 이 셋 중 어느 것인지 가려내는 일입니다.

Symptoms

• 전체 메시지는 curl: (60) SSL certificate problem: unable to get local issuer certificate입니다. 뒤쪽 문구는 OpenSSL의 검증 결과 num=20(X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY)입니다.
• 가까운 친척들은 서로 다른 체인 문제를 가리킵니다: self signed certificate in certificate chain(검증 오류 19)는 사설/가로채기 CA가 경로에 있음, self signed certificate(18)는 엔드포인트가 자기 루트를 제시함, unable to verify the first certificate(21)는 서버가 중간 인증서 없이 리프만 보냄을 뜻합니다.
• 한 호스트만 실패하고 다른 곳은 되면: 그 호스트의 체인 문제 — 거의 항상 서버의 중간 인증서 누락입니다.
• 모든 HTTPS 호스트에서 실패하면: 문제가 사이트가 아니라 나를 따라다닙니다 — CA 번들 누락/노후 또는 로컬 TLS 가로채기입니다.

Top 3 Causes

1. 서버가 중간 인증서를 안 보냄 - 특정 호스트 하나에서 단연 가장 흔한 원인. 서버가 리프만 제시하고 신뢰된 루트로 이어줄 중간 인증서를 빠뜨립니다. 브라우저는 빠진 중간 인증서를 스스로 가져와 이를 가려주지만, curl은 그러지 않으므로 체인을 완성하지 못하고 오류 60에서 멈춥니다. 해결은 서버에 있습니다 — 리프만이 아니라 풀체인(리프 + 중간)을 배포하세요.
2. CA 번들이 없거나 낡았거나 잘못됨 - curl이 사용하도록 빌드된 신뢰 저장소를 찾거나 읽지 못하면 검증할 대상이 없어 모든 HTTPS 요청이 실패합니다. ca-certificates 패키지를 설치한 적 없는 최소 컨테이너 이미지·갓 프로비저닝한 서버, 또는 curl이 존재하지 않는 경로의 번들을 찾도록 컴파일된 경우의 전형입니다. 루트가 교체됐는데 아주 오래된 번들이 새 루트를 담지 못한 경우에도 물립니다.
3. 프록시나 백신이 TLS를 가로챔 - 회사 미들박스와 ‘HTTPS 검사’ 백신은 트래픽을 복호화해 자기 사설 CA로 재서명합니다. 그 CA는 관리되는 기기에서는 신뢰되지만 기본 curl 번들에는 없으므로, curl은 찾을 수 없는 발급자가 서명한 인증서를 보고 오류 60 — 종종 self signed certificate in certificate chain(19) — 을 냅니다. 관리되지 않는 기기라면 같은 서명이 실제 공격자가 만들어낼 바로 그것이고, curl이 거부하는 이유가 정확히 그것입니다.

Diagnose with DechoNet

• SSL 점검은 서버가 회선으로 보내는 정확한 체인을 보여줍니다 — 중간 인증서가 있는지, 서버가 리프만 보내는지. 여기서 체인이 불완전하면 원인 #1을 확인한 것이고 해결은 서버에 있습니다. 공개 인터넷에서는 체인이 완전한데 내 컴퓨터의 curl만 실패하면, 문제는 로컬입니다: CA 번들 또는 트래픽을 재서명하는 프록시(원인 #2 또는 #3).
• HTTP 점검은 인증서 문제를 잠시 제쳐두고 엔드포인트가 실제로 응답하는지 확인해 줘서, 죽어 있는 호스트에서 신뢰 오류를 쫓지 않게 해줍니다.

Resolution Checklist

• 범위를 먼저 읽으세요. 한 호스트만 실패하고 다른 곳은 됨 → 서버 체인 문제. 모든 호스트가 실패 → 내 번들 또는 로컬 프록시. 이 질문 하나가 해결 경로 전체를 가릅니다.
• 한 호스트라면 제시된 체인을 보세요: curl -v https://YOUR_DOMAIN(인증서 줄을 보기) 또는 openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN -showcerts. CERTIFICATE 블록이 하나만 보이면 중간 인증서가 빠진 것 — 풀체인 번들로 인증서를 다시 설치하세요. SSL 점검을 다시 돌려 중간 인증서가 이제 나타나는지 확인합니다.
• 번들 문제라면 신뢰 루트를 설치/갱신하세요: apt-get install --reinstall ca-certificates / update-ca-certificates(Debian·Ubuntu), 또는 yum reinstall ca-certificates / update-ca-trust(RHEL·Fedora). curl이 기대하는 파일이 실제로 있는지 확인하세요(Debian은 /etc/ssl/certs/ca-certificates.crt, RHEL은 /etc/pki/tls/certs/ca-bundle.crt).
• curl이 확실히 신뢰할 번들을 명시하려면 curl --cacert /path/to/ca-bundle.crt https://YOUR_DOMAIN를 쓰거나, 최신 Mozilla 번들을 https://curl.se/ca/cacert.pem에서 내려받으세요. 검증이 켜진 채로 있으므로 -k와 달리 이것이 올바른 해결입니다.
• 신뢰해야 하는 회사 프록시라면 그 루트를 번들에 추가하세요: 프록시 CA의 PEM을 /etc/ssl/certs/ca-certificates.crt(또는 플랫폼 대응 파일)에 덧붙여 curl이 재서명된 인증서를 검증하게 합니다. 가로채는 CA가 낯설다면 멈추세요 — 무작정 신뢰하지 말고 의심스러운 것으로 취급하세요.
• curl -k를 참으세요. 나를 지키던 바로 그 검증을 끄는 것입니다. 굳이 쓴다면 엔드포인트가 동작하는지 한 번 확인하는 데만 쓰고, 빼낸 뒤 신뢰를 제대로 고치세요.

When to Escalate

• 공개 인터넷에서는 완전하고 올바른 체인이 보이는데 한 기기의 curl만 계속 실패하면, 재서명하는 CA는 그 기기의 네트워크에 있는 것 — 프록시나 백신입니다. 이는 엔드포인트/IT 문제(어느 루트를 신뢰하고 어떻게 배포할지)이지 요청마다 붙이는 플래그가 아닙니다.
• 엔드포인트가 실제로 사설/자체 서명 CA를 쓴다면(내부 서비스·어플라이언스·개발 환경), 올바른 조치는 검증을 끄는 게 아니라 --cacert나 시스템 저장소로 그 특정 CA를 신뢰하는 것입니다. 신뢰 오류를 클릭으로 넘기거나 -k로 스크립트를 우회하는 습관은, 내 진짜 서버와 사칭을 가르는 유일한 신호를 무시하도록 길들입니다.