MSIX용 자체 서명 코드 서명 인증서: 실용 가이드
2026-06-02
Tags: Windows · Microsoft Store · MSIX · 스토어 함정
이전 글에서는 MSIX 제출 전 전체 테스트 워크플로를 살펴보았습니다. 그 과정에서 자체 서명 인증서 처리(신뢰할 수 있는 사용자(Trusted People) 저장소에 설치, 올바른 인증서로 패키징 등)가 반복적으로 등장했지만, 중요한 질문 하나를 넘어갔었습니다: 실제로 어떻게 만드나요?
이 가이드는 MSIX 패키징을 위한 자체 서명 코드 서명 인증서에 대해 알아야 할 모든 것 — 생성, 내보내기, Visual Studio에서 사용, 팀 내 관리 — 을 다룹니다.
MSIX에 서명이 필요한 이유
MSIX 패키지는 설치되기 전에 반드시 디지털 서명되어야 합니다. 이는 선택 사항이 아닙니다 — 사이드로딩 및 로컬 테스트의 경우에도 운영 체제는 모든 .msix 파일에 유효한 서명을 요구합니다.
스토어 배포의 경우, Microsoft가 인증 후 자체 인증서로 패키지에 서명합니다. 하지만 로컬 테스트 및 사이드로딩의 경우, 여러분만의 인증서가 필요합니다. 자체 서명 인증서가 필요한 이유가 바로 여기에 있습니다: 상업용 코드 서명 인증서를 구매하지 않고도 개발 및 테스트용 패키지에 서명할 수 있습니다.
서명 프로세스는 두 가지 목적을 제공합니다:
- 무결성: 서명 후 패키지가 변조되지 않았음을 보장합니다
- 신원: 게시자(여러분)를 식별합니다 — 인증서의 CN(Common Name)이
Package.appxmanifest의<Publisher>값과 일치해야 합니다
New-SelfSignedCertificate 사용하기
Windows에는 테스트 목적으로 인증서를 생성할 수 있는 New-SelfSignedCertificate PowerShell cmdlet이 포함되어 있습니다. 관리자 권한으로 PowerShell을 열고 다음을 실행해 보세요:
New-SelfSignedCertificate -Type Custom -Subject "CN=YourCompany" -KeyUsage DigitalSignature -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") -CertStoreLocation "Cert:\CurrentUser\My"각 매개변수를 설명하면:
| 매개변수 | 설명 |
|---|---|
-Type Custom | 기본 인증서가 아닌 사용자 지정 인증서 생성 |
-Subject "CN=YourCompany" | Common Name 설정 — 앱의 Package.appxmanifest에 있는 Publisher와 일치해야 함 |
-KeyUsage DigitalSignature | 디지털 서명 용도로 인증서 지정 |
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") | 확장 키 사용을 코드 서명(Code Signing, 1.3.6.1.5.5.7.3.3)으로 설정하고, 기본 제약 조건을 최종 엔터티(End Entity, 2.5.29.19)로 설정 — Windows 배포 엔진이 앱 패키지에 요구하는 사항 |
-CertStoreLocation "Cert:\CurrentUser\My" | 현재 사용자의 개인 저장소에 인증서 저장 |
두 TextExtension 값이 모두 없으면 인증서가 완전히 인식되지 않을 수 있습니다 — Basic Constraints OID는 인증서를 최종 엔터티(CA가 아님)로 표시하며, Windows 배포 엔진이 MSIX 패키지를 확인할 때 이를 검사합니다. 이 값이 없으면 특정 Windows 빌드에서 배포 오류나 WACK 경고가 발생할 수 있습니다.
주: 제 프로젝트에서는 Basic Constraints 없이 자체 서명 인증서를 사용해도 문제없이 작동했습니다. 이 제약은 Microsoft의 권장 모범 사례이지만, 개발 및 사이드로딩 시나리오에서는 엄격히 필요하지 않습니다.
코드 서명 EKU가 있는 인증서 생성
이미 코드 서명 EKU 없이 인증서를 만든 경우, 올바른 속성이 있는지 확인할 수 있습니다. 인증서를 열어(certlm.msc 통해) 세부 정보 → 확장 키 사용을 확인하면 **코드 서명(Code Signing)**이 나열되어 있어야 합니다.
다음은 MSIX 용도에 맞게 인증서를 생성하고 준비하는 실용적인 스크립트입니다:
# 자체 서명 코드 서명 인증서 생성 (코드 서명 EKU + 기본 제약 조건)
$cert = New-SelfSignedCertificate -Type Custom -Subject "CN=YourCompany" -KeyUsage DigitalSignature -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") -CertStoreLocation "Cert:\CurrentUser\My"
# 인증서 세부 정보 표시
$cert | Format-List Subject, Thumbprint, NotAfter
# 쉽게 참조할 수 있도록 지문 출력
Write-Host "Certificate thumbprint: $($cert.Thumbprint)""CN=YourCompany"를 실제 게시자 이름으로 바꾸세요. 게시자 이름은 Package.appxmanifest의 Identity 요소에서 찾을 수 있습니다:
<Identity Name="YourApp" Publisher="CN=YourCompany" Version="1.0.0.0" />PFX와 CER 내보내기
인증서를 생성한 후에는 일반적으로 두 가지 유형의 파일이 필요합니다:
PFX (Personal Information Exchange)
개인 키 + 인증서를 포함합니다. Visual Studio에서 패키지 서명에 사용하는 파일입니다. 비밀번호처럼 취급하세요 — PFX에 접근할 수 있는 사람은 누구나 여러분으로 패키지에 서명할 수 있습니다.
$password = ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "codesign.pfx" -Password $passwordCER (Certificate file)
공용 인증서만 포함합니다(개인 키 없음). 서명된 패키지를 신뢰할 수 있도록 테스트 머신에 배포하는 파일입니다.
Export-Certificate -Cert $cert -FilePath "codesign.cer"빠른 참조
| 형식 | 개인 키 포함? | 용도 |
|---|---|---|
.pfx | 예 | 패키지 서명 (Visual Studio, signtool) |
.cer | 아니오 | 테스트 머신에 설치하여 신뢰 설정 |
인증서 가져오기 및 지문 확인
자체 서명 인증서로 서명된 MSIX 패키지를 테스트 머신에 설치하려면, 해당 인증서가 시스템에서 신뢰되어야 합니다.
인증서 설치
.cer파일 더블클릭 → Install Certificate- Local Machine 선택 → Browse → 신뢰할 수 있는 사용자(Trusted People) 선택
- 마법사 완료
PowerShell로도 가능합니다:
Import-Certificate -FilePath "codesign.cer" -CertStoreLocation "Cert:\LocalMachine\TrustedPeople"지문 찾기
명령줄 서명 도구를 사용할 때 지문이 필요합니다:
# 개인 인증서 저장소의 모든 코드 서명 인증서 나열
Get-ChildItem -Path "Cert:\CurrentUser\My" -CodeSigningCert | Format-Table Subject, Thumbprint, NotAfter지문은 40자 16진수 문자열입니다. 정확히 복사하세요 — 서명 명령에 필요합니다.
Visual Studio에서 인증서 사용
PFX 파일이 있으면 Visual Studio의 패키징 마법사에서 사용할 수 있습니다:
- 프로젝트 우클릭 → Package and Publish → 새 패키징 프로필 생성
- Select Signing Certificate 단계에서 Select from File... 클릭
.pfx파일을 찾아 비밀번호 입력- 패키징 마법사 완료
인증서는 패키징 프로필에 저장되므로 매번 다시 선택할 필요가 없습니다. 하지만 인증서가 만료되거나 새 인증서로 교체할 경우 프로필을 업데이트해야 합니다.
인증서 저장소에서 인증서 사용
PFX를 개인 인증서 저장소에 가져온 경우, 직접 선택할 수도 있습니다:
- 서명 단계에서 "Select from File..." 대신 드롭다운을 펼칩니다
- 목록에서 인증서를 찾습니다(지정한 CN으로 식별)
- 선택하고 진행합니다
이 방법은 편리하지만 주의하세요 — Visual Studio가 특정 지문을 캐시할 수 있으며, 인증서가 갱신(새 키 쌍)되면 저장된 참조가 유효하지 않을 수 있습니다.
인증서 만료, 갱신 및 재서명
New-SelfSignedCertificate로 생성된 자체 서명 인증서는 기본적으로 1년의 유효 기간을 가집니다(일부 버전은 기본 3년 — NotAfter 속성 확인).
체크리스트
- [ ] 인증서 만료일 기록
- [ ] 만료 전에 새 인증서를 만들고 모든 패키지 재서명
- [ ] 새
.cer을 테스트 머신에 배포 - [ ] Visual Studio의 패키징 프로필 업데이트
- [ ] 스토어 제출용 새 Test 패키지를 새 인증서로 생성
만료 확인:
Get-ChildItem -Path "Cert:\CurrentUser\My" -CodeSigningCert | Format-Table Subject, NotAfter갱신할 때는 동일한 CN으로 새 인증서를 만들고, 새 PFX/CER을 내보낸 후 패키지를 재서명하세요. 지문은 변경되므로 모든 참조가 업데이트되었는지 확인하세요.
팀 개발을 위한 팁
여러 개발자가 동일한 인증서로 패키지에 서명해야 하는 경우:
- PFX를 안전한 공유 위치에 보관 — 팀 스토리지의 비밀번호 보호 아카이브나 파일 첨부를 지원하는 비밀번호 관리자 사용
- PFX를 소스 제어에 절대 커밋하지 않음 —
.gitignore에*.pfx추가 - 비밀번호를 팀 비밀번호 관리자에 문서화 — 코드나 문서에 기록하지 않음
- 각 개발자가 PFX를 개인 인증서 저장소에 가져온 후 Visual Studio에서 선택
- 모든 인증서에 동일한 CN 사용 — 개발자별 인증서가 필요한 경우에도(배포용이 아닌 빌드)
CI/CD 파이프라인의 경우, 대부분의 빌드 에이전트는 보안 환경 변수나 시크릿을 통해 PFX 가져오기를 지원합니다 — 권장 방식을 확인하려면 CI 플랫폼의 문서를 참조하세요.
이 글은 스토어 함정 시리즈의 보충 읽을거리입니다.