Architecture and Components
A PKI-as-a-Service deployment begins with understanding the customer's certificate environment and designing a PKI architecture that supports both current and future certificate requirements. EC runs discovery and whiteboarding sessions with the customer's security, infrastructure, networking and application teams to identify certificate use cases, enrollment requirements, trust requirements, security controls and integration points.
Once the architecture is agreed, EC builds and operates the PKI in the EC-hosted environment. The deployment includes the Root CA, one or more Issuing CAs, HSM integration, certificate policies and templates, revocation infrastructure, trust-store integration, certificate lifecycle management, monitoring, and the enrollment gateways that connect the customer environment securely to the hosted PKI.
The PKI is split across two networks. EC operates the CA hierarchy, the HSMs, the self-service portal and revocation publishing on the EC network. The customer keeps DNS, Active Directory, trust stores and, where auto-enrollment is used, the CEP server and Enrollment Gateway in its own network. The CA is never exposed to customer clients.
Deployment activities
-
Download the Client Intake Form and conduct discovery sessions.
Download the Client Intake Form and conduct working sessions with the key stakeholders to gather the PKI configuration details, regulatory requirements, network dependencies, security controls, and expected certificate usage.
Led by: EC with customer
-
Identify certificate use cases.
Determine exactly where certificates will be used across the organization. This may include user authentication, device authentication, servers, IIS, F5, code signing, etc. This step helps define what types of certificates and enrollment methods are required.
Led by: EC with customer
-
Design the Root CA and Issuing CA hierarchy.
Based on the collected requirements, design the PKI architecture. This includes deciding how many Root and Issuing CAs are needed, whether different Issuing CAs are required for different use cases, where the CAs will be hosted and how trust will flow from the Root CA to the end-entity certificates.
Led by: EC
-
Define certificate policies and configurations.
Establish the rules governing certificate issuance. This includes certificate validity periods, RSA/ECC algorithms and key sizes, certificate templates, Extended Key Usages (EKUs), naming conventions, approval requirements, renewal policies, revocation policies and the enrollment mechanisms that will be permitted.
Led by: EC with customer
-
Generate CA private keys inside FIPS 140-3 Level 3 HSMs.
The private keys for the Root CA and Issuing CAs are generated directly inside dedicated Hardware Security Modules. The CA private keys remain protected within the HSM and are not stored as ordinary software-based key files, providing strong protection against key theft or unauthorized use.
Led by: EC
-
Build and configure the PKI infrastructure.
Create and configure the Root CA, Issuing CA(s) and any supporting PKI components required by the architecture. This includes installing the CA services, applying security hardening, configuring HSM integration, setting CA registry parameters and implementing the agreed PKI design.
Led by: EC
-
Configure certificate validation services.
Configure the mechanisms that systems use to validate certificates. This normally includes CRL Distribution Points (CDP), Authority Information Access (AIA), Certificate Revocation Lists (CRLs) and, where required, Online Certificate Status Protocol (OCSP). These services allow devices and applications to verify the certificate chain and determine whether a certificate has been revoked.
Led by: EC
-
Establish enterprise trust.
Provide the Root CA and Issuing CA certificates to the customer so they can be distributed to the appropriate enterprise trust stores. For example, in a Windows environment, these certificates may be deployed through Group Policy so domain-joined devices automatically trust certificates issued by the new PKI.
Led by: Customer, with EC assistance
-
Configure the SaaS certificate management portal.
Set up the customer's self-service certificate management portal. The portal provides authorized users with a centralized interface to request, approve, issue, renew, revoke and track certificates without requiring direct access to the CA infrastructure.
Led by: EC
-
Integrate certificate enrollment methods.
Configure the required enrollment mechanisms depending on the customer's use cases. These may include Windows Auto-Enrollment for domain devices, ACME for automated server and application certificates, SCEP for network devices, Microsoft Intune for managed endpoints, and REST APIs for application or DevOps integrations.
Led by: EC with customer
-
Perform end-to-end testing.
Validate the complete certificate lifecycle before production use. Testing should cover certificate requests, approvals, issuance, installation, authentication, chain validation, renewal and revocation. CRL/AIA accessibility and trust-chain validation should also be tested from representative customer systems.
Led by: Joint
-
Enable monitoring, inventory and reporting.
Configure operational monitoring for the PKI environment. This includes CA health, HSM connectivity, CRL publication, certificate expiration, certificate inventory, failed enrollment activity, dashboards, reports and automated alerts so potential problems can be identified before they affect production services.
Led by: EC
-
Move certificate workflows into production.
Once testing and customer acceptance are complete, the approved certificate workflows are enabled for production systems. Production applications, users, devices and workloads can then begin requesting certificates from the new PKI through the configured enrollment methods.
Led by: Joint
-
Transition to ongoing PKIaaS operations.
After implementation, the environment moves into the managed-service phase. The PKIaaS team handles ongoing CA operations, infrastructure maintenance, monitoring, CRL publication, certificate lifecycle support, incident response, security updates, reporting and other operational activities defined in the service agreement.
Led by: EC