Bitbucket과 Jenkins는 서로 통신하기 위해 Bitbucket 서버에 SSL 인증서를 설치했습니다. 문제는 Jenkins 팀이 구성을 엉망으로 만들고 SSL 인증서를 변경하여 Bitbucket과 Jenkins 간의 통신을 방해하면서 시작되었습니다. 한 달 안에 이런 일이 자주 발생합니다.
새 인증서가 변경될 때마다 자동으로 설치하는 작업이 할당되었습니다. 즉, URL 인증서와 서버 키 저장소의 인증서를 확인하고 차이가 있는 경우 최신 인증서를 가져올 수 있도록 경고합니다.
그래서 이것이 제가 한 일입니다. 다음 명령을 사용하여 키 저장소에서 SSL 인증서를 받았습니다.
keytool -export -alias jenkins -file jenkins.der -keystore keystore.path
openssl x509 -inform der -in jenkins.der -out jenkins.crt
그런 다음 SSL 인증서는 openssl 명령에서 검색됩니다. 브라우저 URL에서 가져온 것으로 가정합니다.
openssl s_client -connect jenkins:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > jenkins_new.crt
나중에 비교해 보니 파일들 사이에 몇 줄의 차이가 있었습니다. SSL 인증서는 마지막 가져오기 이후 변경되지 않았는데, 설치된 SSL과 브라우저의 SSL의 차이점은 무엇입니까?
내가 뭘 잘못하려고 하는 걸까?
답변1
요점은 인증서가 설치된 위치가 한 곳이 아니라 두 곳이기 때문에 혼란이 발생한다는 것입니다. 또는 설정에 따라 두 개의 서로 다른 인증서도 있습니다(그러나 대부분 동일한 인증서가 두 위치에 모두 설치됨).
특히 실제로는 두 가지 인증서 "저장소" 세트, 즉 Java의 애플리케이션 인증서 키 저장소(백엔드)와 시스템/웹 서버(프런트엔드)의 인증서 구성이 있습니다.
일반적으로 새 인증서를 설치할 때 두 위치에서 업데이트해야 합니다.
Java 키 저장소를 다루고 있음을 보여주었으므로(예: 명령 사용 keytool) 시스템/네트워크 서버 측도 살펴봐야 합니다.
프런트 엔드 웹 서버가 Apache라고 가정하면 일반적으로 인증서 파일 시스템의 위치를 가리키는 ssl.conf지시문( 및 )을 사용하여 구성 됩니다.vhostSSLCertificateFileSSLCertificateKeyFile
그러나 귀하가 개발 팀 출신이라고 가정하면 로컬 시스템 관리자와 친근한 대화를 나누는 것이 좋습니다. 웹 서버/Linux 측에서 인증서를 구성하는 방법을 지적할 수 있어야 합니다.
PS 웹 프런트엔드와 애플리케이션 백엔드는 동일한 VM/서버에 있을 수도 있고 다른 VM/서버에 있을 수도 있습니다.