프라이빗 CA와 퍼블릭 CA: 잘못된 쪽을 쓰고 계실지도 모릅니다

압박에 시달리는 IT 팀에게 퍼블릭 인증 기관(CA)은 흔히 망치처럼 보이고, 모든 암호화 요구 사항은 못처럼 보입니다. 그러나 모든 작업에 퍼블릭 CA를 쓰는 것은 운영 환경을 조용히 망가뜨리는 가장 흔한 방식 가운데 하나입니다.

퍼블릭 CA가 상정하는 용도

퍼블릭 CA(DigiCert, Sectigo, Let's Encrypt 등)는 하나의 주요 시나리오, 즉 자사가 통제하지 않는 디바이스와 신뢰를 맺어야 하는 상황을 위해 설계되었습니다. 외부 사용자가 자기 쪽에서 아무것도 구성하지 않아도 자사의 사이트나 서비스를 신뢰할 수 있게 한다는 발상입니다.

퍼블릭 CA가 적합한 경우:

• 자사와 기존 신뢰 관계가 없는 외부 사용자, 고객, 파트너를 위해 공개 서비스를 운영하는 경우
• 외부 API나 서비스가 별도의 클라이언트 구성 없이 자사 인프라에 연결하는 경우
• 인증서 오류가 최종 사용자에게 브라우저 경고로 표시되는 경우
• 이메일에 서명하고 수신자가 사전 구성 없이 서명을 검증해야 하는 경우

퍼블릭 CA가 무엇을 발급할 수 있는지는 CA/Browser Forum이 정합니다. 자사가 통제할 수 없는 규칙을 따라야 하지만, 위와 같은 시나리오에서는 많은 조직에 합리적인 맞교환입니다. 문제가 되는 것은 바로 그 인증서를 내부 인증에 사용할 때입니다.

프라이빗 CA가 상정하는 용도

프라이빗 CA는 자사가 직접 운영하거나 공급업체가 자사를 대신해 운영하는 CA입니다. 발급 정책은 자사가 정합니다. 이 인증서는 기본적으로 어디에서도 신뢰받지 않습니다. 그룹 정책, Intune 또는 MDM 플랫폼을 통해 프라이빗 CA의 루트 인증서를 디바이스와 사용자에게 배포하면, 관리 대상 엔드포인트가 프라이빗 CA가 발급한 인증서를 신뢰하게 됩니다.

자사 인프라만 인증서를 신뢰하면 되는 모든 용도에는 프라이빗 CA가 알맞습니다:

• 디바이스 인증, 즉 특정 컴퓨터가 관리 대상이며 자사 소속임을 증명하는 용도
• 사용자 인증서 인증, 암호 없는 로그인, 스마트카드 대체, 내부 애플리케이션 접근
• Wi-Fi(802.1X) 및 VPN 연결 보호
• 백엔드 마이크로서비스 사이의 상호 TLS(mTLS) 구성
• 내부 도구와 스크립트를 위한 코드 서명

외부 CA 거버넌스에 의존하지 않고 신뢰 체인과 발급 정책을 온전히 통제할 수 있습니다.

퍼블릭 CA와 프라이빗 CA 비교

문제가 생기는 지점

IT 팀이 가장 흔히 저지르는 실수는 내부 인증에 퍼블릭 CA 인증서를 쓰는 것입니다. 퍼블릭 CA는 애초에 내부 워크로드를 위한 것이 아니었고, 지금 진행 중인 두 가지 변화가 그 간극을 더 이상 무시할 수 없게 만들고 있습니다.

1. 퍼블릭 TLS 인증서의 클라이언트 인증 EKU 폐지

공개적으로 신뢰되는 TLS 인증서는 더 이상 클라이언트 인증 EKU를 담을 수 없습니다. CA/Browser Forum의 SC-081 투표와 주요 루트 프로그램 업데이트에 따라, 퍼블릭 CA는 2027년 3월이라는 최종 시한에 앞서 clientAuth를 단계적으로 폐지하고 있습니다. 내부 디바이스 인증이나 사용자 인증이 퍼블릭 인증서에 의존하고 있다면, 다음 갱신 시점부터 그 구성은 더 이상 작동하지 않습니다.

2. 빠르게 짧아지는 유효 기간

퍼블릭 CA는 인증서 유효 기간을 계속 줄이고 있습니다. SC-081v3에 따라 퍼블릭 인증서의 유효 기간 상한은 200일(2026년)로 제한되고, 2027년 3월에는 100일, 2029년 3월에는 47일로 줄어듭니다. 자동화 도구는 공개 웹 서버에서 90일 주기 갱신을 무리 없이 처리하지만, 수천 대의 내부 노트북이나 디바이스를 6주마다 다시 등록하는 일은 관리자에게 악몽입니다.

프라이빗 CA는 이런 제약 밖에 있습니다. 해지를 자사 환경 안에서 직접 처리하므로, 인위적으로 짧은 수명이나 외부 검증 절차가 필요하지 않습니다. 유효 기간과 규칙은 자사 팀에 맞게 직접 정하면 됩니다.

어느 쪽을 쓸지 판단하는 기준

환경의 인증서마다 이렇게 물어보십시오. 이 인증서를 검증해야 하는 모든 디바이스나 클라이언트를 자사가 통제하고 있습니까?

• 그렇다면: 프라이빗 CA를 쓰십시오. 루트 CA 인증서를 배포하고, 무엇이 발급되는지 통제하며, 외부 규칙 변경에 휘둘리지 않게 됩니다.
• 아니라면: 퍼블릭 CA가 필요합니다. 사전 구성 없이 외부에서 연결하는 쪽은 자기 디바이스가 이미 신뢰하는 CA를 필요로 합니다.

대부분의 IT 부서는 결국 둘 다 필요하게 됩니다. 외부 공개 서비스에는 퍼블릭 인증서를, 디바이스와 사용자, 내부 서비스에는 프라이빗 인증서를 쓰는 식입니다.

SCEPman의 역할

SCEPman은 Microsoft Intune 및 Entra ID와 통합되고, SCEP와 EST를 통해 다른 MDM 플랫폼과도 연동되는 클라우드 네이티브 프라이빗 CA입니다. 관리 대상 디바이스와 사용자를 위해 인증서 발급을 자동으로 처리합니다.

Intune 환경에서 SCEPman은 인증서의 유효성을 디바이스 규정 준수 상태와 연결합니다. 초기화되거나 규정 준수를 벗어난 디바이스는 인증서를 잃고, Wi-Fi와 VPN, 내부 애플리케이션 접근이 자동으로 차단됩니다.

SCEPman은 Certificate Master를 이용해 인증서를 수동으로 발급할 수도 있습니다. 덕분에 IT 부서는 웹 포털, 앱, 디바이스 관리 인터페이스 같은 내부 시스템 전반에서 퍼블릭 CA 인증서를 대체할 수 있습니다.

시작하는 방법

프라이빗 CA가 없거나 레거시 온프레미스 Active Directory Certificate Services(ADCS)에서 벗어나려 한다면, SCEPman 상담을 시작하기에 좋은 시점입니다.

SCEPman 직접 체험하기

30일 체험판을 시작해, 직접 PKI를 운영하는 부담 없이 SCEPman이 디바이스와 사용자, 내부 서비스를 위한 프라이빗 CA 인증서를 어떻게 발급하고 관리하는지 확인해 보십시오.

SCEPman 30일 체험판 시작하기

자주 묻는 질문