서론

SSL 연결 문제는 WebLogic 서버에서 발생할 수 있는 주요 보안 문제 중 하나입니다. SSL 인증서 설정 또는 프로토콜 호환성 문제로 인해 SSL 연결이 실패할 수 있으며, 이를 진단하기 위해 javax.net.debug=ssl 옵션을 사용하여 SSL 통신을 디버깅할 수 있습니다. 이 글에서는 WebLogic에서 Djavax.net.debug=ssl 설정을 활성화하고, 디버깅 로그를 확인하는 방법을 설명합니다.

본론

SSL 디버깅 활성화 방법

1. Djavax.net.debug=ssl 설정 추가

WebLogic 서버에서 SSL 디버깅을 활성화하려면 서버 시작 시 Java 옵션에 Djavax.net.debug=ssl 설정을 추가해야 합니다. 이는 WebLogic 서버의 시작 스크립트나 관리 콘솔을 통해 설정할 수 있습니다.

a. WebLogic 서버 시작 스크립트 수정

WebLogic 서버가 시작될 때 실행되는 startWebLogic.sh 또는 setDomainEnv.sh 파일을 수정하여, 다음 옵션을 추가합니다.

JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.net.debug=ssl"
export JAVA_OPTIONS

이 설정을 추가한 후 WebLogic 서버를 다시 시작하면 SSL 관련 디버깅 로그가 생성됩니다.

b. WebLogic 관리 콘솔에서 설정

WebLogic 관리 콘솔을 통해 SSL 디버깅을 활성화할 수도 있습니다. 관리 콘솔에서 서버를 선택한 후, 서버 시작 옵션에서 다음 Java 옵션을 추가합니다.

  1. WebLogic 관리 콘솔에 로그인
  2. 서버 -> 서버 이름 선택
  3. 서버 시작 탭으로 이동
  4. Java 옵션에 -Djavax.net.debug=ssl 추가
  5. 저장 후 서버를 다시 시작

2. SSL 디버깅 모드 옵션

SSL 디버깅을 더 세밀하게 하기 위해, 다음과 같은 추가 옵션을 사용할 수 있습니다.

  • -Djavax.net.debug=ssl: 기본 SSL 디버깅 정보를 출력
  • -Djavax.net.debug=ssl:handshake: 핸드셰이크 과정에 대한 디버깅 정보만 출력
  • -Djavax.net.debug=ssl:record: 레코드 레벨에서의 SSL 정보 출력
  • -Djavax.net.debug=all: SSL 디버깅을 포함한 모든 관련 정보를 출력

디버깅 로그 확인 방법

WebLogic 서버가 재시작되고 나면 SSL 관련 디버깅 로그는 WebLogic의 일반 로그 파일에 기록됩니다. 로그 파일의 위치는 서버 설정에 따라 다를 수 있으며, 기본적으로 다음 위치에 저장됩니다.

  • 관리 서버 로그: ${DOMAIN_HOME}/servers/AdminServer/logs/AdminServer.log
  • 개별 관리 서버 로그: ${DOMAIN_HOME}/servers/{ServerName}/logs/{ServerName}.log

로그 파일에서 SSL 관련 디버깅 정보는 javax.net.debug 설정에 따라 상세하게 기록되며, 특히 SSL 핸드셰이크 과정이나 인증서 문제와 관련된 정보를 확인할 수 있습니다.

로그 예시

다음은 SSL 디버깅 로그의 샘플입니다. SSL 핸드셰이크 과정에서 발생한 문제를 디버깅할 때 유용합니다.

trigger seeding of SecureRandom
done seeding SecureRandom
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1630601204 bytes = { 122, 64, 85, 102, 105, 33, 64, 92, 86, 12, 87, 1, 78, 42, 9, 84, 69, 21, 71, 79, 89, 90, 32, 73, 101, 88, 19, 23 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, ...]
Compression Methods:  { 0 }
***
main, WRITE: TLSv1.2 Handshake, length = 226
main, READ: TLSv1.2 Handshake, length = 74
*** ServerHello, TLSv1.2
...
main, WRITE: TLSv1.2 Handshake, length = 425
main, WRITE: TLSv1.2 Change Cipher Spec, length = 1
main, WRITE: TLSv1.2 Handshake, length = 16
main, READ: TLSv1.2 Change Cipher Spec, length = 1
main, READ: TLSv1.2 Handshake, length = 16

이 로그는 SSL 통신 과정 중 핸드셰이크 단계에서 발생한 세부 정보를 포함하고 있습니다. 이를 통해 인증서 교환, 암호화 방식 선택, SSL 통신 실패 원인 등을 분석할 수 있습니다.

디버깅 로그에서 확인할 수 있는 주요 사항

1. SSL 핸드셰이크 실패

SSL 핸드셰이크 과정에서 클라이언트와 서버가 상호 인증에 실패하면, 핸드셰이크가 중단되고 로그에 오류가 기록됩니다. 주로 잘못된 인증서나 신뢰할 수 없는 CA로 인해 발생할 수 있습니다.

*** ClientHello, TLSv1.2
...
main, WRITE: TLSv1.2 Handshake, length = 512
main, READ: TLSv1.2 Handshake, length = 1456
main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

위 로그에서 클라이언트가 핸드셰이크 시도 중 “handshake_failure” 경고를 받아 SSL 핸드셰이크가 실패한 것을 확인할 수 있습니다.

2. 프로토콜 불일치

클라이언트와 서버 간에 사용 중인 SSL/TLS 프로토콜 버전이 호환되지 않는 경우 발생합니다. 예를 들어 서버가 TLSv1.2만 지원하는데 클라이언트가 TLSv1.0을 사용하려고 할 때 문제가 생길 수 있습니다.

*** ClientHello, TLSv1
main, WRITE: TLSv1 Handshake, length = 125
main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, protocol_version
javax.net.ssl.SSLException: Received fatal alert: protocol_version
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
	at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2011)

이 로그는 클라이언트가 TLSv1을 사용하려고 했지만, 서버는 TLSv1.2 이상을 요구하여 “protocol_version” 오류가 발생한 상황을 보여줍니다.

3. 인증서 문제

서버 또는 클라이언트가 유효하지 않은 인증서를 제공하거나 신뢰할 수 없는 인증 기관(CA)에 의해 서명된 인증서를 제공할 경우 SSL 핸드셰이크가 실패할 수 있습니다. 다음은 만료된 인증서로 인해 발생한 로그 예시입니다.

*** ServerHelloDone
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=example.com, OU=IT, O=Example Corp, L=Seoul, ST=Seoul, C=KR
  Validity: [From: Mon Sep 20 12:00:00 KST 2021, To: Tue Sep 20 12:00:00 KST 2022]
  Issuer: CN=ExampleCA, OU=Certification, O=ExampleCA, C=KR
]
main, WRITE: TLSv1.2 Handshake, length = 150
main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, certificate_expired
javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_expired

위 로그는 서버가 만료된 인증서를 제공했기 때문에 SSL 핸드셰이크가 실패한 예시입니다. certificate_expired 경고로 인해 SSL 연결이 종료됩니다.

결론

WebLogic에서 SSL 관련 문제를 디버깅하기 위해 Djavax.net.debug=ssl 설정을 활성화하면, SSL 통신 과정에 대한 상세한 로그를 확인할 수 있습니다. 이를 통해 SSL 핸드셰이크 실패, 프로토콜 호환성 문제, 인증서 유효성 등의 문제를 파악하고 해결할 수 있습니다. SSL 디버깅을 통해 정확한 문제 원인을 분석하고 필요한 조치를 취하는 것이 중요합니다.

참고자료

태그:

카테고리:

업데이트:

댓글남기기

참고

Podman의 Pod 소개 및 사용법

Podman은 Kubernetes의 Pod 개념을 빌려와 좀 더 유연한 컨테이너 관리를 제공합니다. Pod라는 개념을 사용해 다수의 컨테이너를 논리적으로 묶어 관리할 수 있습니다. Kubernetes에서 사용하는 Pod와 유사하게, Podman의 Pod는 여러 컨테이너가 같은 네...

Podman 개요, 설치 방법 및 기본 명령어 소개

컨테이너 기반의 애플리케이션 배포는 최근 몇 년간 IT 업계에서 매우 중요한 기술로 자리 잡았습니다. Docker는 이러한 컨테이너 기술의 선두주자였지만, Docker Daemon에 대한 의존성 및 라이선스 문제로 인해 많은 대안이 등장했습니다. 그 중 하나가 바로 Podman입니...

Google TrendReq 사용법 및 예제코드

서론 데이터 분석이 점점 중요해지는 오늘날, 사용자들이 어떤 주제에 관심을 가지고 있는지 파악하는 것은 매우 유용합니다. Google Trends는 특정 키워드에 대한 검색 트렌드를 분석할 수 있는 유용한 도구입니다. 이를 Python에서 활용할 수 있게 해주는 라이브러리가 바로 ...

Docker 컨테이너 실행 시 CPU, 메모리 자원 제약하는 방법

Docker는 컨테이너 기술을 통해 애플리케이션을 가볍고 빠르게 배포할 수 있는 장점을 제공합니다. 그러나 서버의 리소스를 효율적으로 관리하지 않으면 컨테이너가 과도한 자원을 사용하여 다른 애플리케이션에 영향을 줄 수 있습니다. 이를 방지하기 위해 Docker 컨테이너의 CPU와 ...