Nginx TLS 운영 — 인증서 배치·키 처리·Reload·Process 복구
Nginx TLS 운영을 인증서 설정 상속, Private Key 처리, Config Test→Reload, PID·Port 문제 복구라는 네 단계로 정리한다.
Nginx TLS 운영에서 자주 섞이는 문제는 네 층으로 나누면 된다.
1
2
3
4
5
6
7
Certificate를 어디에 선언할까?
↓
Private Key를 어떻게 보호할까?
↓
설정 변경을 어떻게 적용할까?
↓
Process/PID/Port가 꼬이면 어떻게 복구할까?
이 네 질문은 서로 연결되지만 같은 문제는 아니다.
1. 같은 인증서를 여러 Server가 쓴다면 설정의 소유 위치부터 정한다
ssl_certificate, ssl_certificate_key는 http와 server Context에서 사용할 수 있으므로, 같은 인증서를 여러 server가 공유하는 구조라면 상위 http에 공통값을 두고 필요한 Server에서만 Override할 수 있다.
1
2
3
4
5
6
http {
ssl_certificate /etc/nginx/ssl/example.fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/example.key;
include /etc/nginx/conf.d/*.conf;
}
1
2
3
4
5
6
7
8
server {
listen 443 ssl;
server_name app.example.com;
location / {
proxy_pass http://app_backend;
}
}
하지만 “중복 두 줄을 줄인다”는 이유만으로 상위에 올릴 필요는 없다.
1
2
3
4
5
모든 TLS Server가 같은 Certificate Policy
→ 공통 상위 설정 고려
Host별 Certificate가 다름
→ 각 server에 명시
SNI로 Host별 Certificate를 선택하는 일반적인 Public Web 구조에서는 server별 인증서가 더 명확할 수 있다.
2. Private Key의 Passphrase는 자동화와 Key 보호 사이의 선택이다
Passphrase가 걸린 Private Key를 사용하면 Nginx 시작/Reload 시 Key를 해독할 방법이 필요하다.
운영 자동화를 위해 Passphrase 없는 Key를 사용하는 환경도 많다.
1
2
3
4
5
6
openssl pkey \
-in encrypted.key \
-out nginx.key
chmod 600 nginx.key
chown root:root nginx.key
이 경우 Key는 File System에 평문 Private Key로 존재하므로:
1
2
3
4
File Permission
Backup 접근 권한
Host 자체 보안
Secret 배포 경로
가 방어 경계가 된다.
Nginx의 ssl_password_file을 사용할 수도 있지만 Password를 Server 어딘가에 자동으로 제공해야 한다는 운영 문제가 남는다. 따라서 “Passphrase 제거가 무조건 정답”보다 재시작 자동화 요구와 Secret 관리 체계에 맞춰 결정한다.
3. 설정 변경은 Config Test → Reload가 기본 흐름이다
실행 중인 Nginx에 설정을 반영하려면 새 Master Process를 중복 실행하는 것이 아니라 기존 Master에 Reload를 요청한다.
1
2
sudo nginx -t
sudo nginx -s reload
Systemd 환경이라면:
1
sudo nginx -t && sudo systemctl reload nginx
흐름은:
1
2
3
4
5
6
7
8
9
Config 파일 변경
↓
nginx -t
↓ 성공
Reload
↓
새 Worker가 새 설정으로 시작
↓
기존 Worker는 처리 중 Connection 정리 후 종료
따라서 정상 운영에서는 “설정 수정 → nginx 명령을 다시 실행”보다 검증 후 Reload가 기본이다.
4. Address already in use는 새 Process를 띄우려 했는지 본다
이미 Nginx가 443을 Listen하고 있는데 별도 Nginx Master를 다시 시작하면:
1
2
bind() to 0.0.0.0:443 failed
Address already in use
같은 오류가 날 수 있다.
먼저 실제 Listener와 Process를 확인한다.
1
2
sudo ss -lntp | grep ':443'
ps -ef | grep '[n]ginx'
1
2
3
4
5
6
7
8
기존 Nginx 정상 실행 중
→ Reload
다른 Process가 Port 점유
→ 그 Process가 무엇인지 확인
Nginx Process/PID 상태 이상
→ 아래 복구 흐름
으로 분기한다.
5. PID 파일이 실제 Process와 어긋날 때
nginx -s reload나 stop이 PID 관련 오류를 내면 먼저 nginx.pid만 지우지 말고 실제로 살아 있는 Master Process가 있는지 확인한다.
1
2
ps -ef | grep '[n]ginx'
sudo ss -lntp | grep nginx
Master가 정상적으로 살아 있으면 정확한 Process 관리 경로를 사용한다. Systemd로 관리되는 서비스라면 우선:
1
2
systemctl status nginx
systemctl reload nginx
를 기준으로 한다.
수동 실행 Process가 꼬였고 종료가 필요하다면 단계적으로 Signal을 사용한다.
1
2
3
4
5
6
7
8
QUIT
→ Graceful Shutdown
TERM
→ 빠른 종료 요청
KILL
→ Process가 응답하지 않을 때 마지막 수단
무조건 pkill -9 nginx부터 실행하면 처리 중 Connection과 상태를 강제로 끊으므로 마지막 수단으로 둔다.
6. 복구 뒤에는 Config가 아니라 Runtime까지 검증한다
1
2
3
sudo nginx -t
sudo systemctl reload nginx
sudo ss -lntp | grep ':443'
TLS Endpoint까지 확인하려면:
1
2
3
4
openssl s_client \
-connect app.example.com:443 \
-servername app.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
1
2
3
Config Test 성공
≠
외부 Client가 올바른 Certificate를 받고 있음
이므로 실제 Handshake까지 확인한다.
정리
1
2
3
4
5
6
7
8
9
10
11
Certificate 배치
→ 공통 Policy인가 Host별 Policy인가
Private Key
→ 자동화와 Secret 보호 경계
설정 적용
→ nginx -t → reload
장애 복구
→ Process → PID → Port → TLS Endpoint 순으로 확인
TLS 운영은 인증서 파일 두 개를 적는 문제가 아니라 설정 상태와 실행 중 Runtime을 일치시키는 작업이다.
Nginx HTTPS 시리즈
| 글 | 다루는 것 |
|---|---|
| Let’s Encrypt + Nginx — 인증서 수명주기 | Challenge 선택 → 발급 → Renewal → Reload → 외부 TLS 검증 |
| Nginx TLS 운영 (현재 글) | 인증서 배치, Private Key, Reload, Process 복구 |
| 특정 IP에서 HTTPS 강제 우회하기 | 내부 Probe 같은 예외 Routing |
| apex/www Origin과 Cache | Host별 Browser State와 Canonical Redirect |