기술 · 실용 가이드
curl error 60인가요? --insecure 전에 인증서 체인과 신뢰 저장소를 감사하세요
“unable to get local issuer certificate”에는 하나의 만능 해결책이 없습니다. TLS 백엔드, CAfile, CApath, 프록시 경로를 기록한 뒤 서버 체인·클라이언트 신뢰·검사 프록시 중 증명된 경계만 고치세요.
curl error 60은 검증 실패이며 검증을 끄라는 뜻이 아닙니다. 끊긴 고리는 서버가 보낸 체인, curl의 신뢰 입력, 애플리케이션 전용 번들 또는 TLS 검사 프록시에 있을 수 있습니다.
엔드포인트, 체인, 백엔드, 신뢰 입력, 수정 순서로 감사하세요. 증거에 따라 서버, 확인된 사설 CA, 네이티브/파일 저장소 또는 프록시 신뢰를 고칩니다.
실패한 엔드포인트와 curl 빌드 보존
신뢰를 바꾸기 전에 정확한 URL, 호스트, 포트, 사용자, 프록시 변수와 전체 오류를 기록하세요. curl -V로 TLS 백엔드를, curl -v로 CAfile, CApath, 연결 대상과 CONNECT 프록시를 저장합니다. 브라우저 성공은 브라우저의 신뢰 경로만 증명합니다.
실제로 실패한 셸, 컨테이너, 서비스 계정에서 재현하세요. root, PHP, Git, Composer는 서로 다른 설정을 읽을 수 있습니다. -k로 성공해도 검증 경계의 증거일 뿐이므로 즉시 제거하세요.
엔드포인트가 실제로 보낸 체인 검사
SNI를 포함한 정확한 호스트와 포트에서 리프 subject, issuer, 전송된 중간 인증서를 기록하세요. 공개 사이트가 중간을 누락했다면 서버 체인을 고치고 깨끗한 클라이언트로 재검사하세요. 리프를 루트로 신뢰하지 마세요.
TLS 검사 장비가 종료하면 issuer가 조직 CA일 수 있습니다. curl -v와 환경 변수로 경로를 증명하세요. HTTPS 프록시 신뢰는 원본 서버 신뢰와 별도입니다.
이 curl이 쓰는 신뢰 입력 증명
Schannel은 보통 Windows 네이티브 저장소를, 많은 다른 백엔드는 파일 저장소를 씁니다. CURL_CA_BUNDLE, SSL_CERT_FILE, SSL_CERT_DIR, 앱 설정과 컨테이너 마운트를 확인하세요.
--cacert는 확인된 PEM CA에만, --capath는 준비된 디렉터리에만 사용합니다. 지원 빌드와 정책이 맞으면 --ca-native를 사용합니다. Apple에서는 네이티브 신뢰와 사용자 파일을 함께 고려할 수 있습니다.
증거에 맞는 최소 수정 적용
서버가 중간을 누락했으면 서버를 수정합니다. 사설/기업 CA가 의도된 경우 인증된 채널로 fingerprint와 소유자를 확인하고 최소 범위에 신뢰하세요. Ubuntu와 Red Hat은 앵커 위치와 갱신 명령이 다릅니다.
한 애플리케이션만 실패하면 그 CA 경로를, HTTPS 프록시만 실패하면 프록시 전용 CA 설정을 고치세요. 예상치 못한 issuer는 가져오지 말고 에스컬레이션하세요.
검증·범위·롤백 재시험
-k와 임시 재정의를 제거하고 호스트 이름, issuer, 백엔드, CA 입력을 확인한 뒤 실제 앱과 깨끗한 환경을 시험하세요. 일회성 --cacert 성공은 다른 런타임이 같은 파일을 읽는다는 증거가 아닙니다.
실패 증거, 신뢰 변경, CA 소유자, 만료일과 제거 명령을 기록하세요. 서버 수정은 여러 깨끗한 클라이언트에서, 사설 앵커는 제거까지 검증합니다.
