CA 란?

• CA(Certificate Authority)의 약자로, 디지털 인증서를 저장, 서명, 발급할 수 있는 entity(기관)
  ⇒ 인증기관
  - 인증서는 뭘까?
  - 시스템에서 ID 를 확인하고 SSL/TLS 프로토콜을 사용해서 다른 시스템에 대한 암호화된 네트워크 연결을 설정할 수 있도록 하는 디지털 객체
  - Entity는 또 뭐임?
  - Entity의 사전적 의미
  - 데이터베이스에서 쓰이는 Entity는 개체를 의미함
  - 그냥 간단하게 어떤 기관 이라고 생각하자
  - 사람들이 생각하는 개념이나 정보 단위와 같은 현실 세계의 대상체, 실세계에 존재하는 유형 혹은 무형 정보의 대상이며 서로 구별이 되는 하나하나의 대상을 의미
  - 이 개체는 하나 이상의 속성으로 구성

Internet 환경에서 HTTPS 연결은 어떻게 됨? (최초 통신이라 가정)

• HTTPS는 HTTP 프로토콜에 SSL/TLS 암호화 계층을 추가하여 데이터를 안전하게 주고받는 방식
• 어떤 단계를 거칠까? (Server와 Client가 있다고 가정)
  1. Server는 인증서를 발급
     1. 인증서 요청 파일과 개인키 생성
     2. 발급한 인증서 요청 파일을 CA 에 전달
     3. CA는 전달받은 요청 파일에 기반하여 CA의 개인키로 서명된 인증서를 발급
        1. 이 서명을 함으로써 이 인증서가 이 CA로 부터 서명된 인증서임을 증명
     4. CA는 인증서 정보로 데이터베이스, CRL, OCSP를 업데이트
  2. Server에 HTTPS Configuration을 적절히 구성
  3. Client에서 Server에 HTTPS 연결 요청을 보냄
     1. Server가 Client에게 인증서를 보냄
     2. Client은 인증서가 적절한지 확인
        1. 이 인증서가 신뢰할 수 있는 CA에 의해 서명된 인증서인지 확인
        2. 인증서 유효 기간 확인
        3. CRL을 통해 이 인증서가 만료되었는지 확인
        4. OCSP를 통해 이 인증서를 사용할 수 있는지 확인
        • 이 과정들은 Root CA 기준
          • 혹시 Sub CA 라면 바로 윗 단계의 CA와 이 과정을 반복
     3. Client는 대칭키 생성
        • 대칭키를 사용하는 이유? ⇒ 속도가 빨라서
          • 용량이 큰 파일을 대칭키로 암호화 하고, 이 대칭키를 비대칭키로 암호화함으로써 속도가 더 빨라질 수 있음
     4. Client는 대칭키를 Public Key로 암호화 하여 Server에 전달
     5. Server는 Private Key로 전달 받은 Public Key를 통해 암호화된 대칭키 파일을 복호화해 알아냄
     6. Client는 HTTP Data를 대칭키로 암호화해서 보냄
     7. Server는 이를 대칭키로 복호화함

HTTPS의 주요 보안 기능

1. 기밀성
   • 데이터를 암호화하여 외부에서 보지 못하도록 설정
2. 무결성
   • 데이터가 전송 중에 변조되지 않을 것을 보장
3. 인증
   • 서버의 신원을 확인하여 피싱 및 중간자 공격 방지

인증서의 역할은?

1. 신원 확인
   • 브라우저가 인증서를 검증하여 사용자가 접속한 웹사이트가 정상적인 웹사이트인지 확인
2. 데이터 암호화
   • 인증서를 통해 클라이언트와 서버 간의 데이터가 암호화 됨
   • 데이터 전송 중에 제 3자가 가로채가도 알아갈 수 없게 함
3. 데이터 무결성
   • 통신 중 데이터가 변경되거나 변조되지 않았음을 보장
   • 데이터가 전송 중 변조되었는지 확인하는 기능 제공
4. 신뢰성 제공
   • CA에 의해 발급됨
   • CA가 인증서를 발급하기 전에 도메인 소유권 및 조직 정보를 철저히 검증
     • 웹사이트가 안전한지 확인하는 법?
       • 주소창에 자물쇠(🔒) 아이콘을 통해 알 수 있음

CA의 역할은?

1. 인증서 발급
   • 공개키 암호화 시스템에서 공개 키와 소유자의 신원을 인증하는 디지털 인증서를 발급함
   • 디지털 인증서는 인증서의 명시된 주체에 의해 공개키의 소유권을 인증
2. 신원 확인
   • 인증서를 발급하기 전에, 인증 요청자가 신뢰할 수 있는 주체인지 확인
3. 인증서 관리 및 폐기
   • 발급된 인증서의 유효성을 유지
   • 만료되거나 유효하지 않은 인증서는 폐기

CRL/OCSP란?

CRL (Certififcate Revocation Lists)

⇒ 인증서 해지 목록

• 해지되었거나 더 이상 유효하지 않은 인증서의 목록
• 인증기관이 SSL 인증서를 해지 한 후 인증서의 정보를 CRL 목록에 등록
• SSL 인증서의 유효성을 확인하기 위해 클라이언트는 URL에 접속해서 인증기관이 등록한 CRL 목록을 다운로드한 후 인증서의 Serial Number를 통해 유효성 확인

OCSP (Online Certififate Status Protocol)

⇒ 온라인 인증서 상태 프로토콜

• CRL을 주기적으로 업데이트 해줘야 한다는 단점을 보완
• 클라이언트가 CA 서버에 인증서의 상태 확인요청을 실시간으로 보내면 CA 서버는 인증서의 유효성을 확인하여 응답을 제공
• OCSP 요청에는 인증서 상태를 찾기 위해 브라우저가 해지된 인증서 목록을 확인하지 않아도 됨

CRL/OCSP를 포함한 HTTPS 통신과정은?

1. Client 와 Server의 handshaking 과정으로 서로 탐색
   • Client Hello
     • Client 측에서 생성한 랜덤 데이터
     • 암호화 방식 통일을 위한 클라이언트가 사용할 수 있는 암호화 방식
     • Handshaking 기록이 있다면 자원 절약을 위해 기존 세션을 재활용하기 위한 세션 아이디
   • Server Hello
     • Server 측에서 생성한 랜덤 데이터
     • Server가 선택한 Client의 암호화 방식
     • SSL 인증서
   • Client 인증 확인
     • 서버로부터 받은 인증서가 CA에 의해 발급되었는지 본인이 가지고 있는 목록에서 확인
     • 목록에 있다면 CA 공개키로 인증서 복호화
       • 이 과정에서 CRL과 OCSP 가 사용됨
     • CLI - SRV 각각의 랜덤 데이터를 조합하여 pre master secret 값 생성
       • 이 값은 데이터 송수신 시 대칭키 암호화에 사용할 키
     • pre master secret 값을 공개키 방식으로 서버 전달
       • 공개키는 서버로부터 받은 인증서에 포함
     • 일련의 과정을 거져 session key 생성
   • Server 인증 확인
     • Server는 비공개키로 복호화하여 pre master secret 값 취득
       • 대칭키 공유 완료
     • 일련의 과정을 거쳐 session key 생성
2. 데이터 전송
   • Server와 Client는 session key를 활용해 데이터를 암/복호화하여 데이터 송수신
3. 연결 종료 및 session key 폐기

하위 인증기관 (Intermediate CA) 란?

• 그 전에 루트 인증기관에 대해 알아보자

루트 인증기관 (Root CA) 란?

• 최상위 인증기관
• 모든 인증서 신뢰 체인의 시작점
• 루트 인증서는 자체 서명되어 있음
• 운영체제나 브라우저에 사전 설치된 신뢰 목록에 포함됨
• 주요 특징
  • 루트 인증기관이 손상되면 해당 인증기관의 모든 인증서가 신뢰를 잃게 됨
  • 보안을 위해 루트 인증서는 일반적으로 오프라인 상태로 관리

이제 하위 인증기관을 알아보자

• 루트 CA로부터 서명을 받은 인증기관
• 실제로 서버 인증서(도메인 인증서)를 발급하는 역할
• 중간 계층 역할을 하여 루트 CA의 키를 보호하면서도 인증서를 효율적으로 발급할 수 있게 함

왜 하위 인증기관이 필요함?

• 보안 강화
  • 루트 CA의 비밀키를 직접 사용하지 않고 하위 CA를 통해 인증서를 발급함으로써, 루트 CA의 키가 노출될 위험을 줄임
• 관리 효율성
  • 여러 하위 인증기관이 각각 다른 역할이나 고객을 담당할 수 있음
    • 예시 : 특정 지역용 CA, 특정 기업용 CA
• 유연성
  • 하위 CA가 손상되거나 문제가 발생해도, 해당 하위 CA만 폐기하면 되기 때문에 루트 CA 전체를 폐기할 필요가 없음

서명 알고리즘 (RSA, ECDSA)

RSA

• 공개키 암호 시스템
• 암/복호화도 가능하고 전자서명에도 사용됨
• 공개키와 개인키를 사용함
• 소인수 분해 계산 방식을 사용함
  • 애초에 계산 속도가 오래걸림 (결국 언젠가는 뚫린다는 뜻)
    • google에서는 2048 bit로 암호화된 것을 3개월마다 갱신하라고 함
• RSA 서명 알고리즘
  1. 키 생성
     • RSA 서명에 필요한 공개 키와 비밀 키를 만듦
  2. 서명 생성 (서명자 측)
     • 서명할 데이터를 준비
     • 데이터에 대해 해시함수를 사용하여 해시값을 계산
       • 여기서 해시(Hash)란?
         • 데이터를 다루는 기법
         • 해시 값 : 다양한 길이를 가진 데이터를 고정된 길이를 가진 데이터로 매핑한 값
         • 해시의 특징
           • 해시를 통한 데이터 저장 시에는 검색과 저장이 아주 빠르게 진행
           • 무결성
           • 보안성
       • 해시 함수는?
         • 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 단반향성 함수/알고리즘 정도
         • 어디에 씀?
           • 메시지의 무결성 확인
           • 디지털 서명의 생성
           • 메세지 인증코드의 생성
           • 일회용 패스워드(OTP)의 생성
           • 세션 키 도출
           • 소프트웨어 배포시 변경 검출
         • 알고리즘의 예
           • MD5
           • SHA
     • 해시값을 비밀 키로 암호화하여 서명을 만듦
  3. 서명 검증 (검증자 측)
     • 전달받은 데이터와 서명을 받음
     • 데이터에 대해 똑같은 해시 함수를 사용하여 새로운 해시값을 계산
     • 서명을 공개 키로 복호화하여 원래의 해시값을 복원
     • 두 해시값을 비교
       • 동일하면 서명이 유효
       • 다르면 데이터가 변경되었거나, 서명이 위조된 것

ECDSA

• 전자 서명 알고리즘 중 하나로, 타원 곡선 암호학을 기반으로 설계된 알고리즘
• RSA보다 보안성과 성능 면에서 더 효율적
• ECDSA 서명 알고리즘
  1. 키 생성
     • 개인키와 공개키 생성
       • 개인키 : 무작위 숫자로 생성
       • 공개키 : Elliptic Curve Scalar Multiplication (타원 곡선 스칼라 곱) 이라는 함수를 통해 개인 키로 계산
         • 공개키는 다른사람들과 자유롭게 공유 가능
  2. 서명 생성 (서명자 측)
     • 서명을 할 데이터 준비
     • 데이터를 해시 함수로 처리하여 해시 값을 만듦
       • 해시 값은 데이터의 요약본으로, 고정된 길이의 숫자
     • 랜덤 값 k 를 생성 (매번 새로운 값이여야 함)
     • 서명을 계산
       • 서명은 데이터와 함께 다른 사람에게 전달
  3. 서명 검증 (검증자 측)
     • 서명과 데이터를 전달 받음
     • 데이터를 해시함수로 처리하며 해시값을 만듦
     • 서명을 공개 키로 검증
       • 서명이 유효하면 데이터가 변경되지 않고 올바른 사람이 서명함을 알 수 있음

Windows CA 에 대한 이해

• Standalone CA
  • 독립적으로 운영되는 인증기관
  • 주요 특징
    • 독립성
      • 다른 CA 서버와 연결되지 않고 독립적으로 운영
      • 단독으로 인증서 발급 및 관리 함
    • 인증서 발급
      • 사용자, 서버, 애플리케이션 등의 공개 키를 인증하고 디지털 인증서 발급
      • SSL/TLS 연결을 위한 신뢰성 있는 인증 정보로 사용
    • 인증서 관리
      • 인증서 발급, 갱신, 폐기 등 관리 작업을 독립적으로 처리
      • 이를 통해 보안성을 유지하고, 유효하지 않거나 만료된 인증서를 폐기할 수 있음
    • 루트 인증서
      • Standalone CA 는 루트 인증서를 보유하고, 이를 통해 다른 인증서들을 서명
      • 루트 인증서는 다른 시스템에서 신뢰할 수 있는 인증서로 쓰임
    • 내부 또는 외부 사용
      • Standalone CA는 내부 네트워크에서 사용될 수 있으며, 기업 내에서만 사용하는 인증서를 발급할 때 유용함
      • 외부의 클라이언트와 연결된 인증서 발급도 할 수 있음
• Enterprise CA
  • 기업 또는 조직 내에서 인증서 관리하고 발급하는 역할을 하는 인증기관
  • 조직의 내부 네트워크와 보안 요구 사항에 맞게 설정되고 운영
  • 대규모 환경에서 인증서의 중앙 관리와 자동화를 지원하는 특징있음
  • 주요 특징
    • 중앙 집중식 인증서 관리
      • 조직 내 모든 인증서를 관리
      • 사용자 인증서, 서버 인증서, 코드 서명 인증서 등 다양한 인증서를 발급하고 관리하는 역할
      • 여러 개의 인증 기관을 운영할 수 있으며, 이를 통해 인증서를 조직의 보안 정책에 맞게 효율적으로 관리할 수 있음
    • 자동화된 인증서 발급
      • 자동화된 인증서 발급, 갱신 및 폐기 기능을 제공
        • 예를 들어, Active Directory 와 통합되어 사용자의 컴퓨터나 서버가 자동으로 인증서를 받을 수 있게 됨
        • 대규모 환경에서 수동으로 인증서를 관리하는 것 보다 효율적이고 오류를 줄이는데 도움이 됨
    • 조직 내부 통합
      • Enterprise CA는 Active Directory에 통합되어 관리
      • Active Directory와의 연동을 통해 조직 내 사용자나 컴퓨터에 인증서를 자동으로 할당하고 관리할 수 있음
      • Active Directory와의 통합으로 사용자와의 장비에 대한 인증서를 중앙에서 관리
      • 인증서 갱신, 폐기 등의 작업을 쉽게 할 수 있음
    • 보안 및 규정 준수
      • Enterprise CA는 기업의 보안 정책와 규정을 따름
      • 인증서 발급 및 관리를 통해 네트워크 보안 강화
      • VPN, 이메일 암호화, 코드 서명, SSL/TLS 인증서 등을 이용해 조직의 IT 인프라를 안전하게 보호
    • 내부 및 외부 인증서 발급
      • Enterprise CA 는 내부 조직에만 인증서를 발급할 수도 있지만, 외부와의 연결에 필요한 인증서도 발급 가능
    • 서브 CA 운영
      • Enterprise CA는 여러 개의 서브 CA를 운영할 수 있음
      • 상위 CA가 모든 인증서 발급을 관리하고, 하위 CA가 특수한 역할을 수행하는 형태로 분리하여 운영할 수 있음
• 인증서 템플릿
  • 인증서 발급 과정에서 사용되는 미리 정의된 파일
  • 인증서의 구조와 속성을 표준화 하기 위해 사용됨
  • 인증서를 발급할 때 필요한 세부 정보를 지정하여 자동화와 일관성을 제공
  • 주요 역할
    • 인증서 속성 정의
      • 발급되는 인증서의 형식과 내용을 정의
        • 예 : 유효 기간, 서명 알고리즘, 키 길이 등
      • 특정 목적에 맞는 요구 사항 설정
    • 자동화
      • 인증서를 발급할 때 매번 세부 사항을 수동으로 지정하지 않아도 되도록 설정을 미리 정의
      • Enterprise CA 와 통합하여 인증서 발급을 자동화 할 수 있음
    • 일관성 보장
      • 동일한 형식의 인증서에 대해 동일한 정책과 설정을 적용
      • 조직 내에서 인증서 발급과 관리에 대한 표준화된 절차를 제공
  • 인증서 템플릿에 포함되는 주요 설정
    • 목적
      • 인증서가 사용될 목적을 정의
        • 예 : 사용자 인증, 서버 인증, 이메일 보호, 코드 서명 등
    • 유효 기간
      • 인증서의 유효기간 설정
    • 암호화 알고리즘 및 키 크기
      • 인증서에 사용될 키의 크기와 알고리즘 선택
    • 확장 필드
      • 인증서에 추가적인 정보를 포함시켜, 인증서의 용도와 사용 제한을 명확히 정의하는 데 사용
      • 인증서를 발급하는 엔터티(사용자, 서버 등)에 대한 세부 정보와 보안 속성을 담아, 인증서의 사용성을 제어하거나 보안을 강화하는 중요한 역할을 함
    • 보안 및 접근 제어
      • 어떤 사용자나 그룹이 이 템플릿을 사용할 수 있는지에 대해 권한 설정
    • 자동 갱신 정책
      • 인증서가 만료되기 전에 자동 갱신될 지 여부 지정
  • 동작 과정
    1. 템플릿 생성
       • 인증서를 발급할 목적에 따라 템플릿 정의
    2. 사용자 요청
       • 사용자가 인증서를 요청
         • 이때 사용자가 특정 템플릿을 선택하거나 지정된 템플릿이 자동으로 적용됨
    3. CA 에 전달
       • 템플릿의 설정에 따라 CA 가 인증서를 발급
    4. 인증서 발급
       • 템플릿에 정의된 정책과 속성에 따라 인증서를 발급하여 사용자나 시스템에 전달

와일드카드 인증서

• 기본 도메인의 하위 서브 도메인에 SSL 적용을 무제한 적용할 수 있도록 하는 인증서이다.
• 와일드카드 인증서는 요청서를 제출할 때 사용자가 지정하는 수준에서 공통 이름과 모든 하위 도메인을 보호함
• 공통 이름 왼쪽의 하위 도메인 영역에 별표(*)를 추가하면 된다.
  • 예시) *.example.com 이라는 인증서가 있다고 가정
    • 보호를 받을 수 있는 도메인 주소 : example.com, www.example.com, mail.example.com, branch.example.com 등
    • 보호를 받을 수 없는 도메인 주소 : sub.www.example.com, sub.mail.example.com, sub.branch.example.com 등

필요한 이유

• 기존의 단일 도메인 인증서보다 더 큰 네트워크를 캐스트하기 때문에 인증서 소유2자가 도메인과 연관된 서브 도메인 수를 처리하는 작업이 줄어든다.
• 대체 옵션보다 기존 사이트에 새 하위 도메인을 추가할 때 훨씬 더 유연하다.

용도

• 여러 개의 서브 도메인 각각 발급 받는 것보다 Wildcard SSL 1개 적용이 비용절감/관리에 유리한 경우
• 서브 도메인으로 다양한 웹 서비스가 지속적인 확장이 예상되고, 모든 서브에 SSL 적용이 필요한 경우
• 웹 서버에서 443 SSL 기본 포트로 모든 서브 도메인 웹사이트에 적용하고자 하는 경우

일반 인증서와의 차이?

• 와일드카드 인증서는 광범위한 하위 도메인을 유연하게 처리할 수 있다.
• 와일드카드와 가장 유사한 인증서 → SAN(Subject Alternate Name) 인증서, UCC(Unified Communication Certificate) (다중 인증서, Exchange 인증서라고 함)
  • 이 2개의 인증서는 최대 500개의 항목을 보호하기 위한 것

SAN 인증서

• SAN (Subject Alternative Name) 인증서
• 하나의 SSL/TLS 인증서로 여러 개의 도메인과 서브도메인을 보호할 수 있는 인증서
• 기본적으로 SSL 인증서는 Common Name(CN) 에 한 개의 도메인만 설정할 수 있지만, SAN 필드를 활용하면 여러 개의 도메인을 하나의 인증서에 추가할 수 있음

SAN 인증서 특징

• 여러 개의 도메인 및 서브도메인을 한 인증서에 포함 가능
• 서로 다른 도메인도 보호 가능
• 와일드카드 인증서보단 유연함
• 비용 절감 및 관리 편의성 증가

SAN 인증서 vs. 와일드카드 인증서

구분	SAN 인증서	와일드카드 인증서
보호 대상	서로 다른 여러 도메인 & 서브도메인 가능	특정 도메인 1차 서브도메인만 가능 (*.example.com)
예시	example.com, mail.example.net, sub.domain.org	*.example.com (예 : blog.example.com, shop.example.com)
유연성	다양한 도메인 포함 가능	특정 도메인 내에서만 사용 가능
비용	도메인 수에 따라 비용 증가 가능	상대적으로 저렴 (특정 도메인 내에서만 사용 시)

SAN 인증서가 필요한 경우

• 여러 개의 서로 다른 도메인을 하나의 인증서로 보호해야할 때
• 비용 절감 및 인증서 관리 부담을 줄이고 싶을 때
• 특정 도메인 (example.com)뿐만 아니라, 다른 도메인 (example.net, domain.org)까지 포함해야할 때

최근 웹사이트에서 주로 사용하는 인증서

구글은 SAN을 사용하는 것 같다

google play에서는 와일드카드 인증서를 사용

다른 웹사이트까지 찾아본 결과

SAN 인증서를 주로 더 사용하는 것 같음