[TLS] 2. TLS의 인증서

TLS의 인증서

TLS(1) 포스팅의 다음 포스팅으로 인증서를 다룹니다.

 

TLS는 3가지 주요 이점

 

TLS는 다음 이점을 제공합니다.

 

• 암호화: TLS(1)에 작성한 암호화 기법들로 서버 사이에 오가는 데이터들을 "스니핑"으로부터 보호합니다. 암호화로 실제 데이터를 숨길 수 있습니다.
• 무결성: 데이터가 위, 변조 되지 않도록 보호합니다. 대칭키를 RSA방식으로 안전하게 공유 후 암호화된 통신으로 중간에 데이터를 임의로 수정할 수 없도록 합니다.
• 인증: 데이터를 주고받는 서버가 신뢰할 수 있는 서버인지. 클라이언트가 신뢰할 수 있는 서버와 통신하는 것인지 확인하는 작업이 필요합니다. 이 과정에서 "인증서"가 사용됩니다.

여기서 인증서가 등장합니다.

 

 

인증서

 

인증서는 서버가 신뢰할 수 있는 서버인지 확인할 때 필요한 것입니다.

인증 기관이 도메인을 소유한 사람, 비즈니스에 TLS 인증서를 발행하게 됩니다.

 

인증서는 서버의 공개키, 도메인 소유자가 누구인지에 대한 정보 등을 포함하며 서버의 신원을 확인하는데 사용됩니다.

일종의 서버의 디지털 여권입니다.

 

인증서의 주요 구성요소는 아래와 같습니다.

 

1. 서버측 공개키(PublicKey): 서버의 공개키, 암호화 방법

2. 발급자(Issuer): 인증서를 발급한 CA(Certificate Authority)의 신원

3. 주체(Subject): 인증서를 소유한 소유자(보통 서비스의 도메인)

4. 유효기간(Validity Period): 인증서의 유효기간.

5. 지문, 디지털 성명(Digital-signing)

 

 

CA(Certificate Authority)

CA는 디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 기관입니다.

엄격하게 공인된 기업만이 할 수 있습니다. 

 

⭐️CA는 자체적으로 공개키와 비밀키를 가지고 있습니다⭐️

 

CA의 비밀키는 절대 누설되어선 안됩니다. 이 비밀키가 누설되어 파산한 CA도 있다고 합니다.

 

CA의 종류

• Root CA: 최상위 CA로 자체 서명(Self-Signed)된 인증서를 가집니다.
• Intermediate CA: Root CA로 부터 인증을 받아 다른 엔터티(회사)나 하위 CA에게 인증서를 발급합니다.

 

티스토리또한 인증서를 갖고있습니다.

 

chrome의 https통신표시

tistory의 인증서

tistory의 인증서 계층

tistory의 인증서 서명

 

아래 설명으로 인증서 계층과 지문, 인증서의 정보들을 이해할 수 있게됩니다.

 

 

 

CA가 인증서를 발급하는 과정

1) CA에 인증서 발급 요청

    인증서를 요청하는 회사 A는 자신의 도메인과 공개키를 포함하여 CA에 인증서를 요청합니다.

 

2) CA는 회사 A의 정보와 도메인 소유권을 검증합니다.

 

3) CA는 A회사의 공개키를 해시(SHA-256)해서 암호화합니다.

여기서 암호화된 값이 지문이 됩니다.⭐️

 

4) CA는 A회사의 지문을 자신의 비밀키로 암호화하고 인증서의 발급자 서명(Digital-Signing)으로 등록합니다.

이 값이 서명(Digital-Signing)이 됩니다. ⭐️

 

5) CA는 A서버에 인증서를 발급합니다.

 

위에서 보았듯 지문과 서명은 다릅니다.

 

A회사의 공개키를 해시 << 인증서의 지문

A회사의 지문을 CA의 비밀키로 암호화 << 서명(Digital-Signing)

 

 

상위기관은 하위기관에 인증서를 발급할 때 자신의 비밀키로 암호화를 해서 발급자 서명으로 등록합니다.

CA기관중 Intermediate CA의 인증서 또한 Root CA로부터 Root CA의 비밀키로 암호화하여 인증서를 발급받게 되며

Intermediate CA로부터 인증서를 받게되는 경우 Intermediate CA로부터 인증서를 받게되는 경우 Intermiate CA의 비밀키로 암호화 됩니다.

 

이렇게 각자의 상위기관으로부터 인증서를 받아 서로를 보증하게 되는 것을 인증서 체인(Certificate-Chain) 이라고 합니다.

 

Tistory의 인증서 계층

 

Tistory의 인증서 계층을 보면 tistory는 Thawte TLS RSA CA G1(Intermediate CA)로부터 인증서를 발급받았습니다.

발급자 성명은 Thawte TLS RSA CA G1의 비밀키로 암호화 되어있을 것입니다

 

Thawte TLS RSA CA G1는 DigiCert Global Root G2(Root CA)로부터 인증서를 발급받았습니다.

DigiCert Global Root G2는 Root CA이므로 상위기관이 존재하지 않습니다.

 

이런 경우 Root CA는 Self-Signed하게되는데 자신의 공개키를 해시한 후 자신의 비밀키로 암호화해서 서명으로 등록하게 됩니다.

 

 

* CA없이도 인증서는 생성 가능하며 TLS통신또한 가능합니다.
대신 Self-signed되며 "신뢰할 수 없는 사이트입니다." 라는 안내문이 등장합니다.

 

 

TLS인증서로 서버를 인증하는 방법

 

클라이언트들은 CA리스트와 CA의 공개키를 이미 가지고있습니다.

OS, 브라우저를 설치할때 포함하게되며 Mac은 keychain에, 브라우저는 소스코드에 보관합니다.

 

1) 클라이언트는 특정 서버에 접속을 시도합니다.

 

2) 서버는 클라이언트에게 인증서를 제공합니다.

 

3) 클라이언트는 자신이 가진 CA리스트에 있는 기관에서 발급된 것인지 확인합니다.

 

4) 확인이 된다면 CA의 공개키로 서버인증서의 서명을 복호화합니다.

 

인증서를 발급할 때 

 

A회사의 공개키를 해시 << 인증서의 지문

A회사의 지문을 CA의 비밀키로 암호화 << 서명(Digital-Signing)

 

라고 설명 드렸는데!

 

반대로 진행한다면 인증서의 디지털 서명(Digital-Signing)을 CA의 공개키로 복호화 한다면 인증서의 지문이 나오게됩니다.

 

A회사의 공개키를 해시한 값 (인증서의 지문)

A회사의 인증서의 디지털 서명을 발급자(CA)의 공개키로 복호화 한 값

 

이 두개의 값이 같다면 인증서는 위조되지 않았음을 의미하므로 인증서의 유효함을 검증합니다.

 

5) 인증서에 명시된 정보와 도메인에 명시된 정보가 같고 유효기간, 인증서의 폐기여부를 검증합니다.

 

6) TLS 세션수립을 위한 키를 RSA를 통해 공유합니다.

 

7) 클라이언트와 서버간 통신을 시작합니다.

 

 

여기까지가 TLS(SSL)인증서와 발급과정, 인증과정입니다.

 

 

 

다음 사이트를 참고했습니다.

 

https://www.cloudflare.com/ko-kr/learning/ssl/transport-layer-security-tls/

https://babbab2.tistory.com