Platform SDK Redistributable: CAPICOM — Complete Installation Guide

Migrating from CAPICOM: Alternatives to Platform SDK Redistributable

Overview

CAPICOM is an older Microsoft COM-based library for cryptographic operations (certificates, signing, encryption). It’s deprecated and unsupported on modern Windows versions. Migrating away improves security, compatibility, and maintainability.

Key alternatives

• .NET’s System.Security.Cryptography

  • Best for managed applications on Windows and cross-platform when using .NET Core/.NET 6+.
  • Provides APIs for X.509 certificates, hashing, symmetric/asymmetric encryption, and digital signatures.
  • Use X509Certificate2, RSACng/ RSA, ECDsa, Aes, and Cms/PKCS#7 support via System.Security.Cryptography.Pkcs (Windows-only for some features).

• Windows CNG (Cryptography API: Next Generation)

  • Native Windows API replacing CryptoAPI; C/C++ oriented.
  • Use for low-level, high-performance native code: NCrypt, BCrypt, and key storage in KSPs.
  • Supported features: certificate stores, signing, encryption, key management.

• BCrypt / OpenSSL

  • OpenSSL: Cross-platform C library with extensive crypto primitives and PKCS#7, PKCS#12 support. Good if portability to Linux/macOS is required.
  • libsodium: Higher-level modern primitives for encryption/authentication; not a direct replacement for certificate-based features.

• Windows Certificate APIs (CertEnroll, X509Enrollment)

  • COM-based but newer than CAPICOM; useful for certificate enrollment and management.
  • Good for apps that need enrollment workflows with AD CS.

• Microsoft.IdentityModel / System.IdentityModel

  • For token-based scenarios (SAML, JWT, WS-Trust), signing and validation in identity solutions.

• P/Invoke to native Windows APIs

  • For migration from COM to native calls without managed wrappers when specific low-level features are required.

Migration considerations

• Feature mapping: List every CAPICOM feature you use (certificate store, signing, verification, encryption, PKCS#7, timestamping) and map to equivalent APIs (e.g., CAPICOM.SignedData → System.Security.Cryptography.Pkcs.SignedCms).
• Language/platform: Prefer System.Security.Cryptography for .NET apps; CNG or OpenSSL for native or cross-platform needs.
• Certificate stores & key access: Ensure keys (CSP vs CNG key storage providers) are accessible; convert or re-provision keys if needed.
• Interop: Replace CAPICOM COM references; rework code to use classes like X509Certificate2, RSACng, ECDsa, SignedCms.
• Security: Move to modern algorithms (RSA 2048+/RSA-PSS, ECDSA, AES-GCM), avoid deprecated hashes (MD5, SHA1).
• Testing & compatibility: Validate signed data, certificates, PKCS#7 structures, and timestamping against existing consumers.
• Deployment: Remove CAPICOM redistributables; ensure required runtime libraries (e.g., .NET version) are installed.

Quick code mappings (examples)

• CAPICOM SignedData (signing PKCS#7) → .NET SignedCms (System.Security.Cryptography.Pkcs.SignedCms)
• CAPICOM Certificate store access → X509Store / X509Certificate2Collection
• CAPICOM EnvelopedData (encryption) → EnvelopedCms
• CAPICOM private-key operations → RSACng / RSA.Create(), ECDsa.Create()

Recommended path (common scenarios)

• For modern .NET apps: Migrate to System.Security.Cryptography (SignedCms, EnvelopedCms, X509Certificate2).
• For native Windows apps: Use CNG (NCrypt/BCrypt) and CertEnroll for enrollment tasks.
• For cross-platform native apps: Use OpenSSL or platform-agnostic libraries; wrap certificate handling carefully.

Checklist for migration

1. Inventory CAPICOM features used.
2. Choose target API based on language and platform.
3. Prototype core operations (sign, verify, encrypt, decrypt).
4. Update key storage/access patterns.
5. Replace COM references and refactor code.
6. Update cryptographic algorithms to current standards.
7. Run compatibility tests with existing systems.
8. Remove CAPICOM redistributable and update deployment.