SSL/TLS 인증서 관련 정보 모음집(인증서 변환 포함)

호스팅 업무를 하다 보면 많이 접수되는 것 중하나는 SSL/TLS 인증서 관련한 문의입니다. 대부분 어떻게 인증서를 구입 및 적용하는지, 인증서를 꼭 적용해야 하는지 등에 대한 FAQ가 많아서 이것을 개인적인 지식과 SSL발급 업체 홈페이지 안내의 정보를 최대한 한 포스팅에 정리하여 담고자 합니다.

 

※ 모든 정보는 개인서버에서 직접 테스트한 결과만을 가지고 안내를 드리도록 하겠습니다. 주로 Linux Server「Rocky Linux」, Windows Server「2019/2022」에서 테스트를 진행하였습니다.

※ SSL 인증서는 무료 발급「Let's Encrypt」을 이용 : 「포스팅 참고」

※ 해당 포스팅을 통해 실서버 적용 시 문제 발생에 대하여 책임지지 않습니다.

SSL/TLS란?

SSL「Secure Sockets Layer」 프로토콜 「구 버전」

TLS「Transport Layer Security」 프로토콜

서버와 사용자(브라우저) 간의 통신을 할 경우 정보를 함호화 하고 도중에 해킹을 통해 정보가 유출이 된다고 하더라도 정보의 내용을 보호할 수 있는 보안 인증 솔루션 기술이라고 생각하시면 됩니다. 

 

이전에 메일서버 포스팅을 할 때 자주 다루었지만 다시 설명하자면 SSL/TLS가 많이 혼동될 수 있는데 둘은 태생이 같다고 생각하시면 편합니다. 즉 취약점을 보완 및 업그레이드하면서 SSL에서 TLS로 대체된 부분입니다. 순서로 보면 「SSLv1 → SSLv2 → SSLv3 → TLSv1.0 → TLSv1.1 → TLSv1.2 → TLSv1.3 (2018년 8월 RFC8446 게시)」로 업그레이드되었습니다. 사실상 「SSL, TLSv1.0, TLSv1.1」까지 대부분의 비중 있는 기업들은 2020년 말부터 지원을 중단했다고 봐도 됩니다. 그래서 아직까지는 안전한 최소 「TLSv1.2」 이상을 사용하라고 권고를 하고 있습니다. 하지만 TLSv1.2도 언제 도태될지 알 수 없으므로 최근 서버를 새로 구축을 한다면 무조건 「TLSv1.3」을 적용하는 게 좋습니다.

 

아직까지도 인증서 발급 업체들이 SSL 인증서 판매/발급이라고 표현을 하다 보니 SSL/TLS가 다른 것처럼 인식하는 경우가 많습니다. SSL은 보안에 취약하여 낙후되어 사용하지 않게 된 프로토콜이며 요즘 대부분의 업체들이 최소 보안 기준 TLSv1.2 버전 이상을 적용하여 사용하고 있다고 보면 됩니다. 이제는 TLS 인증서 판매/발급이라고 표시하는 게 올바르지 않을까 합니다.

 

또 하나 인증서파일은 단순 서버와 애플리케이션 및 클라이언트(사용자) 간의 인증을 위한 수단일 뿐이며 실제 소프트웨어가「Apache, Tomcat, IIS 등」 SSL/TLS를 사용할 수 있도록 지원합니다. 가장 최신 버전인 TLSv1.3을 사용하기 위해서는 소프트웨어 버전이 일정 버전 이상이 필요할 수 있습니다.

---

◈ 신원 인증을 위한 「CSR」과「KEY」 생성하기

예전에는 인증서 판매업체에서 인증서를 발급받기 위해서는 CSR「Certificate Signing Request」과 개인 키「Private Key」를 별도로 요청했습니다. 원래 인증서라는 게 아무에게나 발급해 주는 것이 아닌 실제 도메인 소유자인지 호스팅 서비스를 하고 있는 관리자인지, 개인 또는 회사 신원이 확실한지 등을 꼼꼼히 파악하여 발급을 했습니다. 이런 정보를 포함한 파일이 CSR이지만 요즘에는 발급 사이트에서 정보만 입력하면 자동으로 바로 생성(무료)을 해주다 보니 번거로운 과정은 생략되고 있습니다. 요즘도 수동으로 요청을 하는 곳이 있는지 모르겠네요. 아래는 서버에서 직접 CSR과 KEY값 생성을 예시로 보여드리겠습니다.

 

① Apache 발급 기준으로 Openssl 확인

[root@]# rpm -qa openssl    [설치 확인]

 

※ 테스트 환경

Rocky Linux release 8.10 (Green Obsidian)

openssl-1.1.1k-12.el8_9.x86_64

※ 일반적으로 OS 설치 시 기본적으로 설치되어 있거나 dnf(yum) 온라인을 통해 RPM 명령어를 사용하여 설치여부 확인 

 

② 개인 키「Private Key」 생성

[root@]# openssl genrsa -des3 -out sub_foxydog_pe_kr.key 2048    [개인 키 생성]

[root@]# openssl rsa -noout -text -in sub_foxydog_pe_kr.key    [생성 확인]

 

※ 구문 옵션 중 「-des3」 윈도우+아파치 이용 시에는 구문 제외

※ 「2048」은 RSA키 (2048 bit 암호화) 크기, 대부분의 인증서 업체에서 사용, (1024 bit)는 보안취약으로 더 이상 사용하지 않음, 일부 업체는 고도의 보안을 위해 최대 (4096 bit)까지 사용하는 경우가 있음

※ 패스워드는 이후 여러 차례 사용되므로 개인(관리자)만 알 수 있는 패스워드 사용

 

③ CSR 생성(수동 생성)

[root@]# openssl req -new -key sub_foxydog_pe_kr.key -out sub_foxydog_pe_kr.csr    [CSR 생성]

[root@]# openssl req -noout -text -in sub_foxydog_pe_kr.csr    [CSR 정보 확인]

◇ CSR 생성 중 항목 예시「영문으로 입력」

※ 넘어가기 전 CSR 항목에서 < > ~ ! @ # % ^ & * ( ) ? 등의 특수 문자 자체를 사용하지 마세요. Common Name에서 도메인을 구분하는 www.foxy-dog.pe.kr  점「.」, 하이픈「-」 형태는 가능하며, 콤마「,」 언더바「_」는 사용 불가합니다.

 

Country Name (2 letter code) [XX]:KR

※ ISO 형식의 2자리 국가 코드 입력 「KR(한국), US(미국), JP(일본) 등」

 

State or Province Name (full name) []:Seoul

※ 각 나라의 "주" 행정구역 입력 「대한한국-서울(Seoul), 미국-뉴욕(New York) 등」, 약어 사용 금지

 

Locality Name (eg, city) [Default City]:Gangnam

※ 회사 위치 「시/군/구」 입력, 값 입력 없이「Enter」 누르면 생략 가능

 

Organization Name (eg, company) [Default Company Ltd]:FoxyDog inc

※ 사업장 등록증에 등록되어 있는 회사명과 동일한 영문명으로 입력

 

Organizational Unit Name (eg, section) []:Engineer Team

※ 부서명 입력 「엔지니어 팀, 리눅스/윈도우 관리팀」

 

*Common Name (eg, your name or your server's hostname) []:sub.foxydog.pe.kr

※ 인증받을 도메인 주소를 입력, 가장 중요한 부분이며 HTTP(S):// 입력 금지, 도메인 명만 입력

 

Email Address []:tester@foxydog.pe.kr

※ 개인 또는 관리자 이메일 주소 입력

 

A challeng password []: 값 입력하지 말고 Enter

An optional company name []: 값 입력하지 말고 Enter

※ 값 입력 시 기존 정보와 다른 CSR값이 생성될 수 있습니다.

 

④ 생성한 CSR 파일의 내부 값을 인증서 발급 업체에 전달

---

◈ 인증서 발급 파일 확인 및 적용「Apache 예시」

인증서는 발급해 주는 업체마다 차이가 있습니다. 웹서버의 종류에 따라 크게 3가지로 「Apache-ModSSL」, 「Microsoft Windows Server IIS」 「Tomcat」로 구분되며 신청한 웹서버만에 해당되는 인증서를 발급해 주는 기관이 있는 반면, 3가지의 형태를 전부 발급해 사용자가 골라서 사용할 수 있도록 해주는 기관도 있습니다. 후자가 나중에 서버를 변경해도 인증서 포맷 변환을 하지 않아서 편합니다. 또한 인증서를 확인해 보면 다양한 「crt」「cer」「csr」「pem」「der」「pfx」「p12」「p7b」「jks」「key」 확장자가 있습니다. 웹서버마다 인증서를 구별하기 위한 확장자이지만 이게 꼭 있는 그대로의 모습이 아닐 수 있습니다. 확장자보다는 내부 내용을 확인하여 실제 포맷(형식)이 어떻게 되어 있는지 확인이 필요합니다. 해당 부분은 인증서를 적용 및 변환하면서 하나씩 테스트해 보도록 하겠습니다.

 

① 「Apache-ModSSL」 인증서 종류 확인

※ 테스트를 위해 무료 인증서 발급 업체를 이용, 「Let's Encrypt」 포스팅 참고

Apache-ModSSL 기준으로 일반적으로 아래의 3~5개의 파일을 발급합니다.

[root@]# ll /etc/letsencrypt/archive/sub.foxydog.pe.kr    [Let's Encrypt 인증서 발급 위치]

cert1.pem    [메인 인증서]
chain1.pem    [체인 인증서]
fullchain1.pem    [체인+체인 또는 체인+루트 인증서]
privkey1.pem    [개인 키]

 

② 「Apache ssl.conf」 인증서 적용

※ RPM설치 시 기본 경로에 ssl.conf 파일이 생성됩니다.

※ 꼭 아래에 설정 파일에 할 필요는 없으며 vhost.conf 별도의 가상 호스트 설정이 있다면 최소 아래 값들을 등록하면 됩니다.

[root@]# vim /etc/httpd/conf.d/ssl.conf    [파일 수정]

Listen 443 https

 

<VirtualHost *:443>    [▷ 시작 지점]

 

DocumentRoot "/var/www/html/foxydog"    [웹서버 루트 디렉토리 경로]

ServerName sub.foxydog.pe.kr     [도메인 네임]

 

SSLEngine on    [SSL엔진 사용 여부]

 

SSLCertificateFile /etc/letsencrypt/archive/sub.foxydog.pe.kr/cert1.pem    [인증서 경로 변경]

SSLCertificateKeyFile /etc/letsencrypt/archive/sub.foxydog.pe.kr/privkey1.pem    [인증서(개인키) 경로 설정]

SSLCertificateChainFile /etc/letsencrypt/archive/sub.foxydog.pe.kr/fullchain1.pem    [인증서(체인) 경로 설정]

 

</VirtualHost>      [◀끝 지점(이 범위 안에 각 옵션 포함 적용)]

[참고]

[SSLCACertificateFile / SSLCertificateChainFile] 이 두 개의 옵션이 [root(루트) / Chain(체인)] 인증서를 설치할 때 가장 많이 혼동할 수 있는 부분인데요, 이렇게 생각하시면 편합니다.

 

패턴 1. CA 번들[ca_bundle] 형태로 인증서를 받았을 경우

ca_bundle.crt(pem) 인증서는 [루트 / 체인] 이 같이 통합된 파일입니다. 인증서 업체에서 처음부터 번들 형태로 발급을 해준다면 [SSLCACertificateFile] 에만 적용해 주면 됩니다.

 

패턴 2.  [루트 / 체인] 두 개로 나누어 받았을 경우

AAACertificateServices.crt (루트) / chain-bundle.pem (체인) 예시와 같이 따로 받았을 경우는 각각 추가로 등록을 해줘야 합니다.

SSLCACertificateFile /.../AAACertificateServices.crt  (루트)

SSLCertificateChainFile /.../chain-bundle.pem  (체인)

 

만약 번들로 통합하고 싶다면 아래와 같이 진행

※ 통합 방법[cat 루트 인증서 체인 인증서 > 변경할 이름.crt(pem)]

[root@localhost ~]# cat AAACertificateServices.crt chain-bundle.pem > Ca_bundle.crt(pem)

 

③ 인증서 「CRT」「PEM」 확장자의 차이?

인증서 발급 업체마다 「.CRT」로 발급해 줄 때도 있고 「.PEM」 확장자로 발급하는 곳도 있어서 무언가 서로 다른 인증서로 착각할 수가 있지만 결론적으로는 거의 같다고 봐도 무방합니다. 정식 표현으로서는 PEM「Privacy Enhanced Mail」으로 사용하는 게 맞으며 Base64(가장 광범위하고 거의 99% 시스템에 호환되는 산업 표준 포맷) 인코딩 된 ASCII  텍스트 파일입니다. 「.CRT」는 인증서 파일이라는 의미로 표시를 한 부분이라 해당 파일도 리눅스 VI나 윈도우 메모장, 노트패드에서 열어보면 거의 동일한 Base64 PEM 포맷 형태로 되어 있습니다. 리눅스/유닉스 기반에서는 인증서 포맷 내용에 문제가 없다면 확장자는 발급자가 마음대로 붙일 수 있다는 뜻입니다. 아래는 테스트 예시입니다.

 

결과를 보면 인증서 파일 내용이 Base64 PEM 포맷 형태로 변경이 없다면 적어도 리눅스/유닉스 서버에서 확장자는 큰 의미가 없습니다. 발급자 마음대로 설정해도 Apache 환경설정에서 정보를 불러올 때 큰 문제는 없다는 것으로 판단됩니다. 애초에 문제가 있었다면 서비스 재시작할 때 에러가 발생합니다. 추가로 로그 「ssl_request_log」 기록을 활성화하여 실시간 접속 기록을 확인해 보면 정상적으로 TLSv1.3으로 응답하는 것을 알 수 있습니다.

 

 

④ 인증서 개인키에 암호 설정 및 제거

발급 업체 홈페이지에서 CSR자동생성으로 했다면 개인키에는 암호를 설정하지 않습니다. 서버에서 수동으로 CSR생성으로 하셨을 경우에는 미리 개인키에 암호 설정을 하게 됩니다. 그러나 인증서에 개인키 암호는 크게 의미가 없습니다. 암호가 설정되어 있으면 괜히 웹서비스 구동(재시작)할 때마다 암호를 물어보며 잊어버리면 당황할 수 있기 때문에 걸려있다면 암호화를 해제하는 게 좋습니다. 아래는 암호화 설정 및 제거 예시 방법입니다.

◇ 개인키 암호화 설정

[root@]# openssl rsa -des3 -in privkey1.pem_bak -out privkey1.pem
writing RSA key

Enter PEM pass phrase:    [개인키 PEM 암호화 패스워드 입력]

Verifying - Enter PEM pass phrase:    [동일 패스워드 재입력]

 

이후 암호화 설정된 개인키를 적용하여 Apache 재시작하면 RSA 패스워드 확인 여부 질의

[root@]# systemctl restart httpd    [Apache 구동(재시작) 시]

Enter TLS private key passphrase for sub.foxydog.pe.kr:443 (RSA) :    [패스워드 입력]

◇ 개인키 암호화 제거

[root@]# openssl rsa -in privkey1_ENCRYPTED.pem -out privkey1.pem
Enter pass phrase for privkey1_ENCRYPTED.pem:    [개인키 PEM 패스워드 입력]
writing RSA key

---

◈ Windows Server IIS용 인증서 변환 및 역추출

이번에는 리눅스에 있던 PEM 인증서를 가지고 PFX 인증서로 변환하여 Windows Server IIS 웹서버에 적용 테스트 해보겠습니다.

 

① PFX 인증서 변환 및 확인

◇ 「CRT(PEM), KEY」  → 「PFX」 인증서 변환

[root@]# openssl pkcs12 -export -in cert1.pem -inkey privkey1.pem -out win_cert.pfx

Enter Export Password:    [패스워드 설정 입력]

Verifying - Enter Export Password:    [패스워드 설정 입력]

 

[root@]# ll | grep pfx

win_cert.pfx    [파일 생성 확인]

◇ 「PFX」 인증서 확인

[root@]# openssl pkcs12 -info -in win_cert.pfx

Enter Import Password:    [패스워드 입력]

 

처음에는 인증서 정보가 나오며

-----BEGIN CERTIFICATE-----

 

다시 한번 PEM 패스워드를 입력하면 개인 키 정보가 나옵니다.

Enter PEM pass phrase:    [패스워드 입력]

Verifying - Enter PEM pass phrase:    [패스워드 입력]

-----BEGIN ENCRYPTED PRIVATE KEY-----

 

② PFX 패스워드 변경(참고)

※ PFX 인증서 파일 자체의 패스워드 변경은 하지 못하며, 패스워드를 제거한 임시 PEM 인증서를 가지고 다시 패스워드를 설정한 PFX파일로 변환하는 작업입니다.

◇ PFX → PEM 기존 패스워드 제거

[root@]# openssl pkcs12 -in win_cert.pfx(기존) -out sub_foxydog_pe_kr.pem(임시) -nodes

Enter Import Password:    [기존 패스워드 입력]

 

◇ PEM → PFX 새로운 패스워드 입력

[root@]# openssl pkcs12 -export -in sub_foxydog_pe_kr.pem(임시) -out new_win_cert.pfx

Enter Export Password:    [새로운 패스워드 입력]

Verifying - Enter Export Password:    [재 입력]

 

[root@]# openssl pkcs12 -info -in new_win_cert.pfx    [PFX 파일 확인]

Enter Import Password:    [새로운 패스워드 입력]

 

③ Windows Server IIS 인증서 가져오기 및 적용

※ Windows Server 2019 가상서버에서 테스트 진행 (리눅스 서버에서 PFX 생성한 파일을 그대로 이용)

Windows IIS 기반에서는 주로 PKCS#12 「.PFX/.P12」형식의 바이너리 포맷의 인증서, 개인 정보 교환「Personal Information Exchange Format」와 암호화 메시지 구문 표준 PKCS#7 인증서「.P7B」 (Base64 Text 파일) 이 두 가지를 많이 발급받아 사용합니다. Microsoft 일련 인증서「.SST」는 사용해 본 적이 없어서 언급을 제외하겠습니다. 「.PFX/.P12/.P7B」형식은 인증서의 형태를 하고 있지만 하나의 파일에 「서버인증서, 개인키, 서버인증서, 루트인증서」 모두를 담을 수 있어서 저장소, 컨테이너 용도 파일에 가깝습니다. 실제로 위에서 인증서 INFO 정보를 확인했을 때 내용에는 「PKCS7 Encrypted」으로 되어 있는 것을 확인할 수 있습니다.

 

정상적으로 「.PFX」적용이 완료되었습니다. 리눅스처럼 확장자 이름을 변경해 보거나 비표시로 해보았지만 윈도우는 확장자를 불러올 때 확실하게 인식하다 보니 올바르게 표시하는 게 중요하네요. 이제 다시 해당 인증서를 리눅스서버에 이전 후 Apache 용도에 맞게 인증서를 추출해 보겠습니다.

 

④ 「PFX」 → 「 CRT(PEM), KEY 」 인증서 추출 하기

◇ PFX → CRT(PEM) 추출 (PFX 암호 필요)

[root@mail mv]# openssl pkcs12 -in win_cert.pfx -clcerts -nokeys -out cert1.pem

 

◇ PFX → KEY 추출 (PFX 암호 필요)

[root@mail mv]# openssl pkcs12 -in win_cert.pfx -nocerts -nodes -out privkey1.pem

 

[root@mail mv]# ll
cert1.pem    [추출된 PEM 서버 인증서]
privkey1.pem    [추출된 개인 키 인증서]

 

추출한 인증서를 적용해도 문제가 없는지 테스트를 위해 Apache ssl.conf 쪽에는 다른 위치 경로를 잡아서 Aapche 재시작, 문제없이 구동되고 인증서도 올바르게 인식하고 있습니다.

 

---

◈ JavakeyStore 「.JKS」 변환 및 적용

ChatGPT왈, Java Keystore(JKS)란?

Java Keystore(JKS)는 Java 환경에서 사용하는 키와 인증서를 안전하게 저장하고 관리하기 위한 저장소 형식입니다. 주로 SSL/TLS 통신을 설정하거나, 애플리케이션의 보안 기능을 구현할 때 사용됩니다. JKS는 Java Development Kit(JDK)에 포함된 keytool 유틸리티를 사용하여 생성하고 관리할 수 있습니다.

※ 개인 클라우드 서버에 JAVA(OpenJDK)와 Apache Tomcat 설치하여 테스트

[root@]# /usr/bin/java -version    [JAVA 버전 확인]

openjdk version "21.0.4" 2024-07-16 LTS

OpenJDK Runtime Environment (Red_Hat-21.0.4.0.7-1) (build 21.0.4+7-LTS)

OpenJDK 64-Bit Server VM (Red_Hat-21.0.4.0.7-1) (build 21.0.4+7-LTS, mixed mode, sharing)

 

[root@]# /opt/tomcat/bin/version.sh    [Tomcat 버전 확인]

Server version: Apache Tomcat/10.1.28

Server built: Aug 2 2024 15:14:43 UTC

Server number: 10.1.28.0

 

① 「CRT(PEM),PFX」→「JKS」 변환

◇ CRT(PEM),KEY를 이용해 먼저 PFX(PKCS#12)으로 변환

※ 구분을 위해 별도 JAVA 이름의 폴더 경로에 파일을 복사하여 테스트

 

[root@]# cat cert1.pem fullchain1.pem > java.pem    [하나의 파일로 통합 후]

 

※ 만약 fullchain 인증서가 없고 「체인/루트」 인증서를 전부 따로 받았을 경우

※ 「도메인인증서/체인인증서/루트인증서」 순으로 통합할 것, 다른 순으로 하면 안 되는지에 대한 테스트는 진행하지 않음

예시 1. [root@]#  cat cert1.pem chain1.pem root_ca.pem > java.pem

예시 2. [root@]#  cat cert1.crt chain1.crt chain2.crt root_ca.crt > java.pem

 

[root@]# openssl pkcs12 -export -in java.pem -inkey privkey1.pem -out java.pfx    [PFX 변환]

Enter Export Password:    [새로운 패스워드 입력]

Verifying - Enter Export Password:    [재 입력]

◇ 「PFX」→「JKS」 변환

※ JAVA(OpenJDK)를 설치하면 기본적으로 「/usr/bin/keytool」 포함되어 있으며 해당 툴을 이용하여 변환

 

[root@]# keytool -importkeystore -srckeystore java.pfx -srcstoretype pkcs12 -destkeystore java.jks -deststoretype jks    [JKS 변환, 전체 한 줄]

Enter destination keystore password:    [대상 키 저장소 비밀번호 입력]

Re-enter new password:    [새 비밀번호 다시 입력]

Enter source keystore password:    [소스 키(PFX) 저장소 비밀번호 입력]

※ 패스워드는 될 수 있으면 다르게 하지 말고 동일하게 세팅할 것(실제 인증서 적용 시 혼동 발생)

※ Alias 1 Successfully imported 성공 메시지 확인

 

[root@]# ll | grep jks
java.jks    [생성 확인]

※ Warning:

The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore java.jks -destkeystore java.jks -deststoretype pkcs12". 해당 내용은 JKS Keystore는 JAVA에서만 사용하는 독점 형식이라, 산업 표준 형식인 PKCS12로 마이그레이션 하는 게 좋다는 단순 경고문입니다. 필자도 JKS 확장자로 Apache Tomcat이나 JAVA로 개발된 소프트웨어 데몬 환경에만 적용을 해봐서 다른 확장자로 적용을 해본 적이 없네요. 이후 순차적으로 적용해 보겠습니다.

◇ 「JavakeyStore(JKS)」 인증서 확인

[root@]# keytool -list -v -keystore java.jks    [확인 방법]

Enter keystore password:    [패스워드 입력]

 

② 「Apache Tomcat - JKS」 인증서 적용 및 확인

[root@]# vim /설치경로/conf/server.xml    [Apache Tomcat 설정 파일 중]

 

        <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"

               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
               maxParameterCount="1000" sslProtocol="TLS" URIEncoding="UTF-8">

            <SSLHostConfig>

            <Certificate certificateKeystoreFile="/인증서경로/java/java.jks"

                         certificateKeystorePassword="암호" type="RSA" />

            </SSLHostConfig>

        </Connector>

[root@]# ps -ef | grep tomcat    [재구동 후 프로세스 확인]

[root@]# netstat -nlp | grep 8443    [SSL/TLS 연결 포트 확인]

※ 포트 응답 확인 시 LISTEN 응답이 없다면, 설정을 잘못했거나 인증서 파일에 문제가 있는지 재 확인

※ 참고사항

◇ 기존 방식 : <Connector 구문 내에/> keystoreFile / keystorePass 옵션을 사용 (대소문자 구분함, 주의)

◇ Tomcat 8.5 이상 : <Connector 구문 내에/> 별도의 <SSLHostConfig> 구문 사용 필요

 

③ 「JKS」→「PFX」 변환

[root@]# keytool -importkeystore -srckeystore java.jks -srcstoretype JKS -destkeystore new_java.pfx -deststoretype PKCS12    [JKS→PFX 변환, 전체 한 줄]

Enter destination keystore password:    [대상 키(PFX) 저장소 비밀번호 입력]

Re-enter new password:    [새 비밀번호 다시 입력]

Enter source keystore password:    [소스 키(JKS) 저장소 비밀번호 입력]

 

[root@]# openssl pkcs12 -info -in new_java.pfx    [인증서 확인]

 

④ 「Apache Tomcat - PFX」 인증서 적용 및 확인

※ 8.5 이상 버전이라 위와 같이 동일하게 세팅, 인증서 파일만 PFX로 경로 설정 변경

※ PFX 적용 시 「도메인인증서/체인인증서/루트인증서/개인키」 정보가 모두 포함되어야 합니다.

 

⑤ 「Apache Tomcat - APR」 인증서 적용 및 확인

※ Tomcat에서 APR(Apache Portable Runtime), CRT(PEM) 인증서를 직접 적용하는 방법입니다.

[root@]# vim /설치경로/conf/server.xml    [Apache Tomcat 설정 파일 중]

※ 프로토콜에서 「org.apache.coyote.http11.Http11AprProtocol」를 사용할 수도 있지만 「apr-devel tomcat-native」 별도의 라이브러리를 설치하여 Tomcat 구동 시 모듈을 불러와야 적용 가능, 여기서는 기본 세팅으로 진행

 

        <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"

               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
               maxParameterCount="1000" sslProtocol="TLS" URIEncoding="UTF-8">

            <SSLHostConfig>

            <Certificate certificateFile="/인증서경로/java/cert1.pem"

                                 certificateKeyFile="/인증서경로/java/privkey1.pem"

                                 certificateChainFile="/인증서경로/java/fullchain1.pem"

                                 certificateKeyPassword="개인키 암호가 있을 경우 옵션 포함" type="RSA" />

            </SSLHostConfig>

        </Connector>

---

◈ ETC.

[2024-09-10 추가 내용] 

 

① OpenSSL를 이용한 인증서 기간 확인[전체 한줄]

[root@]# echo | openssl s_client -connect localhost:443 2>/dev/null | openssl x509 -noout -dates
notBefore=May 31 11:38:34 2024 GMT    [발급일]
notAfter=Aug 29 11:38:33 2024 GMT    [만료일]

 

※ localhost:443 부분은 접근 호스트 부분으로 내부서버인 경우는 localhost(127.0.0.1) 외부서버일 경우 사설/공인IP 192.168.0.1 또는 example.com 네임주소를 입력합니다. (외부서버의 경우는 방화벽 허용 되어 있어야 함) 포트는 인증서가 적용된 접근 포트 입력, 예시로 HTTPS(443), HTTPS:(8443), SMTPS(465), POP3S(995), IMAPS(993)등을 말합니다.

[root@]# echo | openssl s_client -connect localhost:587 -starttls smtp 2>/dev/null | openssl x509 -noout -dates

notBefore=May 31 11:38:34 2024 GMT    [발급일]
notAfter=Aug 29 11:38:33 2024 GMT    [만료일]

 

※ 수발신 SMTP(25/587) 기본 포트같은 경우는 STARTTLS를 사용하므로 옵션중에 「-starttls smtp」를 넣어야 응답을 하고 값이 나옵니다.

 

② OpenSSL TLSv1.3 지원 확인

[root@mail ~]# openssl ciphers -v | grep -i 'tlsv1.3'

※ 값이 나오지 않으면 지원하지 않음, 「ciphers -v」 만 입력하면 지원하는 전체 리스트가 나옵니다. 

---

마치며...

 

이번에 적용 연습을 하면서 Apache Tomcat과 JAVA 쪽 공부가 많이 되었습니다. 솔루션들이 대체로 구버전만 이용하다 보니 Tomcat 8.5 이상부터 적용방식이 달라져서 시행착오를 많이 겪었네요. 설정 구성은 버전마다 미묘하게 달라질 수 있으니 인증서를 변환하여 여러 서버 및 소프트웨어에 적용을 할 수 있다는 것에 의의를 두시면 됩니다. 이 정도만 할 줄 알아도 한 80% 이상은 문제없지 않을까 개인적으로 생각해 봅니다.

 

JAVA log4j 취약점 이후로 오래간만에 긴 포스팅을 하게 되었네요. 

※ 이 내용은 새로운 내용이 포함될 경우 업데이트되거나 잘못된 부분은 수정될 수 있습니다.
※ 운영 입장에서 작성을 하였으므로 개발자분께서 알고 있는 부분이랑 다를 수 있으며, 내용이 긴 만큼 오타나 잘못된 정보가 포함되어 있다면 지적 및 정보 공유 감사합니다.