* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
(pfSense 홈랩 방화벽 ㉒)
pfSense 웹GUI는 기본적으로 자체 서명 인증서를 쓰기 때문에 브라우저가 '안전하지 않음' 경고를 띄운다. OpenVPN에서 이미 CA와 인증서를 잠깐 만졌는데, 이번 편에서 그 인증서 관리자를 제대로 정리한다. 한 번 이해하면 VPN·웹GUI·내부 서비스에 두루 쓴다.
CA · 인증서의 구조
- CA(인증 기관) — 인증서를 발급·보증하는 도장. 내부용 CA를 하나 만든다.
- 서버 인증서 — 그 CA가 서명해 발급. 웹GUI·서비스가 '나는 이 도메인이다'를 증명.
- 사용자 인증서 — 클라이언트(예 VPN 사용자) 신원 증명용.
핵심은, 내가 만든 CA를 각 기기의 '신뢰하는 인증 기관'에 등록하면, 그 CA가 서명한 모든 내부 인증서를 브라우저가 군말 없이 믿는다는 점이다. 그래서 CA 하나만 신뢰시켜 두면 내부 서비스 전부가 깔끔한 자물쇠로 열린다.
웹GUI를 신뢰 HTTPS로
System > Cert Manager에서 내부 CA를 만들고, pfSense 호스트명으로 서버 인증서를 발급한다. 그다음 System > Advanced > Admin Access에서 웹GUI 인증서를 방금 만든 것으로 바꾼다. 마지막으로 CA를 관리 PC의 신뢰 저장소에 설치하면, 경고 없이 접속된다.
직접 해보기
- Cert Manager에서 내부 CA를 생성한다.
- pfSense용 서버 인증서를 발급하고 웹GUI 인증서로 교체한다.
- CA를 관리 PC에 신뢰 등록하고, 경고 없이
https로 접속되는지 확인한다.
✅ 확인 — 브라우저 경고 없이 pfSense 웹GUI가 열리면 성공이다. CA를 신뢰시키는 것이 왜 '한 방에' 내부 인증서를 다 믿게 하는지 설명해 보자.
기기별 CA 설치 — 실제 절차
‘신뢰 저장소에 설치’가 제일 손짓으로 넘어가기 쉬운 단계라, 기기별로 못박아 둔다. 먼저 System > Cert Manager > CAs에서 CA의 인증서(.crt)만 내보낸다 — 개인키는 절대 아니다.
| 기기 | 절차 |
|---|---|
| Windows | crt 더블클릭 → 인증서 설치 → 저장소를 ‘신뢰할 수 있는 루트 인증 기관’으로 직접 지정(자동 선택이면 안 됨) |
| macOS | 키체인 접근 → 시스템에 끌어다 놓기 → 더블클릭 → 신뢰 → ‘항상 신뢰’ |
| iOS | crt를 AirDrop/메일로 → 설정 > 프로파일 설치 → 설정 > 일반 > 정보 > 인증서 신뢰 설정에서 스위치 켜기(이 두 번째 단계를 다들 빼먹는다) |
| Android | 설정 > 보안 > 인증서 설치 > CA 인증서 — 단, 앱들이 사용자 CA를 신뢰할지는 앱마다 다르다(브라우저는 대체로 OK) |
설치 후에도 경고가 나면 브라우저를 완전히 재시작하고, 인증서의 주소(호스트명/IP)와 실제 접속 주소가 일치하는지 확인한다 — CA를 믿어도 이름이 다르면 경고는 계속된다.
인증서 만료 관리
인증서에는 유효기간이 있다. 만료되면 다시 경고가 뜨고 VPN이 끊길 수 있다. 내부 CA는 유효기간을 넉넉히(수년) 잡되 만료일을 기록해 두자. pfSense는 대시보드 위젯과 인증서 목록에서 만료가 임박한 걸 보여준다. 갱신할 땐 CA는 그대로 두고 서버 인증서만 재발급하면 기기들의 신뢰가 그대로 유지된다.
공인 인증서 vs 내부 CA — 언제 무엇을
| 내부 CA(자체) | 공인(Let’s Encrypt 등) | |
|---|---|---|
| 대상 | 내부 전용 서비스·VPN | 외부 공개 서비스 |
| 신뢰 | 내 기기에 CA 등록 필요 | 브라우저가 기본 신뢰 |
| 자동화 | 무료·수동 | 무료·ACME 자동 갱신 |
pfSense는 ACME 패키지로 Let’s Encrypt 인증서를 자동 발급·갱신할 수 있다. 도메인이 있고 서비스를 외부에 공개한다면, 웹GUI에도 공인 인증서를 붙여 경고를 근본적으로 없앨 수 있다.
실전 팁 — CA 개인키는 뿌리다
내부 CA의 개인키는 이 신뢰 체계 전체의 뿌리다. 유출되면 누군가 내 내부 서비스를 사칭할 수 있으니 함부로 노출하지 말자. 반대로 CA를 잃으면 새로 만들어 모든 기기에 다시 등록해야 한다. 다행히 설정 백업(27편)에 인증서가 함께 담기니, 백업만 잘 챙기면 이 뿌리도 함께 보존된다.
다음 편은 손님을 위한 기능이다. 게스트 와이파이에 로그인 페이지를 붙이는 Captive Portal이다.
🔧 현장에서 — Wildcard 인증서를 오해하기 쉽다
*.domain.com 인증서가 여러 단계 서브도메인까지 다 커버할 것으로 생각하기 쉽다. 하지만 a.domain.com은 되어도 a.b.domain.com까지 자동으로 커버되진 않는다. 그래서 파일명이나 CN이 아니라 Certificate SAN을 기준으로 실제 지원 도메인을 확인했고, 다단계 서브도메인이 필요하면 추가 SAN이나 별도 Wildcard를 준비했다.
교훈 — SSL 인증서는 파일 이름이나 CN이 아니라 반드시 SAN을 확인하라.
자주 묻는 질문 (FAQ)
웹GUI HTTPS 경고는 왜 뜨나요?
자체 서명 인증서라 브라우저가 신뢰하지 않기 때문입니다. 내부 CA를 만들어 그 CA를 기기에 신뢰시키면 경고가 사라집니다.
내부 CA를 만들면 뭐가 좋나요?
내부 서비스(웹GUI·리버스 프록시 등)에 신뢰되는 인증서를 발급할 수 있어, 사설망에서도 HTTPS 경고 없이 씁니다.
답글 남기기