보안

Certificate Signing Request (CSR) 이란

MDanderson 2025. 6. 25. 21:19

CSR은 공개키 인증서를 발급받기 위해 인증기관(CA)에 보내는 요청 데이터입니다.

PKCS(Public-Key Cryptography Standards) #10은 인증서 서명 요청(CSR: Certificate Signing Request) 포맷을 정의한 표준입니다.

 

 

✉️ CSR 안에 들어있는 정보

  • 공개키 (Public Key)
  • DN (Distinguished Name): 인증서의 주체 정보
    • CN (Common Name): ex. www.example.com
    • O (Organization), OU (Org Unit), L (Locality), ST (State), C (Country) 등
  • 알고리즘 정보 (ex. SHA256 with RSA)
  • 디지털 서명 (개인키로 서명)

 

✅ CSR 안의 "공개키"와 "서명"은 무엇인가요?

🔑 공개키

  • **CSR 안의 공개키는 "내 공개키"**가 맞습니다.
  • 인증서가 발급되면, 이 공개키가 인증서에 들어가게 됩니다.
  • 즉, 인증서를 받기 위한 내 공개키를 CSR에 넣어서 보내는 겁니다.

✍️ 서명

  • CSR의 서명은 "내 개인키"로 서명한 값입니다.
  • 이 서명은 CSR에 담긴 공개키 + 이름 정보(subject) 등 전체 데이터를 개인키로 서명한 것입니다.
  • 목적: 내가 이 공개키의 주인이라는 것을 증명 (개인키로 서명 → 공개키로 검증 가능)

✅ 알고리즘 정보는 어떤 의미인가요?

CSR 안의 signatureAlgorithm에는 서명에 사용된 알고리즘이 들어갑니다.

예시: Signature Algorithm: sha256WithRSAEncryption

 

이 의미는:

  • 개인키 타입: RSA
  • 해시 함수: SHA-256

즉, 내 RSA 개인키로 SHA-256 해시를 서명한 것입니다.

 

 

 

🔧 CSR 예시 (PEM 형식)

 

-----BEGIN CERTIFICATE REQUEST-----
MIIC2DCCAcACAQAwgYcxCzAJBgNVBAYTAktSMQswCQYDVQQIDAJTRTEPMA0GA1UE
BwwG5rC45rWQMRgwFgYDVQQKDA/sgqzsm5DsoJXrj5kgMTExHzAdBgNVBAsMFlRl
Y2ggRGVwdCAtIFNvZnR3YXJlIERldjEfMB0GA1UEAwwWd3d3Lm15ZG9tYWluLmNv
bS5rciBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxuN4Vh4x2JhOaVmu
Rgg5hYZeqnkU7tduqpD4IbdcfhzfRW+Qr6Ldb9OmUmtKIB05kYb3ZDUML2SoROEu
...
ZvcFPRAxWhZgToGScazIVJcQGvPvkrKYGBE4S9TwFhN3fVE=
-----END CERTIFICATE REQUEST-----

 

이것은 Base64로 인코딩된 데이터이며, 내부 구조는 ASN.1/DER 형식입니다.

 

🧠 구조 요약 (ASN.1)

PKCS #10 CSR의 ASN.1 구조는 아래처럼 생겼습니다:

 

CertificationRequest ::= SEQUENCE {
  certificationRequestInfo CertificationRequestInfo,
  signatureAlgorithm       AlgorithmIdentifier,
  signature                BIT STRING
}

CertificationRequestInfo ::= SEQUENCE {
  version       INTEGER,  -- usually 0
  subject       Name,
  subjectPKInfo SubjectPublicKeyInfo,
  attributes    [0] IMPLICIT SET OF Attribute
}

 

이 중 subject에 이름(CN 등), subjectPKInfo에 공개키가, signature에 개인키로 서명한 값이 들어 있습니다.

 

CSR 전체는 이 세 가지 요소로 구성된 ASN.1 SEQUENCE입니다:

필드                                                                                                설명
certificationRequestInfo 서명할 "요청 정보" (핵심 내용)
signatureAlgorithm 서명에 사용된 알고리즘 (예: SHA256withRSA)
signature 개인키로 서명한 값 (BIT STRING)

certificationRequestInfo이 부분을 자세히 들여다 보면...

1. version : INTEGER

  • 버전 번호 (항상 0 사용됨)
  • 향후 확장을 대비한 필드

2. subject : Name

  • 인증서 주체의 식별 정보 (DN: Distinguished Name)
  • 예: CN(Common Name), O(Organization), C(Country), 등

3. subjectPKInfo : SubjectPublicKeyInfo

  • 이 CSR에서 요청하는 공개키 정보
  • 공개키 알고리즘 + 공개키 값

4. attributes : [0] IMPLICIT SET OF Attribute

  • 선택적인 속성들
  • 보통은 비어 있음, 특별한 정보 필요할 때 사용

예를 들어:

  • challengePassword
  • extensionRequest (확장필드 요청)
    • 예: Subject Alternative Name (SAN)

 

🛠 실습: CSR 직접 만들어보기

터미널에서 CSR을 생성하려면:

# 개인키 생성
openssl genrsa -out mykey.pem 2048

# CSR 생성
openssl req -new -key mykey.pem -out mycsr.csr

mycsr.csr 파일은 위에서 본 것처럼 BEGIN/END 블록으로 시작하는 PEM 형식입니다.

 


이 CSR을 받고 진짜 송신자가 보낸 개인키와 공개키쌍이 맞는지를 어떻게 알까?

CSR 안의 정보가 진짜 송신자(개인키 소유자)가 만든 것인지,
공개키와 개인키 쌍이 맞는지서명(signature) 검증을 통해 확인합니다.

 

✅ 검증 절차 요약

CA(또는 검증 시스템)는 다음을 수행합니다:

  1. CSR에서 아래 세 가지를 추출:
    • certificationRequestInfo (주요 정보: 공개키, subject 등)
    • signatureAlgorithm (예: SHA256withRSA)
    • signature (BIT STRING, 개인키로 서명한 값)
  2. certificationRequestInfo에 대해 해시 수행
    → 서명 알고리즘에 따라 (예: SHA256)
  3. CSR 안의 공개키로 서명 검증
    → 이 공개키로 위 해시와 signature를 비교
  4. 검증이 성공하면
    ✅ CSR은 진짜 개인키 소유자가 만든 것임
    ❌ 실패하면 → 위조/손상된 CSR

🔑 핵심 포인트

  • 공개키로 서명 검증이 되면, 그 서명은 해당 개인키로 생성된 것이 확실함
  • CSR 안에 있는 공개키로 검증하기 때문에, 공개키와 개인키가 짝이 맞는지 자연스럽게 확인됨
  • 즉, 개인키를 가진 사람만 이 서명을 만들 수 있으므로 → 그 사람의 CSR임이 증명됨

📌 보완 질문들에 대한 간단한 답

질문                                                                        답변

 

이 공개키가 "누구의 것인지"는 어떻게 아나? CSR의 subject 정보와 CA가 인증한 정보로 연결해야 함 (ex: 회사 등록, 도메인 소유 확인)
공개키가 위조된 건 아닐까? 그래서 CA는 본인 확인 절차를 반드시 거침 (전화, DNS, 파일 업로드 등)

내가 제3자인척을 하고 내 공개키와 개인키 제3자의 정보를 넣어서 서명을 할 수도 있지 않을까?

 

 

🎭 상황 재현: 제3자인 척 CSR 보내기

예를 들어 공격자 A가 아래와 같이 할 수 있습니다:

  1. A가 자기 공개키/개인키 쌍을 생성
  2. CSR의 subject에 "CN=www.naver.com" 같은 제3자의 정보 입력
  3. 그 정보를 담은 certificationRequestInfo를 자기 개인키로 서명
  4. 그 CSR을 인증기관(CA)에 제출

→ 이 CSR은 서명 검증이 기술적으로 유효합니다.
→ 하지만 문제는 이 사람이 정말 www.naver.com의 소유자냐는 보장 없음입니다.

 

🔐 그래서 중요한 것이 바로 CA의 검증 절차입니다

CA는 단순히 서명이 맞는지만 보고 인증서를 발급하지 않습니다.
CSR에 들어있는 "subject" 정보를 본인 소유인지 검증해야 합니다.

예시: 인증서 발급 단계에서 하는 검증들

타입                                                                   검증 방법
도메인 인증 (DV) CSR에 CN=www.example.com → CA가 www.example.com에 파일 업로드 요청 or 이메일 인증
조직 인증 (OV) 기업 사업자 등록증, 전화 등으로 실존 조직 여부 확인
확장 인증 (EV) 심층적 서류+법적 검증 (ex: 녹색 주소창용)

✅ 결론

질문                                                                          답변
내가 제3자인 척 CSR 만들 수 있나? 기술적으로는 YES
그러면 CA가 속을까? 제대로 된 CA는 절대 NO — 소유권/본인 인증 절차를 반드시 거침
그래서 중요한 건? 서명 검증 + 본인 확인 둘 다 필요함 (PKI의 핵심 원칙)