[ACM] SSL인증서 개념 및 CA인증기관

SSL 인증서

클라이언트와 서버간의 통신을 보증해주는 제3자 문서

 

1) 왜 필요한가? 필요성 (HTTP 한계)

HTTP(80) : 클라이언트와 서버사이의 메시지 교환 규칙 (Request & Response)
‘암호’화 되지 않은 상태로 메시지가 유출되서 잘못된 메시지를 전송할 수 있음
상대방을 확인하는 ‘인증’하는 수단이 없어서 잘못된 상대에게 메시지를 보낼 수 있음

 

2) 목적 : 클라이언트의 안전한 통신

HTTPS(443) : SSL이나 TLS 같은 프로토콜을 사용하는 HTTP (암호+인증+HTTP)
SSL역할: 클라이언트와 서버사이의 통신을 암호화
즉, SSL인증서를 통해 메시지를 ‘암호화’ 하고, 내가 통신하고자 하는 상대가 맞는지 ‘인증’

 

3) SSL인증서 암호화방식

-공개 방식

암호화하는 키와 복호화 하는 키가 다름  
public key(공개키) : 자신(서버)가 타인(클라이언트)에게 제공하는 키로, 전달할 메시지 암호화
private key(개인키) : 자신(서버)가 가지고 있는 키로, 전달받은 메시지 복호화
예를 들어, A->B 비대칭키 암호화방식 통신
A : B의 Public Key로 암호화해서 B에게 전달
B : 자신의 Private Key로 복호화해서 A의 메시지 읽음
즉, 공개키가 노출된다고 해도 개인키가 없으면 암호해제 불가

 

-대칭키 방식

암호화하는 키와 복호화 하는 키가 같음
예를 들어, A->B 대칭키 암호화방식 통신
A : 공통key로 암호화해서 B에게 전달
B : 공통Key로 복호화해서 받은 메시지 복호화
즉, 암호화 했던 Key가 노출되면 암호해제

HTTPS는 공개키 방식과 대칭키 방식을 혼용해서 사용(?>)
공개키 방식은 클라이언트와 서버가 서로 인증하려고 교환하기 위한 key를 암호화하는 목적,
대칭키 방식은 서로를 인증한 후 메시지를 암호화해서 지속적으로 전송하는 목적

 

4) CA 인증기관

공개키 방식의 한계 : Public Key가 진짜인지 확인할 수 없음
따라서, Public Key를 증명해주는 제 3자(CA 인증기관)필요
클라이언트 서버 둘 다 신뢰하는 기관으로 Public Key가 진짜라고 서명한 공개키 인증서발급

CA가 Public key를 인증한 인증서를 일반적으로 SSL인증서라고 부름

 

5) 공개키(SSL) 인증서

CA가 인증한 Public key 가지고 발급한 인증서
서버 -> CA : 서버의 Public Key 제출
CA -> 서버 : Public key를 인증하고, 공개키 인증서를 발급해서 전달
서버 -> 클라이언트 : 공개키 인증서 전달해서 공개키 암호화 방신으로 통신

 

브라우저가 인증기관의 공개키를 가지고 있음

인터넷 설정 옵션에서 인증기관들 확인가능, 그래서 브라우저마다 다를 수도 있음

<브라우저에서 인증서 정보 직접 확인>

발급대상/발급자/유효기간 : 현재 발급대상의 발급자와 유효기간
인증경로 및 인증상태 : 현재 발급대상부터 가장 신뢰할 수 있는 루트CA까지 tree경로

A(root)->B->C->발급대상 트리구조일 경우
현재 발급자는C, C의 인증서에서 발급자는B, B의 발급자는A,
마지막으로 루트CA인 A에서 발급자는 자기자신

 

* 인증서 체인 : 이러한 인증경로들을 모두 포함한 내용

발급대상인 자기자신 뺴고, 루트 CA까지 그 인증서 경로들이 가지고 인증서값들을 모아둔 것 

 

참고

ACM 운영이슈

https://kim-dragon.tistory.com/6