구버전 서버와 최신 JDK 서버, TLS 핸드셰이크 문제 해결기

 

---

이번에 유지보수를 하고 있는 고객사에서 문의가 들어왔다.
10년 전에 우리가 납품했던 솔루션이 아직도 JDK 1.6 + Spring 3 기반으로 잘 돌아가고 있었는데,
상대방 시스템을 업그레이드하면서 JDK를 Zulu OpenJDK 17로 올리려다 보니 문제가 생긴 거다.

우리 쪽은 현실적으로 업그레이드가 불가능했다.
Spring 3는 JDK 11부터 공식적으로 지원하지 않으니, JDK 버전만 올린다고 해결될 게 아니라
사실상 재개발 수준으로 일이 커져버린다.
그래서 결국 결론은 우리 서버는 현 상태 유지, 상대 서버만 JDK 업그레이드 진행으로 정리했다.

근데 여기서 중요한 포인트가 하나 있었다.
바로 JDK 버전 차이로 인한 TLS 통신 문제.

---

TLS Handshake 이슈

HTTPS 통신은 데이터를 주고받기 전에 먼저 TLS Handshake 과정을 거친다.
쉽게 말하면 “우리 어떤 규칙으로 보안 통신할래?” 하고 협상을 하는 절차다.

문제는 여기서 TLS 버전이 안 맞으면 아예 대화 자체가 시작이 안 된다.
서로 다른 언어를 쓰는 것처럼, 악수(Handshake)를 하려 해도 손이 안 맞는 상황인 거다.

• 우리 서버 (WebLogic + JDK 1.6): TLS 1.0 기본
• 상대 서버 (Zulu OpenJDK 17): TLS 1.2 / 1.3 기본, TLS 1.0은 보안 취약점 때문에 비활성화

즉, 지금 상태로는 TLS 버전이 맞지 않아 연결이 끊어질 수밖에 없다.

---

TLS Handshake 과정 다이어그램 ✋🤝✋ 

Client (우리 서버)                          Server (상대방 JDK 17)

   | ---- ClientHello (지원 가능한 TLS 버전 목록) ----> |
   | <--- ServerHello (선택된 TLS 버전 응답) --------- |
   | ---- Certificate (서버 인증서 전달) ------------->|
   | <--- Key Exchange (세션 키 교환) ---------------- |
   | ---- Finished (암호화 시작 준비 완료) ----------> |
   | <--- Finished (암호화 시작 준비 완료) ----------- |

          이후 암호화된 HTTPS 통신 시작 🔒

 

 

 👉 보면 알겠지만, 결국 양쪽이 합의한 TLS 버전으로 내려가야 정상 통신이 가능하다.

근데 지금은 애초에 지원하는 버전 자체가 안 맞으니 손도 못 잡는 상황인 거다.

---

JDK 버전별 TLS 지원 정리 📑

JDK 버전	기본 지원	TLS 버전특징
JDK 1.6	TLS 1.0 (기본)	TLS 1.1/1.2는 추가 패치와 설정 필요
JDK 1.7	TLS 1.0, 1.1	1.2 지원 가능 (업데이트 적용 시 안정적)
JDK 1.8	TLS 1.2 (기본)	가장 널리 사용, TLS 1.3은 불가
JDK 11	TLS 1.2, 1.3	TLS 1.3 지원, 보안 기본값 강화
JDK 17	TLS 1.2, 1.3	최신 보안 표준 준수, 1.0/1.1 기본 비활성화

👉 이 표만 봐도 답이 나온다.
JDK 1.6은 TLS 1.2 이상을 원활하게 쓰기가 어렵고,
JDK 17은 최신 보안 정책 때문에 TLS 1.0/1.1을 아예 막아둔 경우가 많다.

---

TLS가 왜 중요한가? 🔒

“그냥 데이터만 오가면 되는 거 아닌가?” 싶을 수 있는데,
TLS는 사실 보안 통신의 기본 뼈대다.

1. 암호화 (Encryption) → 중간에서 패킷을 훔쳐봐도 내용은 해독 불가
2. 무결성 (Integrity) → 데이터가 전송 중에 변조되지 않았음을 보장
3. 인증 (Authentication) → 내가 통신하는 대상이 진짜 서버가 맞는지 확인

즉, TLS가 안 맞으면 단순히 연결 실패 문제가 아니라
보안적으로 구멍이 크게 뚫린다는 의미다.

---

해결 방법: WebLogic에서 TLS 1.2 켜주기 🛠️

다행히 방법이 아주 없는 건 아니다.
JDK 1.6이라고 해도, 몇 가지 설정을 추가하면 TLS 1.2를 쓸 수 있다.

• JCE Unlimited Strength Policy 설치
• WebLogic JVM 옵션에 프로토콜 강제 지정

예시 옵션:

-Dhttps.protocols=TLSv1.2

 

이렇게 세팅해주면 우리 서버도 TLS 1.2로 통신할 수 있고,
상대방 서버가 JDK 17로 업그레이드되더라도 API 연동은 계속 이어갈 수 있다.

---

이번 경험에서 느낀 점 📝

이번 건으로 확실히 깨달았다.
JDK 업그레이드는 단순히 “버전만 올리면 끝”이 아니라,
TLS 같은 보안 프로토콜 호환성 문제까지 따라온다는 거다.

특히 10년 넘은 구 시스템을 유지보수하는 입장이라면,
상대 시스템이 기술 스택을 바꾸기 전에 TLS 환경부터 확인하는 게 안전하다.

👉 비슷한 상황이 있다면 꼭 체크해라.
“상대 JDK 버전 ↔ 우리 서버 TLS 버전” 이거 먼저 확인하는 게 답이다.