기술 튜토리얼
PEM 형식의 SSL 인증서를 도입하는 방법
인증 기관(CA)의 관리 화면에서 발급된 PEM 형식의 SSL 인증서를,
Ubuntu 24 + Apache + WordPress 환경에 도입하기 위한 일반적인 튜토리얼입니다.
Apache
WordPress
PEM SSL
면책 사항 #
본 문서는 Ubuntu 24 + Apache + WordPress 환경에서의 SSL 인증서(PEM 형식) 도입 방법에 대해 일반적인 절차를 설명하는 기술 튜토리얼입니다.
게재 내용은 작성 시점의 정보를 기반으로 하고 있으나, 특정 환경·구성·인증서 종류·CA 사양·미들웨어 버전 등에 따라 동작이나 설정 방법이 다를 수 있습니다.
개요 #
본 문서는 인증 기관(CA)의 관리 화면에서 발급된 PEM 형식의 SSL 인증서
(화면 내 텍스트 박스에 표시되는 타입)를,
Ubuntu 24 + Apache + WordPress 사이트에 도입하기 위한 일반적인 튜토리얼입니다.
EV / OV / DV 어느 인증서든, 서버 도입 절차는 기본적으로 동일합니다.
전제 조건 #
- OS: Ubuntu 24 (root 또는 sudo 권한 보유)
- Web: Apache(
apache2)가 가동 중 - CMS: WordPress가 Apache 하위에서 가동 중
- 인증서: CA로부터 서버 인증서(Server Certificate)가 발급 완료
- 중간 인증서: CA로부터 중간 인증서(Intermediate / CA Bundle)를 입수 가능
- 중요: CSR을 생성할 때의 개인 키(Private Key)를 보유하고 있음 (분실한 경우 재발급 필요)
CA 화면에서 발급되는 인증서 형식 (첨부와 같은 표시) #
CA의 관리 화면에서는 다음과 같은 블록(PEM)이 텍스트 박스에 표시될 수 있습니다. 이 블록을 처음부터 끝까지 복사하여 서버에 저장합니다.
-----BEGIN CERTIFICATE-----
(영숫자의 긴 덩어리)
-----END CERTIFICATE-----주의
BEGIN/END행을 포함하여 복사합니다.- 줄바꿈이 깨져도 동작할 수 있으나, 가능한 한 표시된 대로 붙여넣기 하는 것이 안전합니다.
- 개인 키(BEGIN PRIVATE KEY)를 붙여넣지 않도록 주의하세요.
도입의 전체 구성 #
- 인증서 파일을 소정의 위치에 저장한다
- 중간 인증서(체인)를 준비한다
- fullchain(서버 인증서 + 중간)을 만든다
- 개인 키와 인증서가 일치하는지 확인한다
- Apache의 HTTPS VirtualHost를 설정한다 (80 → 443 리다이렉트 포함)
- Apache를 리로드하고, WordPress의 URL / 혼재 콘텐츠를 정비한다
- 동작 확인 (체인·리다이렉트·인증서 정보)
절차 1인증서 파일 배치 (서버 인증서) #
Ubuntu의 일반적인 배치 예시입니다 (운영 정책에 맞게 변경 가능).
저장 위치 (예시) #
- 개인 키 (기존):
/etc/ssl/private/example.com.key - 서버 인증서:
/etc/ssl/certs/example.com.crt - 중간 인증서:
/etc/ssl/certs/intermediate-ca.pem - fullchain:
/etc/ssl/certs/example.com.fullchain.pem
디렉터리 생성 및 권한 #
sudo mkdir -p /etc/ssl/private /etc/ssl/certs
sudo chmod 700 /etc/ssl/privateCA 화면의 인증서 (PEM)를 파일로 저장 #
CA 화면의 텍스트 박스에 있는 인증서 블록을 /etc/ssl/certs/example.com.crt에 붙여넣어 저장합니다.
sudo nano /etc/ssl/certs/example.com.crt
sudo chmod 644 /etc/ssl/certs/example.com.crt로컬에서 자동 저장하고자 할 경우 예시:
sudo tee /etc/ssl/certs/example.com.crt >/dev/null <<'EOF'
-----BEGIN CERTIFICATE-----
(여기에 인증서 본문을 붙여넣기)
-----END CERTIFICATE-----
EOF
sudo chmod 644 /etc/ssl/certs/example.com.crt절차 2중간 인증서 (CA Bundle / Intermediate)를 준비한다 #
대부분의 CA에서는 서버 인증서와 별도로 중간 인증서(또는 CA Bundle)가 제공됩니다. 이것이 없으면 일부 단말에서 “신뢰할 수 없음”으로 표시되는 원인이 됩니다.
중간 인증서 저장 (예시) #
CA로부터 입수한 중간 인증서(1개 또는 여러 개)를 PEM 형식으로 아래에 저장합니다.
sudo nano /etc/ssl/certs/intermediate-ca.pem
sudo chmod 644 /etc/ssl/certs/intermediate-ca.pem중간 인증서가 여러 개인 경우 #
CA Bundle에 여러 개의 중간 인증서가 포함된 경우, CA의 안내에 따른 순서로 1개의 파일로 합칩니다(일반적으로 상위로 향하는 순서).
절차3fullchain(서버 인증서 + 중간)을 생성하기 #
Apache에서는 인증서 파일로 fullchain(서버 인증서 + 중간)을 지정하는 운영이 일반적입니다.
sudo cat /etc/ssl/certs/example.com.crt \
/etc/ssl/certs/intermediate-ca.pem \
| sudo tee /etc/ssl/certs/example.com.fullchain.pem >/dev/null
sudo chmod 644 /etc/ssl/certs/example.com.fullchain.pem절차4개인키와 인증서가 일치하는지 확인하기(중요) #
인증서와 개인키가 일치하지 않으면 Apache를 설정해도 HTTPS가 정상적으로 작동하지 않습니다. 반드시 확인합니다.
확인 방법A: RSA키의 경우(modulus 비교) #
openssl x509 -noout -modulus -in /etc/ssl/certs/example.com.crt | openssl md5
openssl rsa -noout -modulus -in /etc/ssl/private/example.com.key | openssl md52개의 MD5가 같으면 일치합니다.
확인 방법B: 키 종류에 의존하지 않음(공개키 SHA256 비교) #
# 인증서 → 공개키 → SHA256
openssl x509 -in /etc/ssl/certs/example.com.crt -pubkey -noout \
| openssl pkey -pubin -outform DER \
| openssl sha256
# 개인키 → 공개키 → SHA256
openssl pkey -in /etc/ssl/private/example.com.key -pubout -outform DER \
| openssl sha2562개의 SHA256이 같으면 일치합니다.
불일치한 경우 #
- 다른 개인키로 CSR을 만들었을 가능성이 높습니다.
- 올바른 개인키를 찾을 수 없는 경우, CA 측에서 재발행(Reissue)하여 올바른 키로 CSR을 다시 만들어야 합니다.
절차5Apache에서 HTTPS를 활성화하기 #
필요한 모듈 활성화 #
sudo a2enmod ssl
sudo a2enmod headers
sudo a2enmod rewrite
sudo systemctl reload apache2포트 443이 Listen되고 있는지 확인 #
일반적으로 /etc/apache2/ports.conf에 Listen 443이 포함됩니다. 필요에 따라 확인하세요.
절차6Apache의 VirtualHost 설정(443 + 80→443 리디렉션) #
여기서는 예시로 example.com용 사이트 설정 파일을 생성하여 도입합니다.
사이트 설정 파일 생성(예시) #
sudo nano /etc/apache2/sites-available/example.com.conf설정 예시(WordPress 가정) #
※ 코드 내의 example.com이나 DocumentRoot를 실제 환경에 맞게 변경하세요.
<VirtualHost *:80>
ServerName example.com
# HTTP -> HTTPS로 영구 리디렉션
RewriteEngine On
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName example.com
DocumentRoot /var/www/example.com/public
# WordPress용(.htaccess 운영 시)
<Directory /var/www/example.com/public>
AllowOverride All
Require all granted
</Directory>
SSLEngine on
# fullchain(서버 인증서 + 중간)을 지정
SSLCertificateFile /etc/ssl/certs/example.com.fullchain.pem
SSLCertificateKeyFile /etc/ssl/private/example.com.key
# 권장: 필요에 따라 활성화(우선 동작 확인을 먼저 수행)
# Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
ErrorLog ${APACHE_LOG_DIR}/example.com-ssl-error.log
CustomLog ${APACHE_LOG_DIR}/example.com-ssl-access.log combined
</VirtualHost>
</IfModule>사이트 활성화 #
sudo a2ensite example.com.conf설정 테스트 → 재로드 #
sudo apache2ctl configtest
sudo systemctl reload apache2어떤 VirtualHost가 활성화되어 있는지 확인하려면:
sudo apache2ctl -S절차 7WordPress 측의 https 화 #
사이트 URL을 https로 통일 #
- WordPress 관리 화면 → 설정 → 일반
- “WordPress 주소 (URL)” “사이트 주소 (URL)”를
https://example.com으로 맞춤
Mixed Content(혼재 콘텐츠) 대책 #
- 이미지나 CSS / JS가
http://인 채로 있으면, 자물쇠 마크가 사라지는 원인이 됩니다. - DB 치환, 테마 설정, 플러그인 등으로
https://로 통일해 주세요(작업 전 백업 권장).
절차 8동작 확인 #
HTTPS 통신(curl) #
curl -I https://example.com/
curl -I http://example.com/기대값:
https://example.com/이 200 / 301 등 정상 응답http://example.com/이 301로 https로 유도
인증서 체인 확인(openssl) #
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts브라우저 확인 #
- 인증서 오류가 발생하지 않을 것
- 인증서 상세에서 발급 대상 / 유효 기간 / SAN 등이 예상대로일 것
자주 발생하는 문제 및 대처 #
인증서가 올바른데 “신뢰할 수 없음”이라고 표시됨 #
- 중간 인증서(CA Bundle)가 제공되지 않았거나, fullchain에 포함되지 않았을 가능성이 있습니다.
SSLCertificateFile이 fullchain을 가리키고 있는지 확인하세요.
Apache 시작 / 리로드 시 SSL 오류로 중단됨 #
- 개인 키 경로가 잘못되었거나, 권한이 부적절하거나, 키와 인증서가 일치하지 않을 가능성이 있습니다.
- “절차 4″의 일치 확인을 재실시하세요.
리다이렉트 루프가 발생함 #
- WordPress 측(siteurl / home)과 Apache 측(80 → 443)이 이중으로 모순되어 있을 수 있습니다.
- Cloudflare 등의 CDN / 리버스 프록시가 있는 경우, SSL 모드 설정의 영향도 받습니다.
롤백(되돌리기) #
- 도입 전에, Apache의 사이트 설정 파일과 인증서 관련 파일의 백업을 권장합니다.
- 문제가 발생한 경우, 해당 사이트를 비활성화하고 리로드합니다.
sudo a2dissite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2운영 메모(갱신·재발급) #
- 갱신 / 재발급 시의 기본: 새 CSR → CA에서 재발급 / 갱신 → fullchain 교체 → Apache reload
- 개인 키 유출 의심: 폐기(Revoke) → 새 키로 CSR 생성 → 재발급
- 인증서 파일은 변경하지 않고, 발급물(PEM)을 정확히 보존할 것