Certificate Signing Request (CSR) 이란
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(또는 검증 시스템)는 다음을 수행합니다:
- CSR에서 아래 세 가지를 추출:
- certificationRequestInfo (주요 정보: 공개키, subject 등)
- signatureAlgorithm (예: SHA256withRSA)
- signature (BIT STRING, 개인키로 서명한 값)
- certificationRequestInfo에 대해 해시 수행
→ 서명 알고리즘에 따라 (예: SHA256) - CSR 안의 공개키로 서명 검증
→ 이 공개키로 위 해시와 signature를 비교 - 검증이 성공하면 →
✅ CSR은 진짜 개인키 소유자가 만든 것임
❌ 실패하면 → 위조/손상된 CSR
🔑 핵심 포인트
- 공개키로 서명 검증이 되면, 그 서명은 해당 개인키로 생성된 것이 확실함
- CSR 안에 있는 공개키로 검증하기 때문에, 공개키와 개인키가 짝이 맞는지 자연스럽게 확인됨
- 즉, 개인키를 가진 사람만 이 서명을 만들 수 있으므로 → 그 사람의 CSR임이 증명됨
📌 보완 질문들에 대한 간단한 답
이 공개키가 "누구의 것인지"는 어떻게 아나? | CSR의 subject 정보와 CA가 인증한 정보로 연결해야 함 (ex: 회사 등록, 도메인 소유 확인) |
공개키가 위조된 건 아닐까? | 그래서 CA는 본인 확인 절차를 반드시 거침 (전화, DNS, 파일 업로드 등) |
내가 제3자인척을 하고 내 공개키와 개인키 제3자의 정보를 넣어서 서명을 할 수도 있지 않을까?
🎭 상황 재현: 제3자인 척 CSR 보내기
예를 들어 공격자 A가 아래와 같이 할 수 있습니다:
- A가 자기 공개키/개인키 쌍을 생성
- CSR의 subject에 "CN=www.naver.com" 같은 제3자의 정보 입력
- 그 정보를 담은 certificationRequestInfo를 자기 개인키로 서명
- 그 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의 핵심 원칙) |