네트워크

TLS 관련 용어, 개념 정리

peanutwalnut 2025. 2. 19. 11:00

TLS ( Transport Layer Security ) 는 서버와 클라이언트 간의 통신을 암호화하고, 양쪽이 서로를 신뢰할 수 있게 하는 보안 프로토콜이다.

이 과정을 이해하려면 기본적으로 인증서(Certificate)와 키(key)가 어떻게 동작하는지 알아야한다.

 

기본 개념: CA, 인증서, 개인 키

(1) CA(Certificate Authority) 인증서

CA는 인증서를 발행해주는 기관(또는 내부적으로 자체 운영하는 CA)이다.

ca.crt 파일은 CA가 소유한 공개 인증서이며, 서버 혹은 클라이언트 측에서 "이 인증서를 발행한 CA가 맞는지"를 신뢰할 수 있도록 검증 기준이 된다.

한마디로, "이 인증서는 내가 책임지고 발행했으니 믿어도 된다" 라고 선언해주는 최상위 권위자의 도장이라고 보면 된다.

 

(2) 서버 인증서 (server.crt)

서버 인증서는 말 그대로 서버(또는 서비스)가 가지고 있는 공개 인증서이다.

이 서버 인증서에는 "서버 도메인/호스트명", "만료 일자", "CA가 서명한 정보" 등이 들어 있다.

실제로 서버와 통신할 때, 클라이언트(또는 다른 서버)는 서버 인증서를 받아서,

1. 발행한 CA가 신뢰할 만한지(ca.crt로 검증)

2. 서버의 도메인(예: etcd0.mycompany.com)이 인증서에 적힌 이름과 일치하는지(SAN 또는 CN 확인) 등을 확인하여 이 서버는 믿을 수 있겠다 라고 판단한다.

 

(3) 서버 키 (server.key)

서버 인증서(server.crt)에 대응되는 개인 키이다.

서버는 이 키를 절대 유출해서는 안된다.

TLS 핸드셰이크 과정에서, 서버는 개인 키(server.key)를 이용해 "내가 인증서의 실제 주인임"을 증명하고, 안전하게 암호화 통신을 설정한다.

 

(4) 인증서 서명 요청 (server.csr)

서명되지 않은 인증서를 서명해달라고 요청하는 것을 CSR(Certificate Signing Request)라고 한다.

서버는 인증서를 서명받기 위해 CSR을 작성하여 CA 기관에 제출한 다음 CA는 인증서를 서명하여 요청한 서버에게 전달한다.

 

정리

  • ca.crt: CA의 공개 인증서 (누가 발행했는지 증명)
  • server.crt: 서버 본인의 공개 인증서
  • server.key: 서버 본인의 개인 키

 

왜 이것들이 필요한가?

1) 클라이언트 -> 서버 암호화 (서버 인증)

1. 클라이언트가 서버에 접속할 때, 서버는 server.crt를 건네준다.

2. 클라이언트는 서버가 준 server.crt를 받아서 자신이 가지고 있는 CA의 공개 인증서(ca.crt)로 서명 값을 검증한다.

3. 도메인 명(또는 IP)이 일치하는지도 확인한다.

4. 이후, server.key와 클라이언트의 임시 키 교환 과정을 통해 안전하게 암호화가 설정된다.

 

이 과정을 통해 클라이언트는 “이 서버가 진짜 맞구나” 를 확인하고, 데이터 통신이 암호화되어 노출되지 않게 됩니다.

 

2) 서버→클라이언트 인증(Mutual TLS, mTLS)

  • 추가로, 클라이언트 측에도 인증서와 키(예: client.crt, client.key)가 있으면, 서버가 클라이언트 인증서를 확인하여 “이 클라이언트 또한 유효한 사용자다” 라고 확인할 수 있습니다.
  • etcd 같은 분산 시스템에서는 피어 간 통신(서버↔서버)에서도 서로 인증서를 검증하는 양방향 TLS(mTLS)를 설정하기도 합니다.

 

 

3. 실제 구성에서 파일들이 하는 일

예를 들어 ETCD를 TLS로 설정한다고 할 때:

  1. ca.crt:
    • etcd가 상대방(클라이언트 혹은 다른 etcd 노드) 이 제시한 인증서가 믿을 수 있는지 검증하기 위해 사용.
    • 즉, CA 공개 인증서.
  2. server.crt:
    • 이 etcd 노드(혹은 “서버”)의 공개 인증서.
    • 클라이언트가 etcd로 접속해올 때, 이 인증서를 보고 “정말 맞는 서버”인지 검사하게 됨.
  3. server.key:
    • 해당 etcd 노드의 개인 키.
    • 외부에 노출되지 않으며, TLS 핸드셰이크 시 서버가 자신이 진짜임을 증명하기 위해 사용.

한 노드에 대해

  • ca.crt는 “남들의 인증서를 검증” 할 때 필요.
  • server.crt + server.key는 “내가 인증받을 때” 필요.

 

 

추가적으로 알아두면 좋은 점

  1. 서버 인증서(server.crt)와 키(server.key) 는 보통 한 쌍입니다.
    • 이 둘은 일반적으로 “CSR 생성 → CA 서명 → 인증서 발급” 과정을 거쳐 만들어짐.
  2. TLS 클라이언트 인증(mTLS)을 사용하려면, 클라이언트(혹은 다른 etcd 노드)도 자신의 인증서와 키를 가지고 있어야 합니다.
    • 이 경우, 서버 측도 ca.crt를 이용해 클라이언트가 낸 인증서가 유효한지 검증합니다.
  3. 클러스터(피어) 간 통신도 TLS로 안전하게 보호하려면, 각 노드마다 서버 인증서/키(또는 피어 인증서/키)를 발급하여 동일한 CA(ca.crt)를 통해 서로 확인할 수 있게 합니다.
  4. Self-signed CA를 쓰는 경우(직접 CA를 만듦), ca.crt는 내부 환경에서만 쓰이지만, 원리는 동일합니다.
    • 실서비스에서는 공개 CA(예: Let’s Encrypt, Digicert 등) 인증서를 사용하기도 합니다만, 내부 통신용으로는 자체 CA가 더 흔합니다.