도메인·DNS·인증서 잡학사전
- .io 도메인의 정체, 알아두면 은근하고 대단하게 쓸모 없는 이야기들을 정리해봤습니다.
들어가며: 도메인, 그냥 이름표일까
소프트웨어 엔지니어로 일하다 보면 어느 날 갑자기 도메인을 사고, DNS 레코드를 등록하고, HTTPS 인증서를 서버에 올리는 순간이 온다. 처음엔 대부분 이렇게 생각 하는데요
"대외 서비스니까
.com쓰고, 인증서는 Let's Encrypt 에서 발급받아서 nginx에 넣으면 끝 아닌가?"
맞습니다 그러면 끝납니다. 실용적이고 필요한것만 원한다면 이 글을 읽을 필요는 없습니다.
다만 그 뒤에는 세계지리, 국제정치, 30년 된 이메일 표준, 그리고 HTTPS를 지탱하는 있는 원리가 숨어 있다.
이 글은 그 뒤편을 구경시켜 주는 투어에 가깝다. 앞부분은 어디 가서 아는 척하기 좋은 잡지식, 뒷부분은 실무에서 진짜 중요한 보안 이야기....같은건 없고 단순히 잡학사전 느낌으로 이런저런 TMI 내용들을 모아봤습니다.
1부. 도메인은 사실 '세계지리'다
너무 일상적으로 쓰는 .com 같은 도메인의 마지막 부분이 어떤 의미인지 알아 보기 위해서는 먼저 TLD 에 대해서 알아봐야 합니다
TLD가 뭐길래
도메인의 가장 오른쪽 부분을 TLD(Top-Level Domain, 최상위 도메인)라고 부른다.
google.com→.comgithub.io→.iokakao.co.kr→.kr이 TLD,.co는 2차 도메인
TLD는 크게 두 종류다.
| 구분 | 설명 | 예시 |
|---|---|---|
| gTLD (Generic) | 국가와 무관한 일반 도메인 | .com .net .org .dev .app .xyz |
| ccTLD (Country Code) | 국가 코드 기반 2글자 | .kr .jp .us .uk .de |
여기까지는 교과서. 재밌는 건 지금부터다.
우리가 매일 쓰는 도메인, 사실은 남의 나라 국가 코드
스타트업과 개발자들이 즐겨쓰는 혹은 힙하다고 생각됬던 도메인들, 알고 보면 대부분 어느 작은 나라(또는 영토)의 국가 코드를 빌려 쓰는 것인데요
| TLD | 원래 의미 (진짜 주인) | 우리가 아는 의미 |
|---|---|---|
.tv | 🇹🇻 투발루 | Television |
.io | 🇮🇴 영국령 인도양 지역 | Input / Output |
.ai | 🇦🇮 앵귈라 | Artificial Intelligence |
.me | 🇲🇪 몬테네그로 | Me |
.fm | 🇫🇲 미크로네시아 | FM Radio |
.gg | 🇬🇬 건지섬 | Good Game |
.co | 🇨🇴 콜롬비아 | Company |
.ly | 🇱🇾 리비아 | -ly (bit.ly) |
.sh | 🇸🇭 세인트헬레나 | Shell |
.to | 🇹🇴 통가 | to |
실제 사용 사례를 보면
bit.ly는 리비아 국가 도메인인데, url단축기 서비스로 유명하다.tv스트리밍 도메인은 남태평양 인구 1만 명의 섬나라 투발루인데, 도메인 등록비가 국가 재정수입 조금 기여하고 있는 셈이다. 실제로 투발루는.tv도메인 수입이 정부 재정의 상당 부분을 차지한 적도 있다는 카더라도 있더라
그래서 위 국가들을 세계지도로 표현해보면 아래와 같다
- 참고로 서양인들의 관점을 이해하기 위해 (한국관점의 태평양 중심의 지도가 아닌) 대서양 중심의 지도로 만들었다
.io의 전성시대, 그리고 .ai의 왕좌 등극
한때 .io는 개발자와 스타트업의 상징이었다. Input/Output 같기도 하고, 짧고, 힙했다. 그런데 그 정체는—
- 영국령 인도양 지역(British Indian Ocean Territory, BIOT). 독립국이 아니라 영국의 해외 영토다.
- 차고스 원주민 강제 이주 같은 어두운 역사가 얽혀 있는 곳이기도 하다.
그리고 AI 시대가 오면서 왕좌는 옆 동네 섬으로 넘어갔다. 카리브해의 작은 섬 앵귈라의 .ai가 AI 붐을 타고 폭발적으로 팔리기 시작한 것. 도메인 등록 수입이 앵귈라 정부 재정의 한 축이 됐을 정도다.
💡 쉬어가는 퀴즈
.tv= Television? → ❌ 투발루.io= Input/Output? → ❌ 영국령 인도양 지역.ai= AI용으로 만든 도메인? → ❌ 앵귈라.com= Company? → ❌ Commercial
사라진 나라의 도메인은 어떻게 될까
국가가 사라지면 그 도메인도 사라질까? 꼭 그렇지는 않다.
| TLD | 나라 | 현재 상태 |
|---|---|---|
.su | 소련(Soviet Union) | 1991년 소련 해체, 그런데 아직도 사용 가능 |
.yu | 유고슬라비아 | 폐지 → .rs, .me 등으로 이전 |
.zr | 자이르 | 콩고민주공화국이 되며 .cd로 변경 |
.an | 네덜란드령 안틸레스 | 국가 해체 → .cw, .sx 등으로 분리 |
나라는 없어졌는데 도메인은 살아 있는 .su 같은 사례가, 디지털 세계의 유령처럼 아직 떠돌고 있다.
핵심 원리: ccTLD는 '국가'가 아니라 'ISO 코드'가 만든다
많은 사람이 "ccTLD = 국가 단위 도메인"으로 알고 있다. 절반만 맞는 이야기다. 일상적으로는 그렇게 이해해도 충분하지만, 실제 배정 기준은 국가 여부가 아니다. ISO 3166-1 alpha-2 — 국제표준화기구(ISO)가 관리하는 2글자 국가·지역 코드 목록에 올라 있는지, 이것 하나로 결정된다.
ISO 3166-1 alpha-2 코드가 있는가?
↓
IANA(ICANN)가 해당 코드를 위임
↓
ccTLD 탄생정리하면 이렇다. ISO 코드만 있으면 ccTLD를 받는다. 독립국인지 아닌지는 따지지 않는다. 그래서 국가가 아닌 지역들도 자기 도메인을 갖고 있다.
- 중화권:
.cn(중국 본토) 외에.hk(홍콩),.mo(마카오),.tw(대만) - 미국권:
.us(본토) 외에.pr(푸에르토리코),.gu(괌) - 영국권:
.ky(케이맨 제도),.gi(지브롤터),.bm(버뮤다) - 덴마크권:
.fo(페로 제도),.gl(그린란드)
애증의 .io도 같은 원리다. 영국령 인도양 지역은 독립국이 아니지만, ISO 코드 IO가 있으니까 당당히 최상위 ccTLD를 받았다.
여담: 그 인도양 영토, 요즘 심상치 않다
.io의 주인인 영국령 인도양 지역은 지정학적으로도 만만치 않은 곳이다. 이곳의 디에고가르시아섬에는 영국과 미국이 함께 쓰는 대형 군사기지가 있어, 인도양 한복판이라는 위치 덕분에 오랫동안 전략 요충지 역할을 해 왔다.
그런데 2025년, 영국이 차고스 제도의 주권을 모리셔스에 넘기는 협정에 서명했다(디에고가르시아 기지는 99년간 임차하는 조건). 영토가 사라지면 ISO 코드 IO도 언젠가 목록에서 빠질 수 있다. 그러면 100만 개 넘게 등록된 .io는 .su처럼 유령으로 남을까, 폐지 수순을 밟을까. 전 세계 스타트업 도메인의 운명이 국제 정치 협상 테이블 위에 올라가 있는 셈이다.
반대로, 나라처럼 굴러가는데 도메인이 없는 곳
정부도 있고 군대도 있고 선거도 치르는데, ISO 코드가 없어서 도메인도 없는 사례들이 있다.
- 소말릴란드 — 사실상 독립국처럼 운영되지만(정부·군대·선거 다 있다) 국제 승인이 거의 없어 ISO 코드가 없고, 따라서 ccTLD도 없다.
- 코소보 — 여러 나라가 승인했지만 정식 ISO 코드는 없다.
.xk는 비공식 임시 코드일 뿐이다. - 압하지야 / 남오세티야 / 북키프로스 — 마찬가지로 ccTLD가 없다.
반대 방향의 사례도 흥미롭다.
- 아프가니스탄 — 탈레반은 '정부'이고 아프가니스탄은 '국가'다. 정부가 바뀌어도 국가는 유지되므로
.af는 그대로 살아 있다. 국가 ≠ 정부. - 팔레스타인 — ISO 코드
PS가 있어.ps가 존재한다.
예외 중의 예외: 국가가 아닌데 도메인이 있는 .eu
ISO 3166-1에는 아주 예외적으로 EU 코드가 예약(reserved) 되어 있다.
- ❌ 독립국은 아니다
- ⭕ ISO가 예외적으로 2글자 코드(EU)를 예약해 뒀다
- ⭕ 그 덕에
.eu가 발급됐고, 기술적으로는 ccTLD처럼 운영된다
중간 정리: 국가, 정부, 영토, 그리고 ISO 코드
비슷해 보이는 개념이 계속 등장했으니 여기서 한번 정리하자.
| 개념 | 뜻 | 도메인 관점에서 보면 |
|---|---|---|
| 국가 | 영토·국민·주권을 가진 국제법상 주체 | 정부가 바뀌어도 국가가 유지되면 ccTLD도 유지 (.af) |
| 정부 | 그 국가를 운영하는 조직 | 도메인의 주인은 정부가 아니라 국가 |
| 영토(속령) | 국가에 속하지만 별도로 구분되는 땅 | 국가가 아니어도 ISO 코드가 있으면 ccTLD 획득 (.io .hk .gl) |
| ISO 3166-1 alpha-2 | 국가·속령에 부여되는 2글자 코드 목록 | ccTLD 발급의 실질적 기준 |
1부의 결론: 도메인에도 힘의 논리가 있다
ccTLD의 공식 원칙은 "ISO 코드가 있으면 발급"이라 지극히 평등해 보인다. 그런데 결과를 놓고 보면 그렇지 않다.
- 강대국은 해외 영토가 많아, 본국 도메인 외에
.io같은 영토 도메인을 줄줄이 확보한다. - 약소국은 해외 영토라는 개념 자체가 없으니 도메인도 하나뿐이다.
- 소말릴란드처럼 사실상 나라 구실을 다 해도, 국제사회의 승인이 없으면 코드조차 받지 못한다.
원칙은 평등한데 결과는 평등하지 않다. 도메인 한 줄에도 국제정치의 힘의 논리가 그대로 담겨 있다.
2부. 이제 진짜 일을 해보자 — DNS 등록
도메인을 샀으면 DNS 레코드를 등록해야 서비스가 뜬다. DNS는 도메인 이름을 IP·메일 서버·인증 정보 등 다양한 정보와 연결하는 시스템이다. 종류가 많지만, 인증서 실무에서 실제로 자주 만지는 건 몇 개 안 된다.
기본 중의 기본
- A Record — 도메인 → IPv4 주소 (
example.com → 192.0.2.10). 가장 기본. - AAAA Record — 도메인 → IPv6 주소. A 레코드의 IPv6 버전.
- CNAME — 도메인 → 다른 도메인(별칭).
www.example.com → example.com,cdn.example.com → xxxxx.cloudfront.net.- IP를 직접 못 넣고 다른 도메인만 가리킬 수 있음
- CDN, 로드밸런서에서 애용
인증서 실무에서 특히 중요한 레코드
- TXT Record — 도메인에 문자열을 저장. 인증서 도메인 소유권 검증(DCV) 의 핵심이자, SPF/DKIM/DMARC, Google·MS 서비스 인증에도 쓰인다. CA가 "이 도메인이 정말 당신 것이라면 이 값을 TXT에 넣어보라"고 요구할 때 쓰는 게 바로 이것.
- CAA Record — 어떤 CA가 인증서를 발급할 수 있는지 지정한다.
letsencrypt.org,digicert.com만 허용하는 식. 지정한 CA 외에는 발급을 막아 오발급을 방지하는 보안 장치.
나머지 조연들
- MX — 메일 서버 지정(우선순위 설정 가능). 메일 수신에 필수.
- NS — 이 도메인을 어느 DNS 서버가 관리하는지 지정.
- SOA — DNS Zone의 기본 정보(Primary NS, 관리자 이메일, Serial, TTL 등). Zone마다 하나만 존재.
- PTR — IP → 도메인(A 레코드의 반대). Reverse DNS, 메일 서버 신뢰성 검증에 사용.
- SRV — 특정 서비스의 서버 위치와 포트 지정(AD, SIP/VoIP, XMPP, Kerberos). 일반 웹서비스에선 거의 안 씀.
인증서 발급할 때 실제로 쓰는 레코드 요약
| 우선순위 | 레코드 | 용도 |
|---|---|---|
| 1 | A | 서버 IP 연결 |
| 2 | CNAME | DCV(CNAME 검증), CDN 연결 |
| 3 | TXT | DNS 소유권 검증 — Let's Encrypt·DigiCert가 가장 많이 사용 |
| 4 | CAA | 특정 CA만 발급 허용(보안 강화) |
3부. 인증서를 서버에 올려보자 — 원리와 실무
모든 인증서는 결국 같은 X.509다
먼저 오해 하나를 풀자. "nginx 인증서", "Tomcat 인증서", "IIS 인증서"가 따로 있는 게 아니다.
인증서는 전부 X.509 규격으로 동일하다. 다르게 보이는 이유는 웹서버·WAS·개인키 저장 방식·파일 형식이 다를 뿐이다.
신뢰의 사슬: 인증서 체인
브라우저가 당신의 사이트를 믿는 이유는 신뢰의 사슬이 이어져 있기 때문이다.
서버 인증서 (Leaf)
↓
Intermediate CA (중간 인증서)
↓
Root CA (최상위 — OS/브라우저에 미리 내장됨)Root CA는 이미 우리 컴퓨터·브라우저에 심어져 있다. 이 사슬이 Root까지 깔끔하게 이어지면 자물쇠가 뜨고, 중간이 끊기면 "신뢰할 수 없는 인증서" 경고가 뜬다. (이 'Root CA를 직접 심을 수 있다'는 점이 뒤에서 아주 무서운 이야기로 돌아온다.)
개인키는 절대 밖으로 나가지 않는다
인증서를 발급받는 흐름의 핵심 원칙:
- CSR(Certificate Signing Request) 을 만들어 CA에 보낸다. 여기엔 공개키, CN, SAN, 조직 정보가 들어간다.
- 개인키(Private Key)는 CSR에 포함되지 않는다. CA에는 공개키만 간다.
- 개인키는 서버 밖으로 절대 내보내지 않는다. (유출되면 인증서가 통째로 무력화된다.)
CN은 죽었다, 이제는 SAN
- 예전엔 CN(Common Name) 으로 도메인을 확인했다.
- 지금 브라우저는 SAN(Subject Alternative Name) 을 기준으로 확인한다. CN만 있고 SAN이 없으면 최신 브라우저에서 경고가 뜬다.
- SAN 덕분에 인증서 하나에 여러 도메인을 담을 수 있다:
example.com,www.example.com,api.example.com…
와일드카드 인증서, 생각보다 규칙이 빡빡하다
*.example.com 하나로 서브도메인을 다 덮는 게 와일드카드 인증서다.
가능 ✅ api.example.com, www.example.com불가능 ❌ example.com(루트 자신), a.b.example.com(2단계)
여기서 실무자들이 자주 헷갈리는 두 가지 규칙:
규칙 1 — 와일드카드는 딱 1단계(1 depth)만 대체한다. 가장 왼쪽 Label 하나만 대체 가능. CA/B Forum 규격 자체가 이렇게 정해놨다.
❌ *.*.example.com (규격 외, 절대 불가)
❌ *.*.*.example.com (규격 외)
✅ *.api.example.com
✅ *.my.salesforce.com규칙 2 — 와일드카드는 왼쪽에만 온다(오른쪽 불가).
❌ api.*.example.com
❌ *.example.*
❌ example.*.com와일드카드는 가장 왼쪽 Label에만 올 수 있다. RFC와 CA/B Forum의 규칙이다.
실전 시나리오: "2단계 와일드카드 쓰는 사이트도 봤는데요?"
*.*.example.com은 규격상 불가능하다고 했는데, 어떤 글로벌 서비스는 2단계 서브도메인에서도 와일드카드가 멀쩡히 동작한다. 어떻게 된 걸까?
정답은 "사용자 눈에만 그렇게 보일 뿐, 실제로 2단계 와일드카드가 동작하는 게 아니다"이다. 비밀은 여러 장의 와일드카드 인증서를 층층이 겹쳐 쓰는 것이다.
글로벌 회사 예시
글로벌 로봇 기업 하나를 예로 들어보자. 이름은 로닌봇, 도메인은 cccp.com이다. 전 세계 서비스를 지역별·기능별(웹/API)로 나누고 싶다면 이렇게 설계할 수 있다.
cccp.com : 기업 사이트
*.cccp.com : 글로벌 서버(정책·업데이트)
├ api.cccp.com
└ web.cccp.com
*.api.cccp.com : 지역별 API 서버
├ kr.api.cccp.com
├ jp.api.cccp.com
└ us.api.cccp.com
*.web.cccp.com
└ kr.web.cccp.com : 한국 웹사이트
*.rt.cccp.com : 실시간 서버대단한 기술이 있는 게 아니다. 규칙을 만족하는 와일드카드 인증서를 단계마다 각각 발급받아 조합했을 뿐이다. cccp.com, *.cccp.com, *.api.cccp.com, *.web.cccp.com… 층마다 한 장씩 쌓아 올리면 모든 케이스가 커버된다.
다만 인증서를 무조건 많이 사면 된다는 얘기는 아니다. 설계를 어떻게 하느냐에 따라 아무리 사도 계속 모자랄 수도 있고, 한두 장으로 충분할 수도 있다.
- 와일드카드를 어떻게 설계하고 쌓을지는 순전히 설계자의 몫이다.
- 도메인은 한 번 배포하고 나면 바꾸기가 정말 어렵다. 통제할 수 없는 곳에 이미 공유된 문서들, 옛날 링크로 들어오는 사용자들, 밀려드는 리다이렉트 요청…
- 그러니 처음 설계할 때 정책을 잘 잡아두자. 처음부터 완벽할 수는 없지만, 알고 시작하는 것과 모르고 시작하는 것의 차이는 크다.
인증서 파일 형식, 왜 이렇게 많아?
.pem .crt .cer .der .p12 .pfx .jks .key… 종류가 많아 보이지만, 딱 두 축으로 정리된다: ① Base64냐 Binary냐, ② 개인키를 포함하냐.
| 형식 | 정체 | 특징 |
|---|---|---|
| PEM | Privacy Enhanced Mail | Base64(사람이 읽음), -----BEGIN CERTIFICATE-----. Linux/nginx/Apache/Go/Node.js |
| CRT / CER | Certificate | 인증서 파일. 내용은 PEM 또는 DER. 확장자만 다른 경우도 많음 (CER은 Windows에서 흔함) |
| DER | Distinguished Encoding Rules | Binary(사람이 못 읽음). Windows에서 자주 |
| KEY | Private Key | 개인키. 절대 유출 금지 |
| PFX / P12 | PKCS#12 | 인증서 + 개인키 묶음, 암호 보호 가능. IIS/Windows/Java/Tomcat |
| JKS | Java KeyStore | Java 전용. Tomcat, Spring Boot |
| P7B | PKCS#7 | 인증서 체인만(개인키 없음). Windows |
여담으로 PEM의 P는 "Privacy Enhanced Mail" — 원래는 이메일 암호화 포맷이었다. 이메일용으로 만든 게 지금은 웹 인증서의 사실상 표준이 됐다. (30년 된 표준의 생명력이란.)
그래서 내 서버는 어떤 형식을 쓰나
| 서버/환경 | 주로 쓰는 형식 | 설정 키 |
|---|---|---|
| Nginx | PEM/CRT + KEY | ssl_certificate, ssl_certificate_key |
| Apache | CRT/PEM + KEY | SSLCertificateFile, SSLCertificateKeyFile |
| Tomcat | PKCS#12(.p12), JKS | Java KeyStore |
| Spring Boot | PKCS#12(.p12), JKS | application.yml의 server.ssl.* |
| IIS (Windows) | PFX | Windows Certificate Store |
| Go | PEM + KEY | tls.LoadX509KeyPair() |
| Node.js | PEM + KEY | https.createServer() |
핵심은 다시 한 번: 인증서 종류가 다른 게 아니라, 각 서버가 요구하는 파일 형식이 다를 뿐이다.
인증서 '상품'의 등급: DV / OV / EV
같은 X.509라도, CA가 얼마나 깐깐하게 검증하고 발급하느냐로 등급이 갈린다.
| 등급 | 검증 범위 | 용도 |
|---|---|---|
| DV (Domain Validation) | 도메인 소유권만 | 개인/블로그. 빠르고 저렴, 자동 발급. Let's Encrypt 대표 |
| OV (Organization Validation) | 도메인 + 기업 실존/사업자 정보 | 회사 서비스 |
| EV (Extended Validation) | 기업 실체·법인·신청자까지 엄격히 | 금융/공공기관 |
EV는 과거 브라우저 주소창에 회사명이 초록색으로 표시되던 그것. 지금은 대부분의 브라우저가 이 표시를 없앴다.
그 외 특수 목적 인증서도 있다.
- Wildcard SSL —
*.example.com하위 도메인 전체 - Multi-Domain(SAN) — 인증서 하나로
example.com,example.net,example.org등 여러 도메인 관리 - Code Signing —
.exe.dll.msi.jar서명. 개발자 신원 확인 + 코드 위변조 방지 (SSL과 용도가 다름) - Client Certificate — 사용자 인증용. VPN, 사내 시스템, mTLS(서버뿐 아니라 클라이언트도 인증서 제시)
무료 인증서와 짧아지는 유효기간
- Let's Encrypt — ACME 프로토콜로 자동 발급·자동 갱신, 유효기간 90일.
- 인증서 유효기간은 계속 짧아져 왔다: 5년 → 3년 → 2년 → 398일 → 200일(2026년 3월부터). CA/Browser Forum 결의로 2027년 100일, 2029년 47일까지 줄어드는 일정도 이미 확정돼 있다.
- 이유: 키 유출 시 위험에 노출되는 기간 축소, 그리고 자동 갱신의 표준화.
- 그래서 "수동으로 1년에 한 번 갱신" 시대는 끝났다. 자동화(ACME)가 답이다.
4부. HTTPS가 진짜 지켜주는 것과, 절대 안 지켜주는 것
자물쇠 아이콘을 "안전한 사이트"라고 오해하는 사람이 정말 많다. 정확히는 이렇다.
🔒 자물쇠 = "안전한 사이트" (X) 🔒 자물쇠 = "TLS로 암호화된 통신 + 신뢰 가능한 인증서" (O)
HTTPS가 보장하는 것:
- 암호화 — 중간에서 훔쳐봐도 내용을 못 읽음
- 무결성 — 중간에서 내용을 변조하면 들킴
- 서버 인증 — 접속한 서버가 진짜 그 도메인의 서버가 맞음
HTTPS가 보장하지 않는 것:
- XSS, SQL Injection 같은 웹 취약점
- 서버 자체의 안전성
- 그 사이트가 악성 사이트인지 아닌지 — 피싱 사이트도 자물쇠는 멀쩡히 뜬다
즉, 자물쇠는 "너와 이 서버 사이의 대화가 도청·변조되지 않는다"는 뜻이지, "이 사이트가 착한 사이트"라는 보증이 아니다.
참고로 포트는 IANA Well-known Port로 정해져 있다: HTTP는 80, HTTPS는 443.
5부. [경고] 루트 인증서, 절대 함부로 추가하지 마라
여기가 이 글이 "묵직하게 끝나는" 지점이다. 앞에서 "Root CA는 브라우저에 미리 내장돼 있다"고 했다. 그런데 여기에 사용자가 직접 인증서를 추가할 수도 있다. 이 기능이 축복이자 재앙이다.
먼저, 흔한 실무 상황: "npm install이 안 돼요!"
사내망에서 개발하다 보면 npm install, pip install, git clone이 갑자기 인증서 에러를 뱉는 경우가 있다. 범인은 보통 사내 보안 장비(프록시) 다.
- 사내망에서 외부로 나가는 트래픽은 프록시·보안 장비를 거친다.
- 이 장비는 HTTPS 트래픽을 일단 복호화해서 검사한 뒤, 자기 사설 인증서로 다시 암호화해서 우리에게 준다.
- 그래서 개발 툴이 "이건 내가 아는 CA가 서명한 인증서가 아닌데?" 하며 거부하는 것이다.
- 해결책: 회사가 배포한 사내 루트 인증서를 각 툴에 등록해준다(
npm config set cafile,pip의--cert,git config http.sslCAInfo등).
잠깐, 방금 그거 중간자 공격 아닌가?
맞다. 이것이 바로 MITM(Man-in-the-Middle, 중간자 공격) 과 동일한 원리다. 사내 보안 장비는 회사가 공식적으로 운영하는 '허가받은 중간자'로서 임직원의 암호화 트래픽을 중간에서 열어 본다. 회사 자산 보호라는 목적과 정해진 절차가 있으니 합법일 뿐, 기술적인 원리 자체는 감청과 같다.
그리고 이 일을 가능하게 만드는 열쇠가 바로 루트 인증서다.
루트 인증서의 막강한 권한
루트 인증서(Root CA)를 시스템에 추가한다는 건, 이런 뜻이다.
"이 인증서로 서명된 건 브라우저야, 무조건 믿어."
즉, 루트 인증서를 심는 순간 그 CA는 어떤 도메인의 인증서든 마음대로 위조할 수 있게 된다. 당신의은행.com이든 google.com이든, 그 루트로 서명하면 당신의 브라우저는 자물쇠를 띄우고 아무 의심 없이 믿는다.
"이 인증서 하나만 설치하면 돼요"의 결말
그래서 누군가 이렇게 접근한다면 극도로 경계해야 한다.
"이 앱 깔면 무료 와이파이 써요", "이 인증서 하나만 설치하면 사은품 드려요"
그 루트 인증서를 설치하는 순간, 상대는 당신의 모든 HTTPS 트래픽을 자물쇠가 멀쩡히 떠 있는 상태로 들여다볼 수 있다.
- 오늘 무엇을 검색했는지
- 누구와 어떤 메시지를 주고받았는지
- 어느 사이트에 어떤 계정으로 로그인했는지
HTTPS가 안전한 것은 신뢰의 사슬이 튼튼하기 때문인데, 루트 인증서를 함부로 추가하는 것은 그 사슬의 맨 꼭대기에 공격자를 앉히는 일이다. 자물쇠는 그대로 떠 있으니 눈치채기도 어렵다. 사실상 HTTPS의 종말이다.
마치며: 기본기가 곧 최고의 보안이다
가볍게 시작해서 여기까지 왔다. 정리하면 이렇다.
- 도메인 뒤에는 세계지리와 국제정치가 있다.
.io가 인도양이고.ai가 앵귈라라는 걸 알고 나면, 도메인 고르는 일이 조금 다르게 보인다. - DNS와 인증서는 암기가 아니라 원리다. A·CNAME·TXT·CAA만 알아도 인증서 실무의 8할은 된다. 인증서는 전부 같은 X.509이고, 서버마다 요구하는 파일 형식이 다를 뿐이다.
- 개인키는 서버 밖으로 내보내지 말고, 루트 인증서는 함부로 심지 마라. 인증서 관리의 처음이자 끝이다.
다음추천글
- X.509 프로토콜 알아보기
- 내 컴퓨터에서 발생하는 HTTPS 트래픽 감청해보기 (Go Lang, Python)
- 인증서관리시스템 예시로 만들어놓은 사이트