1. 서론
회사 내부망에서 Jenkins 환경을 처음 구성할 때, 플러그인 설치나 외부 의존성 다운로드 중 다음과 같은 에러 로그를 자주 마주하게 됩니다.
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
이 에러는 SSL 인증서 검증 과정에서 신뢰할 수 있는 인증 경로를 찾지 못해 발생하는 문제입니다. 구글 검색이나 여러 블로그 글에서는 대체로 skip-certificate-check 플러그인을 활성화하면 해결된다고 안내합니다.
하지만, 정말 이 플러그인을 사용하는 것이 최선일까요?
이번 글에서는 skip-certificate-check 플러그인의 역할과 SSL 인증서 문제의 원인, 그리고 보안상 고려해야 할 점을 함께 살펴보겠습니다.
2. Jenkins의 skip-certificate-check 플러그인이란?
skip-certificate-check 플러그인은 Jenkins가 외부 HTTPS 리소스에 접속할 때 SSL 인증서 검증을 우회하는 역할을 합니다.
즉, Jenkins가 플러그인 설치나 업데이트 시 인증서가 유효하지 않더라도 다운로드를 허용하는 것입니다.
내부망에서 자체 서명된 인증서를 사용하거나 인증서 체인이 완전하지 않은 환경에서는 임시로 도움이 됩니다.
3. SSL 인증서 문제로 설치 실패하는 원인
SSL 오류가 발생하는 대표적인 원인은 다음과 같습니다:
- 자체 서명된 인증서 사용
- 인증서 만료
- 불완전한 인증서 체인 (중간 인증서 누락)
- 호스트 이름 불일치
- 신뢰할 수 없는 인증기관(CA)
- 네트워크 프록시 또는 보안장비에 의한 SSL 트래픽 변조
이러한 문제 때문에 Jenkins가 원격 서버의 인증서를 신뢰하지 않아 설치가 실패합니다.
4. HTTP vs HTTPS 다운로드 센터 URL 문제
- HTTP URL은 암호화되지 않아 보안상 취약하며, 최신 Jenkins는 HTTP를 제한하거나 권장하지 않습니다.
- HTTPS URL은 보안성이 뛰어나지만 인증서 문제가 생길 수 있으며, 내부망 사설 CA 인증서를 Jenkins가 신뢰하도록 설정해야 합니다.
5. skip-certificate-check 플러그인과 curl -k 옵션 비교
Jenkins의 skip-certificate-check 플러그인은 다운로드 센터 URL이 HTTPS일 때 SSL 인증서 검증을 우회하는 역할을 합니다.
즉, 이 플러그인은 URL을 HTTP로 변경하는 게 아니라, HTTPS 접속 시 발생하는 인증서 검증 오류를 무시하도록 Jenkins 내부 SSL 검증 로직을 조작하는 것입니다.
반면에, 단순히 다운로드 센터 URL을 HTTP로 바꾸면 아예 암호화되지 않은 평문 통신이 되므로 보안상 취약하고, 최신 Jenkins는 HTTP 사용을 제한하거나 경고를 띄울 수 있습니다.
따라서 skip-certificate-check 플러그인은
- HTTPS 프로토콜을 유지한 채,
- SSL 인증서가 신뢰되지 않아 발생하는 오류를 건너뛰어 연결을 허용하는 우회 수단입니다.
이 점에서 curl의 -k 옵션과 기능적으로 매우 유사하며, 둘 다 인증서 검증을 무시하고 HTTPS 연결을 시도합니다.
6. SSL 인증 우회 시 발생할 수 있는 문제점
- 중간자 공격(MITM)에 취약해질 수 있습니다.
- 플러그인 파일 변조 및 보안 사고 위험이 커집니다.
- 보안 정책 위반 및 컴플라이언스 문제를 일으킬 수 있습니다.
- Jenkins 시스템의 신뢰도가 떨어집니다.
7. 결론 및 권장 사항
javax.net.ssl.SSLHandshakeException 에러가 발생해 skip-certificate-check 플러그인을 활성화하는 것은 간단한 해결책이지만, 장기적이고 근본적인 해결책은 아닙니다.
사설 인증서를 신뢰하도록 Jenkins 및 Java 환경을 설정하거나, 신뢰받는 인증기관에서 발급한 인증서를 사용하는 것이 바람직합니다.
보안 리스크를 잘 인지한 상태에서 임시방편으로만 사용하는 것을 추천하며, 가능하면 SSL 인증서 문제를 정확히 해결하는 방향으로 접근해야 합니다.
참고 문서 및 링크
'Infra' 카테고리의 다른 글
로그를 작성하는 기준이 있나요? "인포는 인포용, 디버그는 디버그용이요.." (2) | 2025.05.30 |
---|---|
WSL2에서 Cockpit 환경 실습하기: systemd 설정부터 접속까지 (0) | 2025.05.30 |
LightSwitch 서비스 인프라 트러블 슈팅 - Docker Network (0) | 2024.05.28 |