참고 자료

본 페이지는 sslTrus 원격 코드 서명 서비스가 다양한 통합 방식에서 공통으로 사용하는 참고 정보를 정리합니다. 내용은 다음과 같습니다.

• 코드 서명 횟수 계산 규칙.
• Authenticode 및 RFC 3161 타임스탬프 프로토콜.
• 자주 사용하는 코드 서명 타임스탬프 서버.
• 운영 환경에서 타임스탬프 서비스를 선택할 때 주의할 사항.

서명 횟수 계산

서명 횟수는 실제로 완료된 서명 동작을 기준으로 계산합니다.

간단히 이해하면:

一个文件成功完成一次签名 = 一次签名次数

서명 횟수는 소스 코드 파일 수를 기준으로 계산되지 않으며, 한 번의 빌드, 한 번의 패키징 또는 한 번의 CI/CD 파이프라인을 기준으로 계산되지도 않습니다.

예:

100 个源代码文件
        ↓
编译生成 1 个 app.exe
        ↓
app.exe 成功签名一次
        ↓
1 次签名

한 번의 빌드로 다음이 생성되는 경우:

app.exe
helper.dll
installer.msi

세 파일이 각각 서명을 완료하면:

签名次数 = 3 次

기본 규칙

서명 횟수는 주로 다음 사항을 기준으로 합니다.

1. 최종적으로 서명된 파일 또는 객체가 무엇인지.
2. 각 객체에 대해 실제로 완료된 서명 횟수.
3. 일반 클라이언트 서명인지, KSP, Jarsigner 등 하위 레벨 서명 호출 방식인지.
4. 빌드 도구가 추가 EXE, DLL, 제거 프로그램 또는 설치 패키지를 자동으로 서명했는지 여부.

일반적인 서명 객체에는 다음이 포함됩니다.

• .exe
• .dll
• .msi
• .msp
• .sys
• .cat
• .jar
• 제거 프로그램, 예: uninstall.exe

어떤 객체든 실제로 서명이 한 번 성공적으로 완료되면 해당 횟수 계산 규칙에 따라 계산됩니다.

성공한 경우에만 횟수로 계산

원격 코드 서명 서비스가 서명을 성공적으로 완료한 경우에만 서명 횟수가 발생합니다.

다음 상황은 일반적으로 횟수로 계산되지 않습니다.

• 인증 실패.
• 매개변수 오류.
• 인증서 사용 불가.
• 네트워크 요청 실패.
• 서버가 서명 결과를 성공적으로 반환하지 못함.
• 인증서 조회.
• 서명 기록 조회.
• 서명 검증.
• 기존 서명 제거.
• 검증 파일 생성.

원격 서비스가 이미 서명 결과를 성공적으로 반환했지만, 이후 클라이언트가 로컬에서 파일을 쓰거나 타임스탬프를 추가하거나 후속 처리를 수행하는 과정에서 실패한 경우, 이미 완료된 원격 서명은 여전히 성공한 서명으로 계산됩니다.

타임스탬프는 별도로 횟수로 계산되지 않음

타임스탬프는 서명이 특정 시점에 이미 존재했음을 증명하는 용도로, 새로운 코드 서명 작업에 해당하지 않습니다.

따라서:

코드 서명       → 서명 횟수 발생
타임스탬프 추가     → 서명 횟수 추가 발생 없음
서명 검증       → 서명 횟수 발생 없음

타임스탬프 서비스 성공 여부는 최종 서명 파일의 타임스탬프 결과에만 영향을 미치며, 코드 서명이 한 번 더 수행되었음을 의미하지는 않습니다.

SignTool CLI

sslTrus SignTool CLI 사용:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe

서명이 성공한 경우:

1 个文件 × 1 次成功签名 = 1 次

예를 들어:

signtool sign --cert-code CERT_CODE --file app.exe
signtool sign --cert-code CERT_CODE --file helper.dll
signtool sign --cert-code CERT_CODE --file installer.msi

세 파일이 모두 성공했습니다:

合计 = 3 次

SignTool CLI 이중 서명

일반 SignTool CLI를 사용하여 SHA-1과 SHA-2를 동시에 활성화하는 경우:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe \
  --sha1=true \
  --sha2=true

일반 CLI 이중 서명은 하나의 클라이언트 서명 작업으로 계산됩니다:

GUI / SignTool CLI 双签 = 1 次

이것은 일반 클라이언트 서명 흐름과 KSP 하위 수준 서명 호출이 가장 혼동되기 쉬운 지점입니다.

Windows KSP

KSP는 Windows CNG Provider 통합 방식입니다.

Microsoft SignTool, MSBuild, Visual Studio, Electron 패키징 도구 또는 기타 Windows 소프트웨어가 KSP를 통해 원격 코드 서명을 호출할 때, 횟수 계산은 다음에 더 가깝습니다:

底层远程私钥签名调用次数

예를 들어:

작업	서명 횟수
app.exe에 대해 SHA256 서명을 1회 수행	1회
SHA256을 먼저 수행한 후 SHA1을 추가	2회
app.exe, helper.dll, uninstall.exe를 각각 서명	3회

따라서:

SignTool CLI 双签 = 1 次
KSP 双签          = 2 次

如果 도구가 동일한 파일에 대해 여러 번의 하위 서명 작업을 수행하는 경우, 성공한 각 원격 서명은 각각 계산됩니다.

CSP

CSP는 기존 Windows CryptoAPI Provider입니다.

CSP 역시 Microsoft SignTool 또는 다른 Windows 애플리케이션에서 Provider를 통해 원격 서명 서비스를 호출합니다.

서명 횟수를 판단할 때는 실제 발생한 원격 개인 키 서명 작업을 기준으로 해야 합니다.

도구가 여러 파일에 대해 각각 또는 동일한 파일에 대해 여러 번 서명하는 경우 각각 계산해야 합니다.

Jarsigner

sslTrusJarsigner Provider를 사용할 때 표준 jarsigner는 서명 과정에서 원격 코드 서명 서비스를 호출합니다.

일반적으로:

작업	서명 횟수
app.jar 서명	1회
3개의 JAR 각각 서명	3회
동일한 JAR에 다시 한 번 서명	1회 추가
jarsigner -verify	0회
검증용 keystore 생성	0회

따라서:

每个 JAR 每次成功完成签名 = 1 次

설치 패키지

설치 패키지는 다음을 구분해야 합니다.

1. 설치 패키지 내부의 실행 파일.
2. 설치 패키지 자체.

예:

app.exe       → 서명 1회
installer.msi → 서명 1회

그러면:

合计 = 2 次

다른 파일이 있는 경우:

파일	서명 여부	서명 횟수
app.exe	예	1
helper.dll	예	1
driver.sys	예	1
installer.msi	예	1
합계		4

설치 패키지에 포함된 소스 코드, 리소스 파일, 이미지 또는 구성 파일의 수는 서명 횟수에 직접적인 영향을 주지 않습니다.

핵심은:

最终到底有哪些产物被实际签名

Electron

Electron Builder, Electron Forge 등 데스크톱 애플리케이션 빌드 도구는 한 번의 패키징 과정에서 여러 파일에 자동으로 서명할 수 있습니다.

일반적인 대상은 다음과 같습니다.

• 메인 프로그램 .exe
• DLL
• 업데이트 프로그램
• 제거 프로그램
• 설치 패키지 .exe
• MSI
• 기타 보조 실행 파일

예:

산출물	서명 횟수
MyApp.exe	1
ffmpeg.dll	1
update.exe	1
uninstall.exe	1
MyApp Setup.exe	1
합계	5

따라서:

一次 Electron Build ≠ 一次签名

실제 서명된 산출물 수와 산출물별 실행된 서명 횟수를 기준으로 계산해야 합니다.

Electron이 KSP를 사용하고 동일한 파일에 대해 이중 서명을 수행하는 경우, 해당 파일에서 원격 서명이 두 번 발생할 수도 있습니다.

빠른 판단

한 번의 빌드에서 서명 횟수가 얼마나 발생할지 알 수 없는 경우, 다음을 순서대로 확인할 수 있습니다.

1. 最终有哪些文件被签名？
2. 每个文件签了几次？
3. 使用的是 SignTool CLI 还是 KSP / Jarsigner？
4. 构建工具有没有自动签额外文件？

다음과 같이 간단히 이해할 수 있습니다.

签名次数 = 成功完成的签名动作数量之和

특별 주의:

GUI / SignTool CLI 双签                = 1 次
KSP 对同一个文件执行两次底层签名       = 2 次
Jarsigner 每个 JAR 每次成功签名         = 1 次
时间戳                               = 0 次
验证签名                             = 0 次

타임스탬프 서버

코드 서명에는 일반적으로 타임스탬프 서비스가 함께 사용됩니다.

타임스탬프는 디지털 서명이 특정 시점에 이미 존재했음을 증명할 수 있으며, 이를 통해 검증자가 서명 인증서, 타임스탬프 인증서, 폐기 상태 및 검증 정책을 결합하여 서명의 유효성을 판단할 수 있습니다.

코드 서명에는 일반적으로 두 가지 타임스탬프 프로토콜이 사용됩니다.

프로토콜	설명
Authenticode	Microsoft의 전통적인 타임스탬프 프로토콜로, 주로 레거시 Windows 코드 서명 프로세스와의 호환성을 위해 사용됩니다
RFC 3161	범용 타임스탬프 프로토콜로, 현대적인 코드 서명 시나리오에 적합합니다

현대적인 코드 서명 시나리오에서는 일반적으로 RFC 3161이 우선적으로 사용됩니다.

RFC 3161

RFC 3161 타임스탬프 요청은 원본 파일이 아닌, 타임스탬프 처리할 데이터의 다이제스트를 전송합니다.

기본 흐름:

代码签名
   ↓
计算待时间戳数据摘要
   ↓
发送摘要到 TSA
   ↓
TSA 返回时间戳令牌
   ↓
写入最终签名

타임스탬프 토큰에는 일반적으로 다음이 포함됩니다.

• 데이터 다이제스트.
• 타임스탬프 발급 시간.
• TSA 정책.
• TSA 디지털 서명.

타임스탬프 서버는 타임스탬프 추가로 인해 sslTrus 코드 서명 횟수를 추가로 소모하지 않습니다.

일반적인 타임스탬프 서버

다음 엔드포인트는 일반적인 코드 서명 시나리오에 적용됩니다.

프로덕션에 사용하기 전에 해당 공급자의 최신 공식 문서, 서비스 정책 및 가용성을 다시 확인해야 합니다.

Microsoft

http://timestamp.acs.microsoft.com

주로 RFC 3161 타임스탬프에 사용됩니다.

Windows 최신 코드 서명 시나리오에서 타임스탬프 후보로 적합합니다.

예시:

--timestamp-rfc3161=http://timestamp.acs.microsoft.com

Microsoft SignTool:

/tr http://timestamp.acs.microsoft.com
/td SHA256

Sectigo

http://timestamp.sectigo.com

지원:

• Authenticode
• RFC 3161

Windows 및 해당 프로토콜을 지원하는 기타 코드 서명 도구에서 사용할 수 있습니다.

Sectigo는 대량 호출에 대해 서비스 측 사용 요구 사항이 있으며, 운영 시스템은 현재 공식 정책에 따라 호출 빈도를 제어해야 합니다.

DigiCert

http://timestamp.digicert.com

RFC 3161을 지원하며, Microsoft Authenticode 등 코드 서명 시나리오에 사용할 수 있습니다.

Certum

http://time.certum.pl

지원:

• Authenticode
• RFC 3161

Certum 공식 코드 서명 자료는 Windows 및 Java JAR 서명 시나리오를 다룹니다.

GlobalSign

http://timestamp.globalsign.com/tsa/r45standard

현재 GlobalSign 코드 서명 자료는 해당 RFC 3161 타임스탬프 주소를 사용합니다.

더 이상 현재 공식 코드 서명 문서에 없는 기존 GlobalSign 주소는 계속 사용하지 않는 것이 좋습니다.

SSL.com

http://ts.ssl.com

RFC 3161을 지원하며, 기존 Authenticode 타임스탬프 프로토콜은 지원하지 않습니다.

대상 서명 도구나 구형 시스템에서 TSA가 사용하는 키 알고리즘에 대한 호환성 제한이 있는 경우, 프로덕션 연동 전에 실제 검증을 수행해야 합니다.

타임스탬프 서버 비교

제공업체	주소	Authenticode	RFC 3161
Microsoft	http://timestamp.acs.microsoft.com	확인되지 않음	지원
Sectigo	http://timestamp.sectigo.com	지원	지원
DigiCert	http://timestamp.digicert.com	확인되지 않음	지원
Certum	http://time.certum.pl	지원	지원
GlobalSign	http://timestamp.globalsign.com/tsa/r45standard	확인되지 않음	지원
SSL.com	http://ts.ssl.com	지원하지 않음	지원

표의 "지원"은 해당 제공업체의 공개 자료에서 확인된 프로토콜 능력을 의미합니다.

타임스탬프 서비스 정책은 변경될 수 있으므로, 프로덕션 구성 전에 제공업체의 현재 공식 자료를 다시 확인해야 합니다.

제한된 타임스탬프 서비스

일부 타임스탬프 서버는 RFC 3161 서비스를 제공하지만, 익명 공개 TSA로 직접 사용할 수는 없습니다.

QuoVadis

공개 RFC 3161 주소는 다음과 같습니다:

http://ts.quovadisglobal.com/eu
http://ts.quovadisglobal.com/ch

해당 서비스는 호출자 송신 IP를 사전에 등록해야 하므로 연동 전에 해당 권한 부여를 완료해야 합니다.

Apple

http://timestamp.apple.com/ts01

Apple 코드 서명 에코시스템에서 사용하는 타임스탬프 서비스입니다.

이를 Windows Authenticode의 범용 타임스탬프 서버로 직접 사용해서는 안 됩니다.

테스트형 타임스탬프 서비스

일부 공개 RFC 3161 서비스는 프로덕션 코드 서명 TSA로 직접 사용하기보다는 프로토콜 테스트에 더 적합합니다.

예:

https://freetsa.org/tsr

이러한 서비스는 자체 CA 및 TSA 인증서를 사용할 수 있습니다.

따라서 다음과 같이 가정할 수 없습니다:

Windows
macOS
Java
其他代码签名验证器

기본적으로 해당 인증서 체인을 모두 신뢰합니다.

프로덕션 환경에서는 대상 플랫폼에서 실제 서명 산출물을 검증해야 합니다.

프로덕션 환경 점검

타임스탬프 서버를 프로덕션 구성에 추가하기 전에 최소한 다음 사항을 확인하는 것이 좋습니다.

1. 서비스 제공업체의 공식 자료에 해당 엔드포인트가 명시적으로 공개되어 있습니다.
2. 서비스 제공업체가 필요한 타임스탬프 프로토콜을 명시적으로 지원합니다.
3. SHA-256 이상의 타임스탬프 다이제스트 알고리즘을 사용합니다.
4. 대상 시스템이 TSA의 전체 인증서 체인을 검증할 수 있습니다.
5. DNS, 프록시, 방화벽 및 송신 네트워크에서 TSA에 안정적으로 접근할 수 있습니다.
6. 인증 방식, 속도 제한, 지역 제한 및 서비스 약관을 확인했습니다.
7. 실제 서명 산출물로 서명 검증 테스트를 완료했습니다.

다음 사항만으로 판단하지 마십시오.

浏览器可以打开
HTTP 返回 200

타임스탬프 서버가 코드 서명에 적합한지 판단합니다.

반드시 실제 서명 도구를 사용하여 타임스탬프 요청을 보내고, 최종 산출물에 대해 검증을 수행해야 합니다.

타임스탬프 선택 권장 사항

최신 Windows SHA-2 코드 서명의 경우, 일반적으로 RFC 3161을 지원하는 타임스탬프 서비스를 우선적으로 선택합니다.

예:

Microsoft
Sectigo
DigiCert
Certum
GlobalSign

최종 선택 시 다음 사항을 종합적으로 고려해야 합니다.

• 대상 운영 체제.
• 서명 도구.
• TSA 인증서 체인.
• 네트워크 접근성.
• 지역 제한.
• 호출 빈도 제한.
• 서비스 약관.
• 서비스 수준 계약.
• 실제 서명 산출물 검증 결과.

인증서 제공자가 타임스탬프 서비스에 대해 명시적 요구 사항이 있다면 해당 인증서 정책과 서비스 제공자 요구 사항을 우선적으로 따라야 합니다.

관련 통합 방식

통합 방식에 따라 이 페이지의 서명 횟수와 타임스탬프 규칙을 사용합니다.

사용 시나리오	문서
SignTool CLI	클라이언트 도구
Windows KSP / CSP	Windows Provider
Jarsigner	Java 통합
GitHub Actions, Electron Builder, Advanced Installer	CI/CD 및 빌드 도구
원격 서명 인터페이스 직접 호출	API 통합