디버깅 기록 - JDK 배포판 확인의 중요성

여느때와 다름없이 평범한 조회 API 구현 후 개발 배포를 진행했다. 흠.. 하지만 로컬 환경과 또 뭐가 다른건지 다음과 같은 오류를 만났다.

Failed to obtain JDBC Connection; nested exception is com.microsoft.sqlserver.jdbc.SQLServerException:
The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption.
Error: "Certificates do not conform to algorithm constraints"

기존 개발 서버에서는 동일한 코드와 설정으로 문제가 없었지만, 신규 개발 서버에서만 위와 같은 오류가 발생했다. 문제의 원인을 분석한 결과, 기존 서버와 신규 서버에서 사용된 Java 버전은 동일했지만(JDK 17), JDK의 벤더(vendor)가 달라 발생한 문제임을 확인했다. JDK 배포판 별 차이점을 기록해두고자 이 글을 작성하게되었다.

---

🔍 오류 원인 분석

1. Java의 보안 정책 차이

   • 기존 서버: Oracle JDK 사용
   • 신규 서버: Red Hat OpenJDK 사용
   • 두 JDK는 동일한 버전(17.0.x)이었지만, 각 벤더의 java.security 파일 내 보안 설정(jdk.tls.disabledAlgorithms)이 달랐습니다.
   • Red Hat OpenJDK는 더 엄격한 보안 정책을 적용하여 특정 암호화 알고리즘(DH 키 크기 제한, ECDH 등)을 기본적으로 비활성화했습니다.

2. SQL Server 인증서와 Java 보안 정책의 불일치

   • SQL Server에서 사용하는 SSL 인증서가 Java 보안 정책에서 허용하지 않는 알고리즘(예: DH keySize < 1024 또는 EC keySize < 224)을 포함하고 있었습니다.
   • Oracle JDK는 해당 알고리즘을 허용했지만, Red Hat OpenJDK는 이를 허용하지 않아 연결이 거부되었습니다.

---

📊 Oracle JDK vs OpenJDK 비교

항목	Oracle JDK	OpenJDK
라이선스	상업용 라이선스 (유료)	오픈소스 (GPL v2 + Classpath Exception)
보안 업데이트 주기	정기적이고 예측 가능한 업데이트 제공	커뮤니티 기여에 따라 업데이트 주기가 다름
보안 정책	상대적으로 유연	더 엄격한 기본 보안 정책 적용
성능 최적화	엔터프라이즈 환경에 맞춘 추가 최적화 제공	표준 JVM 성능 유지
지원 및 유지보수	Oracle의 공식 지원 제공	커뮤니티 또는 벤더별 지원
비용	상업적 사용 시 유료	무료

---

🚀 결론 및 교훈

• 동일한 Java 버전이라도 벤더에 따라 보안 정책과 설정이 다를 수 있습니다. 특히 java.security 파일 내의 설정은 벤더별로 차이가 있으므로 주의해야 합니다.
• 신규 서버를 설정할 때 기존 환경과 동일한 JDK 벤더를 사용하는 것이 예상치 못한 문제를 방지하는 데 효과적입니다.

이번 이슈를 해결하며 운영 중인 서비스의 JDK 선택이 얼마나 중요한지 깨닳았다.