기술 · 실용 가이드
curl 오류 77? 인증서를 바꾸기 전에 실패한 CA 파일·디렉터리를 증명하세요
오류 77은 curl이 선택된 CA 인증서 위치를 읽지 못했다는 뜻입니다. 바이너리, TLS 백엔드, 재정의와 실제 경로를 확인하고 경로 통과, 바이트와 저장소 구조를 검사한 뒤 한 입력만 복구하고 insecure 없이 재시험하세요.
curl 오류 77은 로컬 신뢰 저장소 로딩 실패이며 원격 서버 인증서가 잘못됐다는 증거가 아닙니다. curl 공식 참조는 SSL CA 인증서 위치를 읽는 문제로 범위를 좁힙니다.
--insecure, chmod 777 또는 임의 번들 다운로드부터 하지 마세요. 실제 curl과 TLS 백엔드, 선택된 파일 또는 디렉터리, 그 위치를 읽지 못하는 이유를 먼저 증명해야 합니다.
1. 실제 실패 런타임을 캡처하세요
실행 파일 경로, curl 버전과 TLS 백엔드, 비밀을 제거한 명령, 종료 코드, 작업 디렉터리, 사용자 또는 서비스 ID, 컨테이너 이미지와 래퍼를 기록하세요. 셸 curl, PHP 확장, Python 바인딩과 내장 libcurl은 서로 다른 빌드와 설정을 사용할 수 있습니다.
전체 오류 줄과 자세한 시작 출력을 저장하되 자격 증명은 제거하세요. Authorization, Cookie, 서명 쿼리, 클라이언트 키 또는 내부 호스트명을 공개하지 마세요. 실패 프로세스가 표시한 CAfile과 CApath는 증거입니다.
2. 옵션과 환경 변수 우선순위를 푸세요
명시적 --cacert·--capath, 애플리케이션 설정, CURL_CA_BUNDLE, SSL_CERT_FILE, SSL_CERT_DIR을 나열하고 실제 빌드 기본값과 비교하세요. 같은 서비스, 컨테이너 또는 CI 단계 안에서 검사해야 합니다. 대화형 셸은 환경이 다를 수 있습니다.
아직 바꾸지 마세요. 선택된 입력과 출처를 명령 옵션, 래퍼 설정, 환경 변수, 네이티브 저장소 또는 컴파일 기본값 표에 적으세요. 두 계층이 충돌하면 의도하지 않은 재정의만 제거하고 한 번 통제 요청을 실행하세요.
3. 경로 통과와 파일 정체성을 증명하세요
실패 사용자로 각 디렉터리 구성 요소와 최종 객체를 검사하세요. 파일이 읽혀도 상위 디렉터리를 통과하지 못하거나 심볼릭 링크가 샌드박스 밖을 가리키거나 바인드 마운트가 없거나 정책이 대상을 막으면 실패합니다. 해석 경로, 소유자, 모드, 크기, 다이제스트와 경계를 기록하세요.
chmod 777을 진단 지름길로 쓰지 마세요. 권한만 과도하게 넓히며 누락 마운트, 빈 번들, 잘못된 파일 유형, 손상 PEM 또는 샌드박스 거부를 고치지 못합니다. 경계를 찾은 뒤 최소 권한으로 되돌리세요.
4. CAfile 또는 CApath 구조를 검증하세요
CAfile에서는 디렉터리, PKCS#12, 0바이트 파일 또는 인증서 번들로 가장한 HTML을 제외하세요. OpenSSL은 PEM 인증서 블록을 요구하고 검증 위치를 로딩할 때 파일을 처리합니다. 시스템 관리 번들을 교체하기 전에 복사본을 파싱하세요.
OpenSSL CApath에서는 인증서 파일에 해시 조회 레이아웃이 필요합니다. 대상 디렉터리에 플랫폼에 맞는 rehash 도구를 실행하고 생성된 링크를 확인하세요. PEM 파일만 있고 필수 이름이 없는 디렉터리는 필요할 때 인증서를 제공하지 못할 수 있습니다.
5. 한 계층만 복구하고 안전한 시험으로 닫으세요
오래된 재정의 제거, 패키지 관리 번들 복원, 마운트 경로 수정, 신뢰 배포원에서 빈 파일 교체, PEM 수정 또는 해시 디렉터리 재구성 중 좁은 원인만 고치세요. 손상이나 이미지 빌드를 조사한다면 이전 파일과 패키지 로그를 보존하세요.
같은 런타임과 목적지에서 --insecure 없이 재시험하세요. 종료 코드 0, TLS 검증 성공, 의도한 CA 소스, 예기치 않은 번들 폴백 없음이 필요합니다. 실제 래퍼나 서비스도 시험하고 수정된 경로, 소유자, 바이트, 다이제스트와 설정 출처를 기록하세요.
