HockeyApp이라는 클라우드 애플리케이션에서 액세스하려는 Debian 서버에서 실행 중인 Jira 인스턴스가 있습니다. 문제는 HockeyApp이 Jira의 프로젝트 목록에 액세스하려고 할 때 발생합니다(오류 없이 실패함). 그래서 Jira API를 확인하고 HockeyApp 백엔드에서 호출될 것으로 예상되는 메서드를 찾았습니다.
Chrome을 사용하여 API에 액세스하면 https://jira.company.com/rest/api/latest/project예상 결과가 json으로 표시됩니다. 하지만 Postman, 컬 또는 httpie에서 이 API를 호출하려고 하면 매번 오류가 발생합니다.
컬은 나에게 말한다 :
컬: (60) SSL 인증서 문제: 로컬 발급자 인증서를 얻을 수 없습니다. 자세한 내용은 여기를 참조하세요.https://curl.haxx.se/docs/sslcerts.html
컬이 서버의 적법성을 확인하지 못하여 보안 연결을 설정할 수 없습니다. 이 상황과 해결 방법에 대해 자세히 알아보려면 위에 언급된 웹페이지를 방문하세요.
그래서 최신 cacert-2018-10-17.pem 파일을 다운받아서 다시 시도해보았습니다. 행운이 없습니다. -kSSL 확인을 무시하는 옵션을 추가하면 예상한 결과를 얻을 수 있습니다.
우체부가 나에게 이렇게 말한다.
postman 설정에서 SSL 확인을 끄면 예상한 결과를 얻을 수 있습니다. 그러나 서버는 자체 서명된 SSL 인증서를 사용하지 않습니다. 인증서는 다음과 같습니다.
인증서는 모든 브라우저, Bitbucket 및 Confluence와 같은 기타 연결된 애플리케이션에서 제대로 작동합니다.
이 문제의 원인을 어떻게 알 수 있나요?
답변1
더 많은 조사 끝에 마침내 문제의 원인이 무엇인지 알아냈습니다.
Wireshark를 사용하여 cURL에서 REST 호출을 실행할 때 네트워크 트래픽을 조사하기 시작하여 인증서가 실제로 잘못되었음을 확인했습니다. 단지 Chrome에서는 신경 쓰지 않습니다.
그래서 다음을 사용하여 인증서를 확인했습니다.
openssl s_client -showcerts -connect jira.company.com:443
이는 다음과 같이 응답합니다.
Start Time: 1544006181
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
그래서 마침내 내 서버에서 사용되는 인증서가 전체 인증 체인을 제공하지 않는다는 것을 알게 되었습니다. 그래서 일부 고객은 이를 거부합니다.
crt 파일을 하나의 company.com.pem 파일에 복사하는 전체 체인을 포함하도록 JKS를 변경했습니다. 자세한 내용은 여기를 참조하세요.https://www.digicert.com/ssl-support/pem-ssl-creation.htm)
-----BEGIN CERTIFICATE-----
(MyCompany.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root.crt)
-----END CERTIFICATE-----
다음을 사용하여 jira 설치를 위한 새로운 JKS를 생성했습니다.
openssl pkcs12 -export -in company.com.pem -name tomcat -out jira.p12
keytool -importkeystore -srckeystore jira.p12 -srcstoretype pkcs12
-destkeystore jira.jks -deststoretype JKS