[WebSphere Liberty] securityUtility로 SSL 인증서 생성 및 AES 패스워드 암호화 설정 가이드

WebSphere Liberty의 securityUtility 도구를 사용하여 자체 서명된(Self-Signed) SSL 인증서를 생성하고, 보안성을 높이기 위해 Keystore 비밀번호를 AES로 암호화하여 설정하는 방법을 정리합니다.

0. 배경 및 시나리오 (Context)

Liberty 서버는 기본적으로 개발 편의를 위해 SSL 설정을 자동화하지만, 운영 환경에서는 명시적인 인증서 관리와 비밀번호 보안이 필수적입니다. securityUtility를 사용하면 인증서 생성과 비밀번호 암호화(Encoding)를 동시에 수행할 수 있습니다.

Test Environment

• Middleware: WebSphere Liberty Profile (WLP)
• Server Name: s11, s12

---

1. SSL 인증서 생성 및 암호화 (Create Certificate)

securityUtility createSSLCertificate 명령어를 사용하여 키스토어(PKCS12)를 생성합니다. 이때 --passwordEncoding=aes 옵션을 사용하여 설정 파일에 들어갈 비밀번호를 암호화합니다.

명령어 구문

# 구문: securityUtility createSSLCertificate --server=[서버명] --password=[키패스워드] --validity=[유효기간일수] --passwordEncoding=aes --passwordKey=[암호화키]

cd $WLP_HOME/bin
./securityUtility createSSLCertificate --server=s11 --password=passw0rd --validity=7300 --passwordEncoding=aes --passwordKey=passw0rd

실행 결과

키 저장소 /sw/was/WebSphere/wlp/usr/servers/s11/resources/security/key.p12을(를) 작성하는 중입니다.

서버 s11에 대한 SSL 인증서를 작성했습니다. 
이 인증서는 CN=testwas11,OU=s11을(를) 사용하여 SubjectDN으로 작성되었습니다.

Tip: 여기서 생성된 키스토어 파일(key.p12)은 usr/servers/[서버명]/resources/security/ 경로에 저장됩니다.

---

2. 서버 설정 적용 (server.xml)

위에서 생성된 인증서를 서버가 사용하도록 server.xml을 수정합니다. 이때 비밀번호 부분에 {aes}... 로 시작하는 암호화된 문자열을 입력해야 합니다.

<server description="SSL Server">

    <!-- 1. SSL 기능 활성화 -->
    <featureManager>
        <feature>transportSecurity-1.0</feature>
    </featureManager>

    <!-- 2. Keystore 정의 (비밀번호는 암호화된 값 사용) -->
    <keyStore id="defaultKeyStore" 
              location="key.p12"
              password="{aes}AJS+VEek/Fgo/zp46z8cuIUMTbnMM7sJVmPPbT49n4s6" />

</server>

---

3. 암호화 키 등록 (bootstrap.properties)

server.xml에 적힌 {aes} 비밀번호를 서버가 복호화하려면, 암호화할 때 사용했던 Key를 서버에 알려주어야 합니다. 이 설정은 bootstrap.properties 파일에 저장합니다.

• 파일 위치: usr/servers/[서버명]/bootstrap.properties

# securityUtility 실행 시 --passwordKey 옵션에 넣었던 값
wlp.password.encryption.key=passw0rd

주의: 이 설정이 누락되면 서버 기동 시 CWWKS1704E: 비밀번호를 복호화할 수 없습니다. 에러가 발생합니다.

---

4. 인증서 검증 (Verification)

생성된 키스토어 파일이 정상적인지, 유효기간은 맞는지 확인하기 위해 JDK에 포함된 keytool 명령어를 사용합니다.

검증 명령어

# keytool -list -v -keystore [파일경로] -storetype PKCS12 -storepass [비밀번호]
./keytool -list -v -keystore /sw/was/WebSphere/wlp/usr/servers/s12/resources/security/key.p12 -storetype PKCS12 -storepass passw0rd

출력 결과 분석

키 저장소 유형: PKCS12
키 저장소 제공자: SUN

별칭 이름: default
생성 날짜: 2024. 6. 12.
항목 유형: PrivateKeyEntry
인증서 체인 길이: 2

# 유효기간 확인
적합한 시작 날짜: Wed Jun 12 16:47:57 KST 2024 
종료 날짜: Tue Jun 07 16:47:57 KST 2044 (약 20년)

# 소유자 및 서명 알고리즘 확인
소유자: CN=testwas11, OU=s12, O=ibm, C=us
서명 알고리즘 이름: SHA256withRSA
주체 공용 키 알고리즘: 2048비트 RSA 키

---

Next Step:
자체 서명 인증서(Self-Signed)는 브라우저에서 경고가 발생하므로, 운영 환경에서는 CSR을 생성하여 공인 인증기관(CA)의 서명을 받은 후 keytool -import 명령어로 교체해야 합니다.

[JBoss EAP 7] 보안 헤더 숨기기: Server 및 X-Powered-By 정보 노출 방지 (Undertow Filter 설정)

JBoss EAP 7.4 (Undertow)의 HTTP 응답 헤더에 노출되는 서버 버전 정보(Server: JBoss-EAP/7, X-Powered-By: JSP/2.3)를 제거하거나 변경하여 보안성을 강화하는 방법을 정리합니다. CLI 명령어를 이용한 JSP 설정 변경과 필터(Filter) 적용 방법을 다룹니다.

1. 문제 현상 (Issue)

기본 설정 상태에서 JBoss EAP 7.4는 응답 헤더에 구체적인 미들웨어 정보를 노출합니다. 이는 공격자에게 서버 정보를 제공하는 단서가 되므로 보안 취약점으로 분류됩니다.

노출되는 헤더 예시

HTTP/1.1 200 OK
X-Powered-By: Undertow/1
X-Powered-By: JSP/2.3
Server: JBoss-EAP/7
...

2. 해결 방법 (Resolution Plan)

조치는 크게 두 단계로 나뉩니다. ① JSP 엔진이 자동으로 붙이는 헤더 비활성화, ② Undertow 필터를 사용하여 Server 헤더 덮어쓰기입니다.

Step 1: X-Powered-By (JSP) 비활성화

서블릿 컨테이너 설정에서 JSP 엔진이 해당 헤더를 생성하지 못하도록 설정합니다.

[JBoss CLI 명령어]

# JSP 설정의 x-powered-by 속성을 false로 변경
/subsystem=undertow/servlet-container=default/setting=jsp:write-attribute(name=x-powered-by,value=false)

# 설정 적용을 위한 리로드 (필요시)
reload

확인: 관리 콘솔에서도 Configuration > Subsystems > Undertow > Servlet Container > JSP 항목에서 X-Powered-By 체크박스가 해제된 것을 확인할 수 있습니다.

---

Step 2: Server 헤더 변경/삭제 (Undertow Filter)

Server 헤더는 엔진 레벨에서 붙는 경우가 많아 아예 삭제가 어렵다면, 필터(Filter)를 통해 무의미한 값으로 덮어쓰는(Override) 방식을 사용합니다.

[JBoss CLI 명령어]

# 1. 헤더 변경용 필터 생성 (이름: server-header, 값: "Apache" 또는 빈 값)
/subsystem=undertow/configuration=filter/response-header=server-header:add(header-name="Server", header-value="Apache")

# 2. X-Powered-By (Undertow) 헤더 제거 필터 생성 (필요 시)
/subsystem=undertow/configuration=filter/response-header=x-powered-by-header:add(header-name="X-Powered-By", header-value="Unknown")

# 3. 생성한 필터를 기본 호스트(default-host)에 적용
/subsystem=undertow/server=default-server/host=default-host/filter-ref=server-header:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=x-powered-by-header:add

Tip: header-value에 빈 값("")을 넣거나 일반적인 웹 서버 이름("Webserver")을 넣어 공격자에게 혼동을 줄 수 있습니다.

---

3. 조치 결과 확인 (Verification)

설정 적용 후 curl 명령어나 브라우저 개발자 도구를 통해 응답 헤더가 변경되었는지 확인합니다.

변경 전후 비교

헤더(Header)	변경 전 (Before)	변경 후 (After)
Server	JBoss-EAP/7	Apache (설정한 값)
X-Powered-By	JSP/2.3, Undertow/1	(삭제됨) 또는 Unknown

[그림] 조치 후 헤더 정보 노출 테스트 결과

[WebSphere] native_stderr 로그 비대화 해결: Verbose GC 로그 분리 및 로테이션 설정

WebSphere의 native_stderr.log 파일에는 로테이션(Rotation) 기능이 내장되어 있지 않습니다. 따라서 Verbose GC가 활성화된 경우 파일 용량이 무한정 증가합니다. 이를 해결하기 위해 JVM 옵션을 사용하여 GC 로그를 별도 파일로 분리하고 순환시키는 방법을 정리합니다.

1. 원인 분석 (Root Cause)

WebSphere는 SystemOut.log와 SystemErr.log에 대해서는 시간/크기 기반의 로그 순환을 지원합니다. 하지만, JVM 프로세스 자체의 출력을 담는 native 로그는 WAS가 제어하지 못합니다.

• 문제점: 관리 콘솔에서 "Verbose garbage collection"을 체크하면, GC 수행 기록이 native_stderr.log에 누적됩니다.
• 결과: 시간이 지남에 따라 파일이 GB 단위로 커지며, 디스크 Full 장애를 유발할 수 있습니다.

Test Environment

• OS: CentOS 7 (3.10.0-957.el7.x86_64)
• WAS: WebSphere Application Server v8.5 / 9.0
• JDK: IBM JDK (WebSphere 기본)

---

2. 해결 방법: GC 로그 분리 설정

해결의 핵심은 native 로그에 GC 내용을 남기지 않고, 별도의 파일로 빼내는 것입니다. 사용하는 JDK 벤더에 따라 옵션이 다릅니다.

Step 1: 기본 Verbose GC 비활성화

JVM 옵션으로 제어하기 위해, 콘솔의 체크박스 옵션은 해제해야 합니다.

• 경로: 서버 > 서버 유형 > WebSphere Application Server > [서버명] > Java 및 프로세스 관리 > 프로세스 정의 > Java 가상 머신
• 조치: Verbose garbage collection 체크박스 해제 (Uncheck)

[그림] 기본 Verbose GC 옵션 해제

Step 2: 일반 JVM 인수(Generic JVM arguments) 추가

같은 화면의 Generic JVM arguments 입력란에 아래 옵션을 추가합니다.

Case A: IBM JDK 사용 시 (WebSphere 기본)

IBM JDK는 -Xverbosegclog 옵션을 사용하여 로그 파일 경로와 로테이션 규칙을 지정합니다.

# 구문: -Xverbosegclog:[경로/파일명][,X,Y]
# X: 파일 개수, Y: 파일당 GC 사이클 수

# 예시 1: 날짜/PID 포함하여 단일 파일 생성 (가장 일반적)
-Xverbosegclog:${SERVER_LOG_ROOT}/gc.%Y%m%d.%H%M%S.%pid.txt

# 예시 2: 10,000 사이클마다 파일 교체, 총 10개 파일 유지 (로테이션)
-Xverbosegclog:${SERVER_LOG_ROOT}/verbosegc.log,10,10000

Case B: Oracle/HotSpot JDK 사용 시

드물지만 Solaris나 특정 환경에서 HotSpot 계열 JDK를 사용하는 경우입니다.

-verbose:gc
-Xloggc:${SERVER_LOG_ROOT}/verbosegc.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=20M
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails

Tip: ${SERVER_LOG_ROOT} 변수를 사용하면 하드코딩된 경로 대신 각 서버의 로그 디렉토리를 자동으로 찾아가므로 관리가 용이합니다.

---

3. 적용 확인 (Verification)

1. 설정 저장 후 서버를 재기동합니다.
2. ps -ef | grep java 명령어로 프로세스를 확인했을 때, 추가한 옵션이 적용되어 있는지 확인합니다.
3. 로그 디렉토리(logs/[서버명]/)에 gc...txt 또는 설정한 이름의 파일이 생성되는지 확인합니다.

---

Next Step:
분리된 GC 로그 파일은 IBM GCMV (Garbage Collection and Memory Visualizer) 도구에 넣어 분석하면 메모리 누수나 튜닝 포인트를 시각적으로 확인할 수 있습니다.

[WebSphere] Log4j 보안 취약점(Log4Shell) 긴급 대응: kc.war 및 uddi.ear 조치 가이드

Apache Log4j 취약점(CVE-2021-44228 등)이 IBM WebSphere Application Server(WAS)에 미치는 영향을 분석합니다. WAS 9.0의 관리 콘솔 도움말(kc.war)과 전 버전의 UDDI 레지스트리(uddi.ear)에 포함된 취약한 라이브러리를 제거하는 임시 조치(Mitigation) 방법을 정리합니다.

1. 영향받는 제품 및 버전 (Affected Products)

사실상 현재 운영 중인 대부분의 WebSphere 버전이 직간접적인 영향권에 있습니다.

제품 (Product)	영향 버전 (Versions)
WebSphere Application Server (Traditional)	9.0, 8.5, 8.0, 7.0
WebSphere Liberty	Continuous Delivery (All)

---

2. 취약점 상세 및 조치 가이드 (Remediation)

WAS 엔진 자체보다는 번들로 제공되는 특정 애플리케이션 내의 라이브러리가 문제입니다. 사용하지 않는 기능이라면 과감하게 삭제하는 것이 가장 확실한 방법입니다.

Case A: WAS 9.0 - kc.war (관리 콘솔 도움말)

WAS 9.0 관리 콘솔의 '도움말(Knowledge Center)' 기능에 Log4j 2.x 취약 버전이 포함되어 있습니다.

• 대상: WAS 9.0 사용자
• 조치 방법: 해당 라이브러리 파일 삭제

# 1. 배포된 디렉토리에서 라이브러리 제거
rm -f [WAS_HOME]/systemApps/isclite.ear/kc.war/WEB-INF/lib/log4j*.jar

# 2. 설치 가능 앱 디렉토리에서 원본 앱 제거 (재설치 방지)
rm -rf [WAS_HOME]/installableApps/kc.war

# 3. 서버 재기동
./stopServer.sh server1 && ./startServer.sh server1

주의: 향후 9.0.5.11 이전의 픽스팩을 적용하면 삭제한 파일이 복구될 수 있으므로, 패치 후 다시 확인해야 합니다.

Case B: 전 버전 - uddi.ear (UDDI 레지스트리)

UDDI(Universal Description, Discovery, and Integration) 서비스에 Log4j 라이브러리가 포함되어 있습니다. 대부분의 최신 환경에서는 사용하지 않는 기능입니다.

• 대상: WAS 7.0 ~ 9.0 전체
• 조치 방법: 사용하지 않는다면 파일 삭제

# 미사용 시 (권장)
rm -f [WAS_HOME]/installableApps/uddi.ear

# 사용 중일 경우 (라이브러리만 교체/삭제 후 재배포 필요)
# uddi.ear 압축 해제 -> log4j*.jar 삭제 -> 다시 압축 -> Redeploy

---

3. Log4j 1.x 관련 추가 조치 (CVE-2021-4104)

Log4j 1.x 버전은 Log4Shell(RCE) 취약점의 직접적인 대상은 아니지만, JMSAppender를 사용할 경우 유사한 공격이 가능합니다. (WAS 기본 설정에는 JMSAppender가 없으나, 애플리케이션에서 사용할 수 있음)

조치 방법 (JMSAppender 제거)

Log4j 1.x는 더 이상 보안 패치가 나오지 않으므로(EOL), 취약한 클래스 파일만 강제로 삭제하는 것이 유일한 방법입니다.

# 시스템 전체에서 log4j-1.2.x.jar 파일을 찾아 JMSAppender 클래스 제거
zip -q -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

---

4. 참고 자료 (Reference)

• IBM Security Bulletin: Log4j vulnerability (CVE-2021-44228)

Summary:
WAS 운영팀은 kc.war와 uddi.ear 내의 log4j 파일을 삭제하고, 개발팀은 배포하는 애플리케이션(WAR/EAR) 내에 취약한 Log4j 버전이 포함되지 않도록 빌드 의존성을 점검해야 합니다.

[IBM HTTPServer] SSL 인증서 적용 가이드: PEM → P12 → KDB 변환 및 gskcapicmd 사용법

일반적인 인증서 파일(PEM/Key)을 IBM HTTP Server(IHS)에서 사용하는 CMS 키 데이터베이스(KDB) 형식으로 변환하는 과정을 정리합니다. OpenSSL을 이용해 P12로 1차 변환 후, IBM GSKit(gskcapicmd)을 이용해 KDB로 최종 변환 및 등록합니다.

0. 배경 및 프로세스 (Workflow)

IHS는 OpenSSL 기반이 아닌 IBM 고유의 암호화 라이브러리(GSKit)를 사용합니다. 따라서 다음과 같은 변환 과정이 필수적입니다.

• Step 1: .key + .pem → .p12 (OpenSSL 사용)
• Step 2: .p12 → .kdb (gskcapicmd 사용)

Test Environment

• OS: Linux / Unix
• Web Server: IBM HTTP Server v9.0 (v8.5 이상 동일)
• Tool: OpenSSL, gskcapicmd (IHS bin 폴더 내장)

---

1. PEM을 P12로 변환 (OpenSSL)

개인키(Private Key)와 인증서(Certificate)를 하나의 패키지 포맷인 PKCS#12(.p12)로 병합합니다.

# 구문: openssl pkcs12 -export -inkey [개인키] -in [인증서] -out [출력파일명]
openssl pkcs12 -export -inkey Wildcard.test.co.kr.key -in Wildcard.test.co.kr.pem -out Wildcard.test.co.kr.p12

주의 (Password):
명령어 실행 시 Export Password를 설정하게 됩니다. 이 비밀번호는 다음 단계에서 KDB로 임포트할 때 필요하므로 반드시 기억해야 합니다.

---

2. P12를 KDB로 변환 (GSKit)

IHS의 bin 디렉토리에 있는 gskcapicmd(또는 gskcmd)를 사용합니다.

2-1. 환경 변수 설정 (필수)

GSKit 라이브러리를 로드하기 위해 라이브러리 경로를 잡아주어야 에러가 발생하지 않습니다.

# IHS 설치 경로 예시 (/sw/web/IHS9)
export LD_LIBRARY_PATH=/sw/web/IHS9/lib:$LD_LIBRARY_PATH
cd /sw/web/IHS9/bin

2-2. 신규 KDB 생성 (없는 경우)

기존 KDB가 없다면 새로 생성합니다. -stash 옵션은 비밀번호를 파일(.sth)로 저장하여 웹 서버 기동 시 비밀번호 입력을 자동화합니다.

./gskcapicmd -keydb -create -db key.kdb -pw [KDB패스워드] -type cms -stash

2-3. P12 파일 임포트 (Import)

생성된(또는 기존) KDB 파일에 위에서 만든 P12 인증서를 넣습니다.

./gskcapicmd -cert -import \
-db /sw/img/Wildcard.test.co.kr.p12 -pw [P12패스워드] \
-target key.kdb -target_pw [KDB패스워드] \
-label "*.test.co.kr"

참고 (Export vs Import):
질문하신 내용 중 -export를 사용하여 P12를 KDB로 바로 변환하는 방법도 가능하지만, 실무에서는 기존 KDB에 인증서를 추가(Import)하거나 갱신하는 경우가 많으므로 -import 방식을 권장합니다.

---

3. 기본 인증서 설정 및 검증

KDB 안에 여러 인증서가 있을 경우, 어떤 인증서를 메인으로 사용할지 지정해야 합니다.

기본 인증서 지정 (Set Default)

./gskcapicmd -cert -setdefault -db key.kdb -pw [KDB패스워드] -label "*.test.co.kr"

검증 (List & Details)

KDB 내의 인증서 목록과 유효기간을 확인하여 작업이 정상적으로 되었는지 점검합니다.

# 인증서 목록 확인 (Default는 * 또는 > 표시가 붙음)
./gskcapicmd -cert -list -db key.kdb -pw [KDB패스워드]

# 특정 인증서 상세 정보 확인
./gskcapicmd -cert -details -db key.kdb -pw [KDB패스워드] -label "*.test.co.kr"

---

Next Step:
key.kdb 파일과 key.sth(Stash) 파일을 httpd.conf의 KeyFile 경로에 위치시키고 IHS를 재기동하면 SSL 적용이 완료됩니다.

[WebSphere] 보안 감사 대응: NCSA Access Log 활성화 및 로그 포맷(User-Agent, Time) 커스터마이징

WebSphere v8.5 환경에서 보안 감사 및 트러블슈팅을 위해 NCSA Access Log를 활성화하는 방법을 정리합니다. 서버 전역 설정과 전송 체인(Transport Chain)별 설정을 모두 적용해야 하며, accessLogFormat 속성을 통해 클라이언트 IP, 수행 시간, User-Agent 등을 기록하도록 포맷을 변경하는 방법을 다룹니다.

0. 배경 및 필요성 (Context)

WAS 앞단에 웹 서버(Web Server)가 있다면 웹 서버 로그를 분석하면 되지만, WAS로 직접 들어오는 요청이나 내부 통신, 혹은 상세한 애플리케이션 수행 시간 분석을 위해서는 WAS 자체의 Access Log가 필요합니다. WebSphere는 NCSA 표준 포맷을 지원합니다.

Test Environment

• Version: WebSphere Application Server v8.5

---

1. 전역 로깅 서비스 활성화 (Global Setting)

가장 먼저 서버 차원에서 로깅 서비스를 켜야 합니다.

1. 관리 콘솔에서 Servers > Server Types > WebSphere application servers > [서버명] 클릭
2. 우측 하단의 Troubleshooting 섹션에서 NCSA access and HTTP error logging 클릭
3. 설정 체크:
   • Enable logging service at server start-up (서버 기동 시 서비스 활성화)
   • Enable access logging (액세스 로깅 활성화)

---

2. 전송 체인별 로깅 활성화 (Chain Setting)

전역 설정을 했더라도, 실제 통신을 담당하는 전송 체인(Transport Chain)에서 로깅을 켜지 않으면 로그가 남지 않는 경우가 많습니다. 사용하는 포트(9080, 9443 등)에 해당하는 체인을 수정해야 합니다.

설정 경로

[서버명] > Web Container Settings > Web container transport chains

설정 방법

주로 사용되는 체인(WCInboundDefault, HttpQueueInboundDefault 등)을 선택하여 아래 작업을 반복합니다.

1. 체인 이름 클릭 (예: WCInboundDefault)
2. HTTP inbound channel (HTTP_2) 클릭
3. Enable logging 체크박스 선택

Tip: HTTPS(SSL) 요청에 대한 로그도 남기려면 WCInboundDefaultSecure 체인에 대해서도 동일하게 설정해야 합니다.

---

3. 로그 포맷 커스터마이징 (Custom Properties)

기본 포맷(Common Log Format)은 정보가 부족할 수 있습니다. 수행 시간이나 세션 ID, User-Agent 등을 남기기 위해 사용자 정의 속성을 추가합니다.

속성 추가 위치

위의 HTTP inbound channel (HTTP_2) 설정 화면에서 우측의 Custom properties (사용자 정의 특성) 메뉴로 진입합니다.

속성 값 (Key & Value)

• Name: accessLogFormat
• Value: (아래 예시 중 선택)

# 예시 1: 표준 확장 포맷 (IP, 시간, 요청, 상태, 크기, 수행시간)
%h %u %t "%r" %s %b %D

# 예시 2: 전체 정보 포함 (Referer, User-Agent, SessionID 포함)
%h %u %t "%r" %s %b %D "%{Referer}i" "%{User-agent}i" %{JSESSIONID}C

---

4. 주요 포맷 지시어 설명

지시어	설명
%h	클라이언트 IP 주소 (Host)
%t	요청 시간 (Time)
%r	요청 라인 (Request Line) - Method, URI, Protocol
%s	응답 상태 코드 (Status Code, 예: 200, 404, 500)
%D	요청 처리 소요 시간 (마이크로초 단위, 성능 분석 시 중요)
%{Header}i	특정 요청 헤더 값 (예: %{User-Agent}i)
%{Cookie}C	특정 쿠키 값 (예: %{JSESSIONID}C)

---

Next Step:
모든 설정을 마친 후에는 반드시 서버를 재기동해야 로그가 남기 시작합니다. logs/[서버명]/http_access.log 파일이 생성되는지 확인하십시오.

[WebSphere] TLS 1.2 전환 완벽 가이드: 버전별 지원 현황 및 WAS/IHS/Plugin 필수 설정

WebSphere Application Server v7.0, v8.0, v8.5 환경에서 TLS 1.2 프로토콜을 활성화하기 위한 최소 요구 사항(Fix Pack, JDK)을 확인하고, WAS, IHS, Plugin 각 계층별 필수 설정 방법을 정리합니다. 특히 플러그인 연결 시 발생하는 GSK_ERROR_SOCKET_CLOSED 에러 해결법을 포함합니다.

1. 버전별 TLS 1.2 지원 현황 (Prerequisites)

TLS 1.2를 사용하려면 WAS 버전에 따른 최소 픽스팩(Fix Pack)과 JDK 버전이 충족되어야 합니다.

WAS Version	Minimum Fix Pack	Required SDK Version
v7.0	7.0.0.23 이상	SDK 6 SR10 FP1 이상
v8.0	8.0.0.3 이상	SDK 6.0.1 (J9 2.6) SR1 FP1 이상
v8.5	8.5.0.0 (기본 지원)	SDK 6.0.1 (J9 2.6) SR2 이상

주의 (v7.0 제한사항):
WAS v7.0은 Java 레벨에서는 TLS 1.2를 지원하지만, 함께 제공되는 Web Server Plugin(GSKit V7 사용)은 TLS 1.2를 지원하지 않습니다. 따라서 v7.0 환경에서 웹 서버 연동 구간까지 TLS 1.2를 적용하려면 Plugin 모듈 업그레이드 혹은 아키텍처 검토가 필요할 수 있습니다.

---

2. WAS 설정 (Application Server)

관리 콘솔에서 SSL 설정을 변경하고, 관리 명령(stop/sync) 수행을 위해 클라이언트 설정 파일도 함께 수정해야 합니다.

1) 관리 콘솔 설정 (QoP)

Security > SSL certificate and key management > SSL configurations 메뉴로 이동합니다. CellDefaultSSLSettings, NodeDefaultSSLSettings 등 사용 중인 모든 설정을 수정합니다.

1. 설정 이름 클릭 (예: CellDefaultSSLSettings)
2. 우측의 Quality of protection (QoP) settings 클릭
3. Protocol 드롭다운 메뉴에서 TLSv1.2 선택
4. 저장 (Save)

2) ssl.client.props 수정 (중요)

이 설정을 하지 않으면 WAS가 TLS 1.2로 전환된 후, stopNode나 syncNode 같은 관리 명령어가 구형 프로토콜로 통신을 시도하여 실패하게 됩니다.

• 대상 파일:
  • [PROFILE_HOME]/properties/ssl.client.props

# 파일 내 해당 라인 수정
com.ibm.ssl.protocol=TLSv1.2

3) 재기동 및 동기화

설정 적용을 위해 DMGR부터 순서대로 재기동합니다.

# 1. 노드 및 DMGR 중지
./stopNode.sh
./stopManager.sh

# 2. DMGR 기동
./startManager.sh

# 3. 노드 동기화 (수동 동기화 권장)
./syncNode.sh [Dmgr_Host] [Dmgr_SOAP_Port] -username [ID] -password [PW]

# 4. 노드 기동
./startNode.sh

---

3. Web Server (IHS) 설정

IBM HTTP Server의 httpd.conf 파일에서 SSL 설정을 강화합니다.

<VirtualHost *:443>
    SSLEnable
    
    # TLS 1.2 활성화
    SSLProtocolEnable TLSv12
    
    # 취약한 하위 프로토콜 비활성화
    SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
</VirtualHost>

---

4. Plugin 설정 (Troubleshooting)

WAS와 IHS를 모두 TLS 1.2로 설정했는데도 http_plugin.log에 GSK_ERROR_SOCKET_CLOSED (gsk rc = 420) 에러가 발생하며 연결이 안 될 수 있습니다. 이는 플러그인이 기본적으로 보안 수준을 엄격하게 검사하지 않아서 발생하는 호환성 문제입니다.

해결 방법: StrictSecurity 적용

plugin-cfg.xml 파일의 최상단 Config 태그에 속성을 추가해야 합니다.

<Config StrictSecurity="true">
    <Log LogLevel="Error" Name="..." />
    ...
</Config>

Tip: StrictSecurity="true" 설정은 플러그인이 WAS와 통신할 때 TLS 프로토콜을 엄격하게 준수하도록 강제하여, TLS 1.2 핸드쉐이크 문제를 해결합니다.

---

5. 검증 (Verification)

openssl 명령어를 사용하여 서버가 TLS 1.2만 허용하는지 테스트합니다.

# TLS 1.2 접속 성공 확인
openssl s_client -connect [Host]:9443 -tls1_2

# TLS 1.0 접속 실패 확인 (핸드쉐이크 에러가 나야 정상)
openssl s_client -connect [Host]:9443 -tls1

[WebSphere Liberty] installUtility 사용법 완벽 가이드: Feature 검색, 다운로드 및 로컬 저장소 구성

WebSphere Liberty의 기능(Feature)을 관리하는 커맨드 라인 도구인 installUtility의 핵심 사용법을 다룹니다. 온라인 IBM 저장소에서 기능을 검색/다운로드하는 방법과, 사내 폐쇄망 환경을 위한 로컬 리포지토리(Local Repository) 설정 방법을 정리합니다.

Test Environment

• OS: CentOS 7.2
• Middleware: IBM Liberty Core 20.0.0.6
• Tool: installUtility (Located in $WLP_HOME/bin)

---

1. Feature 검색 및 다운로드 (Basic Usage)

IBM의 공인 저장소(IBM WebSphere Liberty Repository)에 연결하여 필요한 기능을 찾거나 다운로드합니다.

기능 검색 (Find)

설치 가능한 기능의 정확한 이름을 모를 때 유용합니다.

# 구문: installUtility find [검색어]
installUtility find jsp --type=feature

기능 다운로드 (Download)

서버에 바로 설치하지 않고, 파일(ESA) 형태로 로컬 디렉토리에 다운로드합니다. 이 파일들은 나중에 로컬 저장소를 구축할 때 사용됩니다.

# 구문: installUtility download [기능명] --location=[경로]
installUtility download jsp-2.3 --location=/SW/img/LibertyUtility --acceptLicense

---

2. 로컬 저장소 구성 (Repository Configuration)

인터넷이 차단된 서버나, 사내 표준 라이브러리를 관리하기 위해 로컬 디렉토리를 저장소로 등록하여 사용합니다.

설정 파일 위치

Liberty 설치 경로 내의 etc 디렉토리에 설정 파일을 생성해야 합니다.

• 위치: ${wlp.install.dir}/etc/repositories.properties

설정 내용 (repositories.properties)

다운로드 받아둔 Feature 파일들이 위치한 경로를 url로 지정합니다.

# Local Repository Path Configuration
# 로컬 파일 시스템 경로 또는 사내 웹 서버 URL 지정 가능
local-rep.url=/SW/img/LibertyUtility

Tip: useDefaultRepository=false 옵션을 추가하면 IBM 공인 저장소 접속을 차단하고 로컬 저장소만 바라보게 강제할 수 있습니다.

---

3. 설정 검증 (Verification)

작성한 리포지토리 설정이 정상적으로 인식되는지 확인합니다.

설정 확인 (viewSettings)

현재 적용된 리포지토리 목록과 우선순위를 출력합니다.

installUtility viewSettings

(출력 결과에서 local-rep.url이 목록에 포함되어 있는지 확인)

연결 테스트 (testConnection)

지정한 경로로 접근이 가능한지 최종 테스트합니다.

# 특정 저장소 테스트
installUtility testConnection local-rep

# 또는 전체 테스트
installUtility testConnection --all

---

4. 참고 자료 (References)

• IBM Knowledge Center: installUtility command reference
• IBM Fix Central: Download Liberty Features (Offline)
  (Fix Central에서 wlp-featureRepo 패키지를 받으면 전체 기능을 포함한 로컬 저장소를 한 번에 구축할 수 있습니다.)

---

Next Step:
로컬 저장소 구성이 끝났다면, installUtility install [기능명] 명령어를 통해 인터넷 연결 없이도 필요한 기능을 서버에 즉시 설치해 보십시오.

[WebSphere] WAS v9.0 CLI 설치 완벽 가이드: IM, WAS, IHS, Plugin 및 JDK 8 동시 설치

CentOS 7 환경에서 GUI 없이 imcl 명령어를 사용하여 WebSphere v9.0.5.1을 설치합니다. v9.0부터 변경된 정책에 따라 JDK 8을 반드시 함께 설치해야 함을 강조하며, WAS, IHS, Plugin 설치 및 패치 적용 명령어를 정리합니다.

Test Environment

• OS: CentOS 7 (3.10.0-957.el7.x86_64)
• Installer: IBM Installation Manager (IM) 1.8.x 이상
• Target Version: WebSphere Application Server 9.0.5.1

---

1. Installation Manager (IM) 설치

IBM 제품군을 설치하고 관리하는 도구인 IM을 먼저 설치합니다. -repositories에는 repository.config 파일이 있는 경로를 지정합니다.

설치 명령어

# 설치 경로로 이동
cd /sw/img/im

# IM 설치 실행
./imcl install com.ibm.cic.agent \
-repositories "/sw/img/im/repository.config" \
-installationDirectory "/sw/IBM/InstallationManager/eclipse" \
-sharedResourcesDirectory "/sw/IBM/IMShared" \
-acceptLicense \
-showProgress -sP

Tip (패키지 ID 확인):
설치하려는 제품의 정확한 ID(예: com.ibm.websphere...)를 모른다면 설치 미디어 내의 Offerings 폴더를 확인하거나, ./imcl listAvailablePackages -repositories [경로] 명령어로 조회할 수 있습니다.

---

2. WebSphere Application Server (WAS) 설치

중요: WAS v9.0은 기본 JDK가 포함되어 있지 않습니다. 따라서 com.ibm.websphere.BASE... 패키지와 com.ibm.java.jdk.v8... 패키지를 동시에 지정하여 설치해야 합니다.

설치 명령어 (Base + JDK 8)

설치 도구(tools) 경로로 이동하여 실행합니다.

cd /sw/IBM/InstallationManager/eclipse/tools

# WAS 및 JDK 동시 설치
./imcl install com.ibm.websphere.BASE.v90_9.0.5001.20190828_0616 \
com.ibm.java.jdk.v8_8.0.5041.20190924_1031 \
-repositories "/sw/img/base","/sw/img/sdk" \
-installationDirectory "/sw/was/AppServer9" \
-sharedResourcesDirectory "/sw/IBM/IMShared" \
-acceptLicense \
-properties cic.selector.nl=ko \
-showProgress -sP

Fix Pack 업데이트 (Optional)

설치 후 특정 픽스팩(예: 9.0.5.3)으로 업데이트가 필요한 경우 아래 명령어를 사용합니다.

./imcl install com.ibm.websphere.BASE.v90_9.0.5003.20200226_0941 \
-repositories "/sw/img/fixwas" \
-installationDirectory "/sw/was/AppServer9" \
-acceptLicense -sP

---

3. IBM HTTP Server (IHS) 설치

웹 서버인 IHS도 마찬가지로 JDK 설치가 필요합니다. user.ihs.httpPort 속성으로 기본 포트를 지정할 수 있습니다.

# IHS 및 JDK 동시 설치
./imcl install com.ibm.websphere.IHS.v90_9.0.5001.20190828_0616 \
com.ibm.java.jdk.v8_8.0.5041.20190924_1031 \
-repositories "/sw/img/ihs","/sw/img/sdk" \
-installationDirectory "/sw/web/IHS9" \
-sharedResourcesDirectory "/sw/IBM/IMShared" \
-acceptLicense \
-properties user.ihs.httpPort="80" \
-showProgress -sP

---

4. Web Server Plugin (PLG) 설치

WAS와 웹 서버를 연동해주는 플러그인 모듈입니다.

# Plugin 및 JDK 동시 설치
./imcl install com.ibm.websphere.PLG.v90_9.0.5001.20190828_0616 \
com.ibm.java.jdk.v8_8.0.5041.20190924_1031 \
-repositories "/sw/img/plg","/sw/img/sdk" \
-installationDirectory "/sw/web/Plugins9" \
-sharedResourcesDirectory "/sw/IBM/IMShared" \
-acceptLicense \
-showProgress -sP

---

5. 설치 검증 (Verification)

모든 설치가 완료되면 설치된 패키지 목록과 상세 버전을 확인합니다.

설치된 패키지 목록 확인

# IM 명령어로 확인
./imcl listInstalledPackages

상세 버전 리포트 확인

WAS가 제공하는 스크립트로 상세 리포트를 확인합니다.

# WAS 홈의 bin 디렉토리
/sw/was/AppServer9/bin/versionInfo.sh

---

Next Step:
엔진 설치가 완료되었습니다. 이제 manageprofiles.sh 명령어를 사용하여 실제 서비스를 구동할 프로파일(Profile)을 생성해야 합니다.

[Windows 10] Microsoft Edge 기본 검색 엔진 변경 방법 (Bing -> Google/Naver)

Windows 10 Edge 브라우저의 주소 표시줄에서 검색 시 기본적으로 사용되는 검색 엔진(Bing)을 Google, Naver, Daum 등으로 변경하는 방법을 정리합니다. 설정 메뉴 깊숙이 들어갈 필요 없이 단축 URL로 한 번에 이동하는 팁을 포함합니다.

Test Environment

• OS: Windows 10
• Browser: Microsoft Edge (Chromium 기반 최신 버전)

---

Method A: 단축 URL로 한 번에 이동 (추천)

복잡한 메뉴를 찾아들어갈 필요 없이, 주소창에 아래 명령어를 입력하면 설정 화면으로 바로 이동합니다.

Tip: 아래 주소를 복사하여 Edge 주소창에 붙여넣으세요.
edge://settings/search

---

Method B: 설정 메뉴를 통한 이동

단축 URL이 기억나지 않을 때 사용하는 정석적인 방법입니다.

1. 설정 메뉴 진입

1. Edge 브라우저 우측 상단의 점 세 개(...) 버튼 클릭
2. 설정(Settings) 클릭

2. 개인 정보 및 서비스 설정

1. 좌측 메뉴에서 '개인 정보, 검색 및 서비스(Privacy, search, and services)' 선택
2. 스크롤을 맨 아래로 내려 '주소 표시줄 및 검색(Address bar and search)' 클릭

---

3. 검색 엔진 변경 (Change Engine)

설정 화면에 진입했다면, 원하는 검색 엔진으로 변경합니다.

• 주소 표시줄에서 사용되는 검색 엔진: 드롭다운 메뉴를 클릭하여 Google, Naver 등을 선택합니다.
• 새 탭에서의 검색 상자 등...: '검색 상자(권장)' 대신 '주소 표시줄'을 선택하면 새 탭에서도 변경한 엔진이 적용됩니다.

참고: 만약 목록에 원하는 검색 엔진(예: Naver)이 없다면, '검색 엔진 관리' 메뉴로 들어가서 해당 사이트(naver.com)를 한 번 방문한 뒤 수동으로 추가할 수 있습니다.