Self-signed 문제

 

 

 

Self-Signed Certificate(Self-signed certificate)의 핵심 문제는:

"누가 이 공개키가 진짜인지 보증하지 않는다"

 

는 거야.

즉:

"내가 나를 믿는다"

 

구조라서 브라우저가 신뢰할 근거가 없다.

---

먼저 정상 HTTPS 구조

정상 인증서는:

CA가 전자서명

 

한다.

즉:

"이 공개키는 진짜 naver.com 것 맞음"

 

이라고 보증.

---

브라우저는 왜 믿나?

브라우저 안에는:

신뢰된 Root CA 공개키

 

들이 이미 들어있다.

그래서:

CA 전자서명 검증 성공

 

→ 신뢰.

---

그런데 Self-Signed는?

자기 자신의 개인키로 자기 인증서에 서명한다.

즉:

"이 공개키는 진짜입니다"
↓
누가 보증?
↓
본인

 

---

브라우저 입장

"그걸 왜 믿지?"

 

가 된다.

---

그래서 경고 뜸

브라우저에서:

이 연결은 안전하지 않음
NET::ERR_CERT_AUTHORITY_INVALID

 

같은 거 뜨는 이유.

---

핵심 문제 — MITM 공격 가능

여기가 진짜 중요.

---

상황

공격자가 중간에서:

가짜 서버
+
Self-Signed 인증서

 

보내도 기술적으로는 가능하다.

---

브라우저가 왜 막냐?

신뢰된 CA 서명 없음

 

이기 때문.

---

만약 사용자가 "무시하고 진행"

누르면?

MITM 공격 가능

 

해진다.

---

실제 공격 흐름

1

사용자:

https://bank.com

 

접속.

---

2

중간 공격자가:

가짜 공개키
+
Self-Signed 인증서

 

전달.

---

3

사용자가 경고 무시.

---

4

이후:

공격자와 HTTPS 연결

 

이 성립.

---

결과

공격자는:

• 비밀번호
• 쿠키
• 세션

전부 볼 수 있다.

---

즉 HTTPS 핵심은

암호화 자체보다
"진짜 서버인지 검증"

 

이 엄청 중요.

---

Self-Signed 자체가 나쁜 건 아님

중요 포인트.

---

사용되는 곳

1. 개발환경

예:

localhost
dev 서버

 

---

2. 사내망

회사 내부 시스템.

---

3. 테스트 장비

• NAS
• 공유기
• 프린터
• Kubernetes 내부

---

왜 가능?

조직 내부에서:

직접 인증서 배포 가능

 

하기 때문.

---

예시

회사 PC들에:

사내 Root CA 등록

 

하면 Self-Signed 계열도 신뢰 가능.

---

기업 내부에서는 자주 씀

예:

• 사내 VPN
• 내부 API
• Kubernetes Ingress
• Dev 환경

---

Kubernetes에서도 흔함

예:

• cert-manager
• internal CA

사용.

---

그럼 왜 공인 인증서 쓰나?

인터넷 서비스는:

불특정 다수 사용자

 

가 접속한다.

---

따라서

브라우저 기본 신뢰 체계

 

를 따라야 한다.

즉:

• Let's Encrypt
• DigiCert

같은 공인 CA 필요.

---

실무 핵심

1. 운영환경에서는 Self-Signed 지양

특히 외부 서비스.

---

2. 내부망은 가능

단:

사내 Root CA 배포 필요

 

---

3. 경고 무시는 위험

실제 피싱/MITM 공격에서 자주 사용.

---

쉽게 비유하면

공인 인증서:

정부 발급 신분증

 

---

Self-Signed:

자기 손으로 만든 학생증

 

느낌.

---

핵심 한 줄

Self-Signed의 문제는:

공개키의 진위를 보증하는
신뢰된 제3자(CA)가 없어서,
가짜 서버인지 진짜 서버인지 구분할 수 없다는 것

 

이다.