SSL Certificate with Wrong Hostname(45411), 인증서를 고쳐야 할까? — PCI DSS ASV 스캔 대응 실무

 

PCI DSS ASV 스캔이나 내부 정기 스캔 결과를 열어보면 거의 매번 올라오는 항목이 있습니다.

 

SSL Certificate with Wrong Hostname (Plugin ID: 45411)

 

"인증서 호스트명이 틀렸다"는 말만 보면 인증서를 잘못 발급받은 것 같은데, 정작 브라우저로 접속해보면 자물쇠도 멀쩡하고 경고도 안 뜹니다. 그래서 "이거 오탐 아니냐"는 말이 나오고, 소명을 넣었다가 반려당하고, 결국 인증서를 다시 발급받아야 하나 고민하게 됩니다.

 

이 글에서는 왜 브라우저는 멀쩡한데 스캐너만 걸리는지, 정말 조치가 필요한 경우는 언제인지, 그리고 하면 안 되는 조치는 무엇인지를 정리했습니다.

---

🎯 취약점 내용

스캐너가 출력하는 설명은 이렇습니다.

이 서비스가 제시한 SSL 인증서의 commonName(CN) 속성이 다른 장비의 것이다.

Solution: 이 서비스에 맞는 SSL 인증서를 구매하거나 생성하라.

플러그인 정보

항목	값
Plugin ID	45411
File Name	ssl_cert_wrong_host.nasl
Family	General
Risk Factor	Medium
CVSS v2 Base	5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N)
CVSS v3 Base	5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N)

 

Output 예시

The identity known by Nessus is :
  <대상 IP>

The Common Name in the certificate is :
  *.example.co.kr

The Subject Alternate Names in the certificate are :
  *.example.co.kr

여기서 첫 줄이 핵심입니다. The identity known by Nessus is 항목에 무엇이 찍혀 있는지가 이 결함의 성격을 결정합니다.

---

🧩 왜 이게 취약점으로 잡히나요?

TLS 핸드셰이크가 끝나면 클라이언트는 두 가지를 검증합니다.

1. 신뢰 검증 — 이 인증서가 신뢰할 수 있는 CA가 발급한 유효한 것인가
2. 신원 검증 — 이 인증서가 내가 접속하려던 그 대상의 것인가

 

 

1번만 통과하고 2번이 깨지면 어떻게 될까요? 공격자가 자기 소유의 정상 도메인 인증서를 들고 중간에 끼어들어도 클라이언트가 이를 구분하지 못합니다. 인증서 자체는 유효하니까요.

즉 신원 검증은 TLS 신뢰 체인의 마지막 연결 고리이고, 이게 빠지면 앞의 암호화가 아무 의미가 없어집니다. 스캐너가 Medium을 매기는 이유입니다.

💡 참고로 CN 필드는 신원 검증 용도로는 이미 폐기된 필드입니다. 현대 브라우저는 CN을 보지 않고 SAN(Subject Alternative Name)만 확인합니다. 플러그인 이름과 설명에 "commonName"이 남아 있는 건 2010년에 만들어진 플러그인이라 그런 것이고, 실제 판정은 SAN까지 함께 봅니다.

---

🔍 그런데 대부분은 "스캐너 관점"의 불일치입니다

Output 첫 줄이 IP 주소로 찍혀 있다면, 이야기가 완전히 달라집니다.

The identity known by Nessus is :
  203.0.113.10          ← 스캐너는 IP로 접속했다

The Common Name in the certificate is :
  *.example.co.kr       ← 인증서는 도메인용이다

스캐너가 IP로 접속했기 때문에 203.0.113.10과 *.example.co.kr을 비교했고, 당연히 불일치가 났습니다. 실제 사용자는 www.example.co.kr로 접속하니 아무 문제가 없는데도 말이죠.

왜 IP는 절대 매칭되지 않나요?

CA/B Forum Baseline Requirements에 따르면, 인증서에 IP 주소를 담으려면 반드시 SAN 확장의 iPAddress 형식으로 넣어야 하며 dNSName 형식에 넣어서는 안 됩니다.

즉 dNSName: *.example.co.kr은 구조적으로 IP를 커버할 수 없습니다. 와일드카드를 아무리 넓게 써도 마찬가지입니다.

와일드카드 매칭 규칙

이 부분에서 착각이 많아 표로 정리합니다. 인증서에 *.example.co.kr이 들어 있을 때:

접속 대상	매칭	비고
www.example.co.kr	✅	정상 매칭
api.example.co.kr	✅	정상 매칭
example.co.kr	❌	apex 도메인은 커버 안 됨
dev.api.example.co.kr	❌	와일드카드는 한 레이블만 매칭
203.0.113.10	❌	IP는 iPAddress SAN에만 가능

apex 도메인이 안 걸리는 건 실무에서 자주 놓치는 부분입니다. example.co.kr로도 서비스한다면 SAN에 별도로 넣어야 합니다.

---

⚠️ 진짜 조치가 필요한 경우 vs 아닌 경우

같은 45411이라도 성격이 다릅니다. 실제 클라이언트가 어떤 이름으로 접속하느냐로 판단하세요.

상황	실제 위험	조치
사용자·연동 시스템이 모두 FQDN으로 접속. 스캐너만 IP로 접근	낮음	조치 불필요 → Dispute(예외) 처리
배치·모니터링·내부 API가 IP를 하드코딩해서 접속	높음	조치 필요
apex 도메인(example.co.kr)으로도 서비스 중	높음	SAN 추가 발급
2단계 이상 서브도메인으로 서비스 중	높음	SAN 추가 또는 별도 발급
인증서가 아예 다른 서비스의 것(장비 기본 인증서 등)	높음	정상 인증서 교체

🚨 IP 하드코딩 경로는 반드시 확인하세요

이게 이 항목에서 진짜 건질 게 있는 지점입니다.

IP로 직접 접속하는 내부 연동이 있다면, 그쪽은 십중팔구 인증서 검증을 꺼놓고 돌아가고 있습니다. 안 그러면 애초에 연동이 안 됐을 테니까요.

# 흔히 보이는 패턴
requests.get("https://203.0.113.10/api", verify=False)

curl -k https://203.0.113.10/api

// Java에서 더 위험한 형태 — 전역으로 검증을 무력화
HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> true);

이 상태라면 실제 위험은 "CN 불일치"가 아니라 "TLS 신원 검증 미수행"입니다. 스캔 결과만 봐서는 안 드러나니, 45411이 올라온 김에 해당 서버로 들어오는 커넥션 소스를 한 번 훑어보시길 권합니다. 소명 근거도 되고 별도 개선 과제도 됩니다.

조치 방향은 두 가지입니다.

• ① 접속 경로를 FQDN으로 전환 (권장) — 애플리케이션 설정만 바꾸면 됨
• ② 대상 IP를 iPAddress SAN에 포함한 인증서 발급 — 공인 IP라면 공인 CA도 IP 인증서 발급이 가능하지만 취급하는 CA가 제한적이고, 사설 IP는 Reserved IP Address로 분류되어 공인 CA 발급이 불가하므로 사내 CA를 써야 합니다

---

🚫 이런 조치는 하지 마세요

여기가 이 글에서 가장 중요한 부분입니다.

① 스캔 타겟을 IP에서 FQDN으로 바꾸기

"타겟을 FQDN으로 넣으면 결함이 사라진다"는 말이 있는데, PCI ASV 스캔에서는 절대 하면 안 되는 조치입니다.

ASV Program Guide는 스캔 범위를 외부 노출 IP 주소 전체를 기준으로 정의하고, 여기에 더해 FQDN과 기타 진입 경로를 추가로 제출하도록 요구합니다. IP를 빼고 FQDN 목록만으로 돌리면 DNS 레코드가 없는 호스트나 등록 누락된 서비스가 스캔에서 빠져도 이를 검출할 방법이 없습니다.

그리고 범위 정의 책임은 ASV가 아니라 고객사에 있습니다. 스캔 범위에 포함되지 않은 외부 노출 IP에서 침해가 발생하면 그 책임은 고객사가 집니다. 결함 하나 없애자고 범위 완전성을 흔들면, 결함이 문제가 아니라 attestation 자체가 무효가 될 수 있습니다.

⚠️ 심사원이 "IP 기준으로 제출하라"고 하는 건 이 때문입니다. 다만 FQDN도 함께 제출 대상이라는 점은 짚어두세요. 둘 중 하나를 고르는 게 아니라 둘 다 내는 겁니다.

② PCI 템플릿에서 스캔 옵션 조정하기

일반 Basic Network Scan에는 결과에 호스트를 DNS 이름으로 표기하는 옵션(Report → Output)이 있습니다. 하지만 PCI Quarterly External Scan 템플릿에서는 쓸 수 없습니다.

Tenable은 이 템플릿에서 취약점 체크 비활성화, 심각도 임의 조정, 스캔 파라미터 변경 등을 사용자가 하지 못하도록 막아두었습니다. ASV Program Guide 준수를 위한 의도적인 잠금이라 우회 방법도 없고, 우회를 시도해서도 안 됩니다.

③ 서버마다 CN을 개별로 맞춰 발급하기

Solution 문구를 곧이곧대로 읽으면 "장비마다 그 장비 이름으로 인증서를 발급하라"로 들립니다. 실제로 그렇게 하면 결함은 사라지겠지만,

• 인증서 개수가 서버 수만큼 늘어남
• 갱신 주기 관리 부담 증가 (공인 인증서 유효기간은 계속 짧아지는 추세)
• 자산 목록과 인증서 목록이 따로 놀기 시작

와일드카드 인증서로 통합 관리하는 편이 운영상 훨씬 안전합니다. 결함을 없애려고 관리 체계를 나쁘게 바꾸는 건 본말전도입니다.

---

📋 검증 방법

소명이든 조치든, 먼저 실제 상태를 확인해야 합니다.

1. 인증서 SAN 전체 확인

openssl s_client -connect <대상IP>:443 -servername <FQDN> </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

2. IP 직접 접속 시 어떤 인증서가 나오는지 확인

openssl s_client -connect <대상IP>:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

-servername을 뺐다는 점이 중요합니다. SNI 없이 접속했을 때 나오는 기본(default) 인증서를 확인하는 겁니다. 한 IP에 여러 vhost가 물려 있으면 여기서 전혀 엉뚱한 인증서가 나올 수 있고, 그러면 심사자가 추가 질문을 합니다.

3. FQDN 기준으로 검증이 통과하는지 확인 (소명 증적)

curl -vI https://<FQDN>/ 2>&1 | grep -i -E "subject|SSL certificate verify"

출력에 SSL certificate verify ok가 나오면 소명 근거로 충분합니다.

---

체크리스트

확인 항목
SAN에 실제 서비스 FQDN이 모두 포함되어 있는가	☐
apex 도메인으로도 서비스한다면 SAN에 별도 등재되어 있는가	☐
SNI 없이 접속했을 때 나오는 기본 인증서가 우리 것인가	☐
FQDN 접속 시 verify ok가 나오는가	☐
IP를 하드코딩해 접속하는 내부 연동이 있는가	☐
있다면 그쪽에서 인증서 검증을 끄고 있지는 않은가	☐
인증서 만료일이 다음 분기 스캔 이후인가	☐

---

💬 자주 나오는 질문

Q. 브라우저에서 경고가 안 뜨는데 왜 결함인가요?

브라우저는 사용자가 입력한 도메인으로 접속하고, 스캐너는 IP로 접속하기 때문입니다. 같은 서버, 같은 인증서라도 비교 대상이 다르니 결과가 갈립니다. 브라우저에서 정상이라는 건 "FQDN 기준으로는 문제없다"는 뜻이지, 결함 자체가 오탐이라는 근거는 아닙니다.

Q. 그냥 내부적으로 위험 수용 처리하면 안 되나요?

PCI ASV 스캔에서는 안 됩니다. ASV 통과 기준은 DoS를 제외한 Critical/High/Medium 또는 CVSS 4.0 이상 항목이 모두 해소되는 것입니다. 45411은 Medium(CVSS 5.0/5.3)이라 그대로 두면 Fail로 잡힙니다.

반드시 ASV 워크벤치에서 Dispute를 제기해 승인을 받아야 하고, 사내 예외 처리 문서로는 대체되지 않습니다.

내부 정기 스캔(Nessus·TIOVM 등)에서 나온 거라면 사내 절차에 따른 위험 수용으로 처리 가능합니다.

Q. Dispute 사유는 False Positive와 Exception 중 어느 쪽인가요?

Exception 쪽이 맞습니다.

사유	적합 여부	설명
False Positive	❌	플러그인 판정 자체가 틀렸을 때 사용. 스캐너가 IP로 접속한 이상 불일치는 사실이므로 FP 주장은 반려되기 쉽습니다
Exception	✅	해당 결함이 CDE에 위험을 주지 않는다는 증거로 뒷받침되는 경우. "실제 접속 경로는 FQDN이고 그 기준으로는 검증 통과"가 정확히 이 논리입니다
Compensating Control	△	기술적·업무적 제약으로 요구사항을 못 지킬 때. 이 건에는 잘 안 맞습니다

Q. Dispute 증적은 어떻게 준비하나요?

Tenable은 증적에 언제·어디서·어떻게 수집했는지에 대한 설명이 함께 있어야 한다고 명시하고 있습니다. 화면 캡처, 설정 파일 등을 첨부할 수 있습니다.

준비할 것:

• 인증서 SAN 전체 목록 (위 명령 1번 출력)
• 해당 IP에 매핑되는 FQDN과, 그 FQDN 접속 시 verify ok 출력 (명령 3번)
• 실제 서비스 접속 경로가 FQDN임을 보여주는 자료 (공개 URL, LB/WAF 설정, vhost 설정 중 하나)
• 각 증적의 수집 일시·수집 위치·수집 방법 명기

Q. 매 분기 똑같이 올라올 텐데 매번 이걸 해야 하나요?

네, 구조적으로 그렇습니다. 와일드카드 인증서 + IP 기반 스캔 조합에서는 피할 방법이 없습니다.

다만 Tenable 워크벤치에서 생성한 Dispute는 편집·복제가 가능합니다. 첫 분기에 증적 패키지를 제대로 만들어두고, 이후 분기는 복제 후 증적 캡처 날짜만 갱신하는 식으로 운영하면 부담이 크게 줄어듭니다.

Q. 제출 일정은 어떻게 잡아야 하나요?

Tenable은 제출 기한 30일 전 제출을 권고합니다. Dispute는 심사자와 추가 자료 요청이 오갈 수 있어서 여유를 두는 게 좋습니다. 스캔 자체는 횟수 제한 없이 돌릴 수 있으니, 미리 돌려서 어떤 항목이 올라오는지 확인해두세요.

---

📮 Dispute 제출 문안 예시

Dispute Reason: Exception

The reported hostname mismatch results from the scanner connecting to
the host by IP address. In accordance with the CA/Browser Forum Baseline
Requirements, an IP address can only be asserted in the iPAddress form
of the subjectAltName extension; a dNSName entry such as *.example.co.kr
cannot, by design, match an IP address. The mismatch is therefore an
artifact of IP-based scanning rather than a misissued certificate.

All production traffic to this host is served over the fully qualified
domain name. When accessed by FQDN, the certificate passes standard
hostname verification, as shown in the attached evidence.

We have also reviewed system-to-system integrations terminating on this
host and confirmed that none of them connect by IP address.

Attached evidence:
  1. Full subjectAltName listing of the presented certificate
     (openssl x509 -ext subjectAltName), captured on <YYYY-MM-DD> from
     <수집 위치>.
  2. Hostname verification result via FQDN
     (curl -vI, "SSL certificate verify ok"), captured on <YYYY-MM-DD>
     from <수집 위치>.
  3. Service configuration showing the FQDN-based virtual host binding.

The scan scope submitted for this quarter includes all external-facing
IP addresses as required, and we have not modified it. We request that
this finding be accepted as an exception.

IP 하드코딩 연동이 실제로 있어서 조치를 완료한 경우라면 세 번째 문단을 이렇게 바꿉니다.

We identified one internal integration that connected to this host by IP
address with certificate verification disabled. This has been remediated:
the integration now connects by FQDN with full certificate verification
enabled. Evidence of the configuration change is attached.

---

🎉 정리

1. Output 첫 줄부터 확인한다. The identity known by Nessus is가 IP면 스캐너 관점의 불일치일 가능성이 높다.
2. 와일드카드는 IP를 커버하지 못한다. 규격상 불가능하며, apex 도메인과 2단계 서브도메인도 커버하지 않는다.
3. 진짜 위험은 IP 하드코딩 연동이다. 그쪽은 대개 인증서 검증을 꺼놓고 있으니 이번 기회에 점검한다.
4. 스캔 타겟을 FQDN으로 바꾸지 않는다. ASV 범위 완전성이 깨지고, 그 책임은 고객사가 진다.
5. 서버별 CN 개별 발급도 하지 않는다. 와일드카드 통합 관리가 운영상 더 안전하다.
6. ASV에서는 Dispute(Exception)로 처리한다. Medium이라 방치하면 Fail이고, 사내 위험 수용으로는 대체되지 않는다.
7. Dispute는 복제해서 재사용한다. 첫 분기에 증적 패키지를 제대로 만들어두면 이후가 편하다.

인증서를 고쳐야 하는 항목처럼 보이지만, 대부분은 고칠 게 없다는 것을 증명하는 항목입니다. 대신 그 과정에서 IP 하드코딩 연동 같은 진짜 구멍이 하나씩 나오니, 형식적으로 넘기지 말고 한 번은 제대로 훑어보시길 권합니다.

---

🔗 참고 자료

• Tenable Plugin 45411 — SSL Certificate with Wrong Hostname — 플러그인 상세, CVSS 점수
• CA/Browser Forum — Guidance on IP Addresses in Certificates — IP는 iPAddress SAN에만 담아야 하는 이유
• CA/Browser Forum — Baseline Requirements — Reserved IP Address 정의 및 발급 제한
• Tenable PCI ASV — Dispute Reasons — False Positive / Exception / Compensating Control 구분
• Tenable PCI ASV — Disputes — Dispute 생성·편집·복제
• Tenable PCI ASV FAQ — PCI Quarterly External Scan 템플릿 설정 잠금
• Understanding PCI DSS Scanning Requirements — Tenable Blog — ASV 워크벤치 운영과 제출 일정