Certification Practice Statement (CPS)

Document ID

A4E-PKI-CPS-001

Version

1.0 — Production Release

Effective Date

2026-05-01

Review Date

2027-05-01

Classification

Public (Internal Network)

Policy Authority

Brian Vicente, Network Coordinator

Implements CP

A4E-PKI-CP-001 v1.0

Hosted At

http://10.0.1.232/pki/docs/cps.html

1. Introduction

1.1 PKI Architecture

The Alliance Multi-Org PKI is a three-tier hierarchy hosted across Hyper-V and XenServer infrastructure:

Note on certificate templates: All certificate templates are managed on PKI-ALLIANCE (not on the Root CA). This is the correct ADCS Enterprise CA architecture.

2. Publication and Repository

All CDP and AIA endpoints are served over HTTP (not HTTPS). This is required per RFC 5280 §4.2.1.13 and CA/B Forum BR to ensure relying parties can perform revocation checks without circular trust dependencies.

3. Identification and Authentication

3.1 Enrollment Authentication Methods

4. Lifecycle Operations

4.1 ADCS Certificate Templates

4.2 Renewal and Re-Key Policy

• AD auto-enrollment renews at 80% of certificate lifetime
• ACME certs renewed at 66% of 90-day lifetime (approximately day 60); cert-manager or step-ca renewal agent handles this automatically
• Forced re-key required on: key compromise, algorithm change (PQC migration), CA re-key, subscriber identity change
• CRL and OCSP checked at renewal; revoked subscriber certs are blocked from renewal

5. Operational Controls

5.1 Root CA Key Ceremony Procedure

1. Power on PKI-ROOT VM via Hyper-V or XenCenter console
2. Verify NIC is disconnected in Device Manager before any signing operation
3. Insert offline USB; copy pending CSR(s) onto PKI-ROOT via USB only
4. Review each CSR: verify subject DN, SAN, extensions, requestor identity in AD, and NameConstraints compliance
5. Sign CSR(s) using ADCS; export signed certificate(s) to USB immediately
6. Publish updated CRL to USB
7. Shut down PKI-ROOT VM; verify NIC remains disconnected
8. Import signed cert(s) and CRL to the-orc endpoints
9. Log ceremony in PKI Operations runbook: date/time, certs signed, serial numbers, SHA-256 thumbprints, operator initials

5.2 Atera RMM Monitoring Policy

• certsvc (Active Directory Certificate Services) service state monitored on all issuing CAs; alert on stop
• CRL file modification date monitored; alert if issuing CA CRL is older than 13 days (1 day before overlap window)
• the-orc HTTP endpoint availability monitored; alert if /pki/CRL/ or /pki/OCSP returns non-200
• PKI-ROOT VM power state monitored; alert if VM starts outside approved maintenance window

6. Technical Security Controls

7. Certificate Profiles and ASN.1 DER Requirements

7.1 End-Entity DER Encoding Checklist

• Version: 02 01 02 (X.509 v3)
• Basic Constraints: MUST be absent or CA=FALSE on all end-entity certificates
• Key Usage: correct DER bitstring; TLS Server RSA = 03 02 05 A0 (digitalSignature + keyEncipherment); TLS Server ECDSA = 03 02 07 80 (digitalSignature only)
• Extended Key Usage: all EKU OIDs explicitly enumerated; no implicit inheritance
• Subject Alternative Name: MUST be present and non-empty for all TLS; contains dNSName or iPAddress only; CN not relied upon for TLS validation
• CDP: HTTP URL only; no LDAP; no trailing slash; must resolve on internal network
• AIA OCSP: HTTP URL (not HTTPS); OCSP responder does not require HTTPS
• AIA CA Issuer: HTTP .crt URL pointing to issuing CA certificate
• Certificate Policies: policy OID + CPS pointer URL (IA5String); no userNotice in production v1.0

7.2 Corrected step-ca TLS Server Template (v1.0)

{
  "subject": {
    "commonName": "{{ .Subject.CommonName }}",
    "organization": "{{ .Insecure.User.org | default "Alliance for Empowerment Inc." }}"
  },
  "sans": {{ toJson .SANs }},
  "keyUsage": ["digitalSignature", "keyEncipherment"],
  "extKeyUsage": ["serverAuth"],
  "basicConstraints": { "isCA": false },
  "extensions": [
    {
      "id": "2.5.29.32",
      "critical": false,
      "value": "{{ .Insecure.User.policyOID | default "1.3.6.1.4.1.65571.2.1" }}"
    }
  ],
  "validity": {
    "notBefore": "{{ now }}",
    "notAfter": "{{ now | date "2006-01-02T15:04:05Z" | addDate 0 0 90 }}"
  }
}

8. Compliance and Audit

8.1 Annual Internal Audit Checklist

• Verify Root CA and all issuing CA certificates are within valid period; flag certs expiring within 24 months
• Verify all CRLs are current; HTTP GET test from each org network segment
• Verify CDP, AIA, OCSP URLs in issued certificates resolve to live, correct content
• Verify step-ca RA instances are running; test ACME challenge flow end-to-end for each org
• Review CA audit logs: Event IDs 4886 (issued), 4887 (declined), 4888 (revoked), 4890 (revocation config changed)
• Run certutil -view -restrict to check for certs issued outside NameConstraints permitted subtrees
• Verify key backup integrity: attempt recovery test of at least one issuing CA key backup annually
• Test browser trust: load internal HTTPS page on Chrome, Edge, Firefox, Safari per org
• Review Atera RMM alert history; confirm no unresolved certsvc or CRL publish alerts
• Review and update CP/CPS; increment version and effective date if material changes made

8.2 Compliance Matrix

9. Business and Legal Matters

• Governing organization: Alliance for Empowerment Inc., Pine City, New York 14871
• Policy administrator: Brian Vicente, Network Coordinator — pki-admin@wearealliance.org
• Subscriber obligations: Protect private keys; report compromise within 24 hours to pki-admin@wearealliance.org; use certificates only for authorized purposes within NameConstraints subtrees
• Relying party obligations: Validate full certificate chain including CRL or OCSP status check before trusting any certificate issued under this CPS
• Privacy: Subject DN and SAN data limited to operational minimum; no data shared externally; retention per organizational policy
• CA termination: Minimum 90-day advance notice to all subscribers; final CRL with extended NextUpdate published; key destruction ceremony documented in runbook
• Domains in scope: wearealliance.org, o365.wearealliance.org, alliance.internal, able2.internal, able-2.org, capabilities.internal, capabilities.org
• Domains excluded: AllianceforEmpowerment1118.onmicrosoft.com and all *.onmicrosoft.com subdomains (Microsoft-managed; not under PKI organizational control per RFC 5280 §4.2.1.10)

10. step-ca RA Integration

10.1 Provisioner Configuration

10.2 Policy Engine Rules (ca.json excerpt)

"policy": {
  "x509": {
    "allow": {
      "dns": [
        "*.alliance.internal", "*.wearealliance.org",
        "*.o365.wearealliance.org",
        "*.able2.internal", "*.able-2.org",
        "*.capabilities.internal", "*.capabilities.org"
      ],
      "email": [
        "@wearealliance.org",
        "@able-2.org",
        "@capabilities.org"
      ]
    },
    "deny": {
      "dns": ["*.onmicrosoft.com", "*.mail.onmicrosoft.com"],
      "ip": ["0.0.0.0/0"]
    },
    "allowWildcardNames": false
  }
}

10.3 RA Database and Backup

• step-ca database: /etc/step-ca/db/ (Badger v2) on each step-ca host
• Nightly encrypted backup to the-orc: /backup/step-ca/[org]/
• RA certificate (authorizes step-ca to submit to ADCS) renewed 30 days before expiry via scheduled task on each step-ca host
• step-ca logs forwarded to Watchguard SIEM (syslog UDP/514) for security event correlation with Atera RMM

11. Post-Quantum Cryptographic Procedures

11.1 Phase Activation Gate Criteria

• Phase 2 Hybrid gate: Windows Server / ADCS PQC support generally available; step-ca PQC provisioner stable release; successful lab validation on non-production PKI for minimum 30 days
• Phase 3 PQC Primary gate: Chrome + Firefox + Edge native PQC TLS in GA release; FIPS 140-3 HSM available with ML-DSA-65 support; Phase 2 hybrid in production for minimum 6 months
• Phase 3 IoT gate: SP 800-232 (Ascon) implementation support in target embedded/IoT platforms confirmed by vendor
• Phase 4 RSA Sunset gate: NIST SP 800-131A published deprecation timeline; all active subscribers confirmed migrated to PQC or hybrid

12. Browser Trust Deployment

12.1 Windows (Chrome / Edge) — GPO Deployment

# Step 1: Publish root CA to AD certificate stores
certutil -dspublish -f Alliance-Root-CA.crt RootCA
certutil -dspublish -f Alliance-Root-CA.crt NTAuthCA

# Step 2: Verify AD publication
certutil -viewdelstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration"

# Step 3: GPO configuration
# Path: Computer Config > Windows Settings > Security Settings
#       > Public Key Policies > Trusted Root Certification Authorities
# Import: Alliance-Root-CA.crt
# Apply GPO to: Domain Computers OU

12.2 Firefox — Enterprise Policy Deployment

# Method 1: Windows GPO Registry Key
# HKLM\SOFTWARE\Policies\Mozilla\Firefox
# Value: "security.enterprise_roots.enabled" = 1 (REG_DWORD)
# This causes Firefox to read from the Windows Certificate Store

# Method 2: policies.json (Linux / macOS / Docker)
# /etc/firefox/policies/policies.json
{
  "policies": {
    "Certificates": {
      "Install": ["/etc/ssl/certs/alliance-root-ca.crt"],
      "ImportEnterpriseRoots": true
    },
    "SecurityDevices": {
      "Add": {}
    }
  }
}

12.3 Intune — iOS / Android / macOS Trust

• Create Intune Trusted Certificate configuration profile
• Upload Alliance-Root-CA.crt; destination store: Computer Certificate Store — Root
• Assign profile to: All Devices (or org-specific device group)
• macOS: also push via MDM PKCS profile to System Keychain
• iOS: trust prompt shown once; user must tap “Trust” in Settings > General > About > Certificate Trust Settings

12.4 Browser Compatibility Matrix