이 글의 목적은 크롬·엣지·사파리 등 브라우저에서 발생하는 NET::ERR_CERT_AUTHORITY_INVALID 인증서 오류의 원인과 현장 대응 절차를 체계적으로 정리하여, 관리자·개발자·보안담당자가 즉시 복구하고 재발을 방지할 수 있도록 돕는 것이다.
1. 오류의 의미와 발생 메커니즘
NET::ERR_CERT_AUTHORITY_INVALID는 방문한 사이트의 서버 인증서를 신뢰할 수 없음을 뜻하며, 핵심은 신뢰 사슬(chain of trust) 검증 실패이다. 브라우저는 서버 인증서→중간(체인) 인증서→루트 인증서 순으로 신뢰 사슬을 구성하여 검증한다. 다음 상황에서 실패한다.
- 자체서명(self-signed) 인증서를 공용 인터넷 서비스에 사용한 경우이다.
- 중간 인증서 누락으로 서버 인증서에서 루트까지 사슬이 이어지지 않는 경우이다.
- 사설 CA(기업 프록시·보안 게이트웨이 등)의 루트 인증서가 단말 신뢰 저장소에 배포되지 않은 경우이다.
- 루트 또는 중간 인증서가 폐기·만료되었거나 약한 알고리즘 정책에 의해 거부된 경우이다.
- 엔드포인트 보안 제품이 TLS 트래픽을 가로채는 과정에서 재서명한 인증서를 단말이 신뢰하지 못하는 경우이다.
- 클라이언트 시스템 시간 오차로 인증서 유효기간 검증이 실패하는 경우이다.
2. 현장 즉시 점검 체크리스트(5분 요약)
| 항목 | 확인 방법 | 정상 기준 |
|---|---|---|
| 시스템 날짜·시간 | OS 시간대·NTP 동기화 점검 | 표준시와 ±1분 이내 |
| 도메인 일치 | 주소창 FQDN과 인증서 SAN 비교 | SAN에 요청 FQDN 포함 |
| 체인 완전성 | openssl s_client -connect 도메인:443 -servername 도메인 -showcerts | 서버→중간→루트 순서로 모두 제공 |
| CA 신뢰 | 클라이언트 신뢰 저장소에서 발급자 확인 | 공개 신뢰 루트 또는 사내 루트 등록 |
| 보안 프록시 개입 | 회사 네트워크/프록시 우회 후 재시도 | 우회 시 정상 접속이면 프록시 원인 |
3. 근본 원인별 해결 절차
3.1 중간 인증서 누락
상용 CA 인증서를 설치했지만 체인 파일(fullchain)이 아닌 서버 단일 인증서만 배포한 경우 발생한다.
- CA에서 제공하는 fullchain 또는 bundle 파일을 내려받는다.
- 웹서버에 서버 인증서(
server.crt)와 개인키(server.key), 체인(fullchain.pem)을 모두 설정한다. - 웹서버를 재시작하고
openssl s_client로 체인을 재검증한다.
Apache 예시
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCertificateChainFile /etc/ssl/certs/fullchain.pem
</VirtualHost>
Nginx 예시
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/ssl/certs/fullchain.pem; # 서버+중간 포함
ssl_certificate_key /etc/ssl/private/server.key;
} 3.2 사설 CA 또는 SSL 가로채기(기업 프록시)
기업 DLP/방화벽/백신이 TLS 가시화를 위해 트래픽을 복호화하고 사설 CA로 재서명할 수 있다. 단말이 그 루트를 신뢰하지 않으면 오류가 발생한다.
- 사내 루트 인증서의 지문(SHA-256)과 배포 경로를 확인한다.
- Windows는 그룹 정책(GPO), macOS는 MDM으로 루트를 신뢰로 배포한다.
- 테스트용 단말에서 프록시 우회(모바일 테더링 등) 후 정상 접속되면 프록시 설정을 수정한다.
- 금융·정부 등 민감 도메인은 TLS 가로채기 제외 규칙을 설정한다.
3.3 자체서명 인증서 사용(개발·사내 포털)
인터넷 공개 서비스에는 금지한다. 내부망 또는 개발 환경에서만 다음 절차를 사용한다.
- 개발 환경은
mkcert와 같은 로컬 신뢰 도구로 각 단말 신뢰 저장소에 루트를 설치한다. - 도메인별 SAN을 포함해 인증서를 재발급한다.
- 내부 DNS·호스트 파일과 일관되게 FQDN을 사용한다.
3.4 루트/중간 인증서 만료·정책 불일치
OS·브라우저 신뢰 저장소가 구버전이거나 루트 교체가 반영되지 않으면 발생한다.
- Windows Update, macOS 업데이트, 모바일 OS 업데이트를 적용한다.
- 서버 측은 최신 체인으로 재발급하고, 만료 임박 시 사전 전환한다.
- 유효기간·키 길이·서명 알고리즘이 최신 브라우저 정책을 만족하는지 점검한다.
3.5 시스템 시간 오차
도메인·체인에 문제가 없어도 단말 시간이 틀리면 유효기간 검증이 실패한다.
- NTP 동기화 활성화 및 표준시 서버 지정한다.
- 가상머신·듀얼부팅 환경은 시간 동기 정책을 통일한다.
4. 역할별 복구 시나리오
| 역할 | 즉시 조치 | 근본 개선 |
|---|---|---|
| 웹서버 관리자 | fullchain 설치, SNI 설정 검증, 재시작 후 체인 점검 | 자동 갱신 파이프라인 구축, 사전 만료 알림, 스테이징 검증 |
| 네트워크/보안 | TLS 가로채기 예외 목록 적용, 사내 루트 신뢰 배포 | 프록시 인증서 수명·알고리즘 정책 최신화, 감사 로그 관리 |
| 엔드유저 지원 | 시간 동기화, 브라우저/OS 업데이트, 보안제품 일시 우회 테스트 | 표준 이미지 관리, 신뢰 저장소 중앙관리 |
5. 진단 명령어 실무 예시
5.1 체인 확인
# 서버가 중간 인증서를 제공하는지 점검
openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null | openssl x509 -noout -issuer -subject -dates
5.2 프로토콜·암호군 확인
# 서버 설정 개요 확인
nmap --script ssl-enum-ciphers -p 443 example.com
5.3 신뢰 저장소로 수동 검증
# 특정 루트/체인으로 신뢰 검증
curl -v https://example.com --cacert /path/to/ca-bundle.pem
6. 웹서버별 구성 포인트
6.1 Nginx
ssl_certificate는 서버+중간 포함 파일을 지정한다.- 멀티도메인일 경우 SNI별
server_name블록을 분리한다. - 자동 갱신 후 핫 리로드(
nginx -s reload)를 수행한다.
6.2 Apache httpd
SSLCertificateFile,SSLCertificateKeyFile,SSLCertificateChainFile를 모두 지정한다.- 가상호스트별
ServerName과 SAN 일치를 확인한다.
6.3 IIS
- 인증서 스토어의 개인키 매핑을 확인한다.
- SNI 사용 사이트는 바인딩마다 호스트 이름을 명시한다.
7. 모바일·클라이언트 특이사항
- iOS·macOS는 사용자 설치 루트를 기본적으로 신뢰 안 함으로 배포 정책에서 신뢰를 명시한다.
- Android 7.0 이상은 사용자 CA를 앱이 기본 신뢰하지 않는다. 앱 네트워크 보안 구성에 CA를 선언해야 한다.
- 모바일 MDM으로 루트/중간을 푸시 배포하여 일관성을 유지한다.
8. 운영 정책과 재발 방지
- 인증서 수명 주기(Lifecycle)를 CMDB에 등록하고 만료 30·14·7일 전 다중 알림을 설정한다.
- 갱신 자동화(예: ACME)와 스테이징 환경 사전 검증을 표준화한다.
- 체인지 관리 시 체인 파일 동시 교체를 필수 항목으로 포함한다.
- 프록시 TLS 가시화 예외 도메인 목록을 정기 재검토한다.
- 취약 루트/중간 폐기 공지 모니터링으로 선제 대응한다.
9. 사용자 측 임시 우회에 대한 경고
경고 화면에서 “고급”→“계속”은 금지한다. 중간자 공격 위험이 있으며, HSTS 사이트는 우회 자체가 불가능하다. 업무 연속성이 필요하면 네트워크 변경(테더링), 프록시 우회 테스트, 다른 브라우저/단말에서 재현 확인만 수행한다.
10. 사례 기반 원인-해결 매핑
| 증상 | 가능 원인 | 해결 |
|---|---|---|
| 사내망에서만 오류, 외부망 정상 | 프록시 재서명, 사설 CA 미배포 | 사내 루트 신뢰 배포, 예외 도메인 설정 |
| 모바일만 오류 | 모바일 신뢰 저장소 미동기 | MDM로 루트/중간 배포, 앱 네트워크 보안 구성 수정 |
| 일부 브라우저에서만 오류 | 체인 파일 순서·포맷 문제 | PEM 순서 정정, fullchain 사용 |
| 간헐적 발생 | 로드밸런서 노드별 인증서 상이 | 모든 노드에 동일 인증서/체인 동기화 |
| 개발 서버만 오류 | 자체서명 인증서 | 사설 루트 신뢰 배포 또는 ACME 스테이징 활용 |
11. 점검 절차 표준 운영안(SOP)
- 현상 파악: 브라우저·OS·네트워크·시각·도메인 기록한다.
- 재현성 확인: 사내망/외부망, 다른 단말·브라우저에서 비교한다.
- 체인 수집:
openssl s_client로 서버 제공 체인을 저장한다. - 체인 검토: SAN·유효기간·발급자·서명 알고리즘을 점검한다.
- 서버 수정: fullchain 적용, SNI·바인딩 정합성 확인 후 재시작한다.
- 프록시 검토: TLS 가시화 정책과 루트 배포 상태를 점검한다.
- 클라이언트 정리: 시간 동기화, 캐시/SSL 상태 초기화, OS 업데이트한다.
- 사후 검증: 외부 스캐너·명령어로 체인과 암호군을 재확인한다.
- 재발 방지: 만료 알림·자동 갱신·예외 도메인·운영 대시보드 구축한다.
12. 자주 하는 실수와 예방
- 서버 인증서만 교체하고 중간 인증서를 갱신하지 않는 실수이다.
- 멀티도메인 와일드카드의 SAN 누락이다.
- 로드밸런서 SSL 종료 지점과 백엔드 체인 불일치이다.
- 프록시 제외 리스트에 와일드카드 적용 누락이다.
13. 보안 정책 관점의 권장 설정
- HSTS는 유지한다. 오류 우회를 통한 접속은 금지한다.
- TLS 1.2 이상만 허용하고 취약 암호군을 제거한다.
- 키 관리는 HSM 또는 전용 금고에 보관한다.
- 중요 도메인은 멀티 CA 전략과 장애 대비 핫스왑 절차를 마련한다.
FAQ
브라우저에서 ‘안전하지 않음’ 경고를 무시하고 접속해도 되는가?
권장하지 않는다. 중간자 공격 위험이 있으며, HSTS 활성 사이트는 우회가 불가하다. 원인을 제거하는 것이 유일한 해결책이다.
ERR_CERT_COMMON_NAME_INVALID와 무엇이 다른가?
COMMON_NAME_INVALID는 도메인 불일치가 원인이다. AUTHORITY_INVALID는 신뢰 사슬 실패가 원인이다. 증상은 유사하지만 원인과 해결이 다르다.
사내 프록시를 사용해야 한다. 안전하게 TLS 가시화를 유지하는 방법은?
사내 루트를 단말 신뢰 저장소에 배포하고, 금융·정부 등 민감 도메인을 예외 처리하며, 재서명 인증서의 알고리즘·수명 정책을 최신 표준에 맞춘다.
개발 환경에서만 자체서명 인증서를 쓰고 싶다. 어떻게 해야 하나?
로컬 신뢰 도구로 자체 루트를 설치하고 SAN을 정확히 지정한다. 공용 인터넷 서비스에는 사용하지 않는다.
체인이 맞는데도 간헐적으로 오류가 뜬다.
로드밸런서 노드별 인증서·체인이 불일치하거나 SNI 라우팅 오구성이 원인일 수 있다. 모든 노드를 동기화하고 헬스체크로 검증한다.