2026년 7월
진행 중웹 인증서 자동화 사내 PKI
사설 ACME 인증기관(step-ca)을 설계·구축하여 KAIST 웹서버 TLS 인증서를 무인 발급·갱신 — 만료 장애도, 수작업 요청도 없이. (진행 중)
- PKI
- TLS
- 자동화
- step-ca
- DevSecOps
개요
사내 웹서버는 모두 TLS 인증서가 필요합니다 — 그리고 이를 수작업으로 발급·갱신하면 통신팀에 대한 반복 요청과, 결국은 만료로 인한 장애가 발생합니다. 저는 **사내 인증서 자동화(PKI)**를 설계·구축하고 있습니다: 각 서버의 인증서를 자동으로 발급·갱신하는 **사설 ACME 인증기관(step-ca)**을 두어, 담당자는 명령 한 줄을 한 번만 실행하면 이후는 무관리로 동작합니다.
상태: KAIST 정보보안팀과 함께 설계·구축 진행 중.
아키텍처
설계상 두 개의 독립 경로:

- 서비스 트래픽 — WAF 경유. 사용자 → 관문 WAF → 전산실 WAF → 원본 웹서버
(Nginx / Apache / IIS), 각 구간에서 443으로 재암호화. WAF는 공인 와일드카드 인증서
(
*.kaist.ac.kr)를 보유하고, 각 원본 서버는 자동 갱신되는 전용 인증서를 보유합니다. - 인증서 발급·갱신 — WAF를 거치지 않는 직접 통신. 서버는 내부망에서 step-ca와 직접 통신합니다. 최초 부트스트랩만 관문 WAF를 경유하는데, 갓 배포된 서버는 아직 내부 CA를 신뢰하지 않으므로 Root CA를 공인 인증서로 안전하게 받아야 하기 때문입니다.
보조 구성요소: 자동 등록을 위한 step-ca의 온보딩 API(발급 정책은 *.kaist.ac.kr로 한정), 각
도메인을 실제 원본으로 해석하는 CA 전용 리졸버, 그리고 서버로 배포되는 cert-setup 설치
파일(최초 1대만 수동 설치).
발급 동작 방식

- Root CA 수신 — 최초 1회, 관문 WAF 경유, 공인 인증서로 안전하게 신뢰.
- 발급 요청 — 서버가 step-ca와 직접 통신(WAF 무관).
- 원본 주소 해석 — CA가 전용 리졸버로 도메인의 실제 서버 위치를 확인.
- 소유 확인 후 발급 — CA가 웹서버 80 포트로 접속해 소유를 검증한 뒤 발급.
1단계는 최초 1회만 수행되고, 이후 2~4단계가 갱신 때마다 자동으로 반복됩니다.
통신 포트
| 출발지 | 목적지 | 포트 | 용도 |
|---|---|---|---|
| 사용자 | 관문 WAF | 443 | 서비스 |
| 관문 WAF | 전산실 WAF | 443 | 전달 |
| WAF | 원본 웹서버 | 443 | 재암호화 |
| 웹서버 | step-ca | 443 | 발급 · 갱신 |
| step-ca | CA 리졸버 | 53 | 이름 해석 |
| step-ca | 웹서버 | 80 | 소유 확인 |
| step-ca | NTP | 123 | 시각 동기 |
| 관리 대역 | step-ca | 22 | 운영 관리 |
설계 선택
- WAF 우회 발급 경로로 자동화 트래픽을 서비스 경로에서 분리하고, 최초 1회 WAF 부트스트랩으로 “신규 서버가 아직 내부 CA를 신뢰하지 않는” 문제를 해결.
- 발급 정책을
*.kaist.ac.kr로 고정하여 내부 CA가 발급할 수 있는 대상을 제한. - NTP + 단기 인증서로 ACME 흐름의 정확성을 확보하고 피해 범위를 축소.
기대 효과
- 서버당 명령 한 줄, 이후 무관리 — 통신팀에 대한 반복 요청 제거.
- 인증서 만료 장애 없음, 갱신은 완전 자동화.