등록 방식

따라서 인증서 등록 프로토콜의 핵심 속성은 인증서 요청자를 어떻게 인증하는가에 있습니다. 인증서를 어디에 사용하는지에 따라 어떤 프로토콜이 더 유리한지가 달라집니다.

또 하나의 중요한 속성은 실제 보급 정도입니다. 의도한 사용 사례에서 등록 방식이나 프로토콜은 CA 쪽과 클라이언트 쪽 모두에서 지원되어야 합니다.

가장 널리 쓰이는 등록 프로토콜은 다음과 같습니다.

• SCEP
• ACME
• EST
• Microsoft의 RPC/DCOM
• Microsoft의 SOAP
• CA 웹 페이지에서의 수동 등록
• 기타 독자 프로토콜

SCEP

역사와 사양

Simple Certificate Enrollment Protocol(SCEP)은 Cisco가 처음 고안했습니다. 당시에는 표준이 없었는데도 MDM 시스템에서 널리 채택되었습니다. Cisco는 더 나아가 SCEP을 대체할 후속 프로토콜인 Enrollment over Secure Transport(EST)까지 설계했습니다. 그래서 EST는 RFC 7030으로 훨씬 일찍 공개 표준이 되었고, SCEP은 한참 뒤인 RFC 8894에서야 표준화되었습니다. 그때 SCEP은 이미 MDM 시스템의 인증서 등록을 위한 사실상의 표준이었습니다.

기술

SCEP은 HTTP 기반입니다. SCEP 요청은 암호화하고 서명한 PKCS#7이며, GET 또는 POST 요청으로 SCEP 서비스에 전송됩니다. 서비스는 마찬가지로 암호화하고 서명한 PKCS#7 형태의 SCEP 응답을 반환합니다. 요청에는 PKCS#10 인증서 서명 요청이 들어 있고, 응답에는 발급된 X.509 인증서가 들어 있습니다.

인증

PKCS#10 요청에는 "SCEP 챌린지"가 들어 있으며, 이는 해당 SCEP 서비스에 따라 달라지는 대역 외 방식으로 서명 요청을 인증하고 인가합니다. 오늘날 실제로 쓰이는 SCEP 챌린지는 세 가지입니다.

정적 SCEP 챌린지

가장 단순한 방법은 고정된 암호 문구입니다. PKCS#10의 SCEP 챌린지가 SCEP 서비스에 미리 저장된 값과 일치하면 인증서가 발급되고, 그렇지 않으면 요청이 거부됩니다. 이 방법의 문제는 요청된 인증서의 속성이 요청자와 일치하는지를 사실상 확인할 수 없다는 점입니다. 이 문제에는 CVE까지 등록되어 있습니다.

이러한 방식은 다시 다음과 같이 구분할 수 있습니다.

1. 직접 SCEP 등록에서는 인증서를 등록받을 개체가 SCEP 서비스와 직접 통신합니다. 예를 들어 MDM 시스템이 어떤 Android 휴대폰에 "SecurePassword"라는 SCEP 챌린지로 SCEP 등록을 수행하라고 지시합니다. Android 휴대폰은 올바른 값이 담기기를 기대하며 CSR을 생성하고, SCEP 챌린지로 "SecurePassword"를 넣습니다. 그런 다음 CSR을 SCEP 서비스로 보내고 발급된 인증서를 돌려받습니다.
2. 투명 SCEP 프록시는 HTTP 리버스 프록시와 같습니다. SCEP은 암호화되고 서명되어 있으므로 프록시는 SCEP 요청이나 응답의 내용을 들여다볼 수도, 수정할 수도 없지만, 네트워크 경계를 기준으로 누가 언제 인증서를 등록할 수 있는지는 통제할 수 있습니다.
3. 프로토콜 어댑터 SCEP 프록시는 다른 시스템을 대신해 SCEP으로 인증서를 요청하는 시스템입니다. 예를 들어 JAMF 같은 MDM 시스템이 어떤 iPhone을 대신해 SCEP 서비스에 인증서를 요청할 수 있습니다. 인증서와 개인 키를 받고 나면 다른 프로토콜로 인증서를 배포할 수 있습니다. 이렇게 하면 SCEP 챌린지에 접근하는 것은 MDM 시스템뿐이며, MDM 시스템이 인증서의 내용도 통제할 수 있습니다.

동적 SCEP 챌린지

이 경우 각 SCEP 챌린지는 단 한 번의 인증서 요청에만 유효합니다. 덕분에 SCEP 서비스는 해당 SCEP 요청을 식별하고, 요청된 인증서 속성이 그 요청에 허용된 값과 일치하는지 검증할 수 있습니다.

MDM 시스템과 SCEP CA가 요청에 사용할 SCEP 챌린지를 합의하는 방식은 실무에서 대체로 두 가지입니다.

1. MDM 시스템이 SCEP 요청에 필요한 일회용 코드를 SCEP 서비스에 요청합니다.
   1. Microsoft NDES가 그 예입니다. NDES는 AD 자격 증명으로 인증하는 별도의 "admin" 페이지를 제공합니다. 이 관리 페이지에 접근할 때마다 SCEP 요청 한 건에만 쓸 수 있는 새 일회용 코드를 생성해 표시합니다. 다만 이 구성으로 사용할 때 NDES는 인증서의 속성을 전혀 확인하지 않는데, 일회용 코드가 범용이기 때문입니다.
2. MDM 시스템이 관리 대상 시스템에 SCEP으로 인증서를 요청하라고 지시할 때 일회용 코드를 생성합니다. SCEP 요청이 SCEP 서비스에 도착하면, 서비스는 보통 웹 훅으로 MDM 시스템에서 일회용 코드를 가져와 요청의 SCEP 챌린지와 일치하는지 확인해야 합니다. 이 프로토콜에는 표준이 없으므로 MDM 시스템과 SCEP 서비스가 어떤 형식을 쓸지 합의해야 하며, 요청의 속성을 검사하는지 여부도 구현에 따라 달라집니다.

서명된 메타데이터

SCEP 챌린지에는 사실상 길이 제한이 없습니다. 따라서 사람이 이해할 수 있는 "암호 문구"일 필요가 없고 BLOB일 수도 있습니다.

Intune은 서명하고 암호화한 XML을 SCEP 챌린지로 사용합니다. Intune은 인증서를 등록하려 할 때 이 XML을 서버 측에서 만들어 클라이언트 디바이스로 보내고, 디바이스는 SCEP 요청을 생성합니다.

SCEP 서비스는 PKCS#10 요청 전체를 Intune SCEP 챌린지 서비스로 보내야 합니다. SCEP 챌린지 서비스는 XML을 복호화할 개인 키와, 그것이 정품 Intune 서비스에서 생성되었는지 확인할 공개 키를 가지고 있습니다.

XML에는 주체(Subject)가 어떤 형태여야 하는지 같은 요청 관련 메타데이터가 들어 있습니다. 이 정보는 한편으로는 SCEP 구성 프로필에서, 다른 한편으로는 인증서를 발급받을 사용자나 디바이스의 구체적인 개체 데이터에서 도출됩니다.

예를 들어 SCEP 구성 프로필이 주체를 CN={{DeviceId}}로 설정했다고 해 보겠습니다. 아이디가 xyz인 디바이스가 인증서를 요청하면 XML에는 주체가 CN=xyz여야 한다고 기록됩니다. 그러면 SCEP 챌린지 서비스가 XML의 정보와 PKCS#10 요청의 주체를 비교합니다. 주체가 다르면 검증에 실패하고, 이 항목과 나머지 속성이 일치하면 성공합니다.

SCEP 서비스는 검증에 성공한 경우에만 인증서를 발급합니다.

Microsoft는 이 검증을 설명하는 문서를 제공합니다.

Microsoft NDES는 추가 NDES 정책 모듈로 이를 지원하며, 다른 SCEP CA가 이를 기본으로 지원하는지는 제품에 따라 다릅니다.

Microsoft RPC/DCOM

역사

Microsoft Active Directory Certificate Services(ADCS)는 "Microsoft CA"라고만 불리기도 하며, Windows Server에 내장된 인증 기관 소프트웨어입니다. 이 소프트웨어는 원래 지난 천 년의 끝 무렵에 개발되었고 이후 10~15년 동안 계속 기능이 추가되었습니다.

대안으로는 Microsoft의 SOAP이나 SCEP이 있으며, Microsoft는 각각 웹 등록(Web Enrollment)과 NDES라고 부릅니다.

사양과 보급

그동안 Microsoft가 Microsoft OpenSpec에 사양을 공개하기는 했지만, 이 프로토콜을 구현한 다른 CA 시스템은 알려진 바가 없습니다. 클라이언트 쪽에서는 Windows가 이 프로토콜을 기본으로 지원하며, 다른 플랫폼은 지원되지 않습니다.

기술

주된 등록 방식은 RPC나 DCOM을 기반으로 하는 독자 프로토콜입니다.

자동 등록도 이 프로토콜을 사용합니다. 자동 등록이 작동하려면 다음이 필요합니다.

• 도메인에 가입된 디바이스,
• 자동 등록을 활성화하는 그룹 정책,
• 독립 실행형이 아닌 엔터프라이즈 CA,
• 그 CA가 등록하는 인증서 템플릿,
• 그리고 해당 템플릿에 대해 사용자나 디바이스가 가진 등록 및 자동 등록 권한.

자동 등록을 확인하는 기본 간격은 8시간이지만, certutil -pulse나 대개 더 효과적인 gpupdate -force로 강제할 수 있습니다.

인증

이 프로토콜은 Active Directory에 내장된 인증 프로토콜을 사용합니다. 즉, 사용자와 컴퓨터가 자신의 AD 자격 증명으로 인증합니다.