Prerequisites

This page defines the prerequisites that must be in place before Encryption Consulting (EC) begins a PKI-as-a-Service deployment. It sets out the information the customer provides, the decisions that must be approved, and the environment readiness that EC validates before the Root CA and Issuing CA are built. Deployment activities are scheduled only after every item in the readiness checklist at the end of this page is confirmed.

Purpose

The PKIaaS hierarchy is built once and then operated for many years, so decisions such as CA names, key algorithms, validity periods and publication URLs must be agreed before the build starts. Changing them later typically requires a new CA certificate or a re-issue of end-entity certificates. The prerequisites below make sure that these decisions are documented, approved and supported by the customer environment before any key material is generated.

Scope

The following areas are covered by these prerequisites:

The PKI design decisions recorded in the Client Intake Form and approved by the customer.
Customer-side naming, DNS, network and identity requirements for the PKIaaS portal, the CDP and AIA publication points and the integrations.
The trust distribution plan for the EC Root CA and Issuing CA certificates.
The enrollment methods, integrations and pilot scope used to validate the service.

The following areas are outside the scope of this page:

The build, hardening and operation of the EC-hosted Root CA, Issuing CA and datacenter HSM, which EC performs as part of the service.
The prerequisites for the on-premises Certificate Enrollment Gateway, which are described in Gateway Deployment > Prerequisites.

Client Intake Form

The Client Intake Form is the primary input to the deployment. It is available on the Encryption Consulting Resource Hub and records the customer's environment, security requirements, certificate use cases and integration points in one place.

The customer downloads the form, completes it with the PKI, security, networking, Active Directory and application owners, and returns it to the EC engagement lead.
EC reviews the completed form, raises any clarifications, and runs working sessions with the key stakeholders to close open items.
The approved form becomes the configuration baseline for the CA build. Any later change to a recorded value is handled through the agreed change process.

Project Governance and Contacts

Executive sponsor: a named sponsor who approves the PKI design, the Certificate Policy and the go-live decision.
Technical contacts: named owners for PKI, networking, Active Directory and DNS, security, applications and endpoint management, available during the design workshops, the build and testing.
Change windows: the customer's change management process, approval lead times and the maintenance windows in which DNS, firewall, Group Policy and trust changes can be made.
Communication channels: the escalation path, the meeting cadence and the location where deliverables are shared.

PKI Design Decisions

The following values are recorded in the Client Intake Form and approved before the build:

Hierarchy: a two-tier hierarchy with an offline Root CA and one or more online Issuing CAs, and the number of Issuing CAs required (for example, separate CAs for users and devices, or per region).
CA names: the common names and distinguished name suffixes for the Root CA and each Issuing CA.
Cryptography: the key algorithm and key size (for example RSA 4096 for the Root CA and RSA 2048 or ECC P-256 for issued certificates) and the hash algorithm (for example SHA-256).
Validity periods: the lifetime of the Root CA certificate, the Issuing CA certificates and each type of end-entity certificate.
Revocation settings: the CRL and Delta CRL publication intervals, overlap periods and the requirement for OCSP.
Policy information: the certificate policy OIDs and the Certificate Policy and Certification Practice Statement locations.
Approval workflows: which certificate requests are issued automatically and which require approval, and who the approvers are.

Certificate Use Cases and Templates

A list of the systems that will request certificates, such as users, computers, web servers, IIS, F5 and other load balancers, network devices, mobile devices, code signing, APIs and workloads.
For each use case: the subject and SAN format, key usage and extended key usage, validity, key size, whether the private key may be exported, and the enrollment method.
The estimated certificate volume per use case, which is used to size the service and the subscription.
Any certificates that must be migrated or re-issued from an existing PKI.

Naming, DNS and Publication Points

The host names for the PKIaaS portal and the CDP and AIA publication points (for example pki.example.com). These URLs are embedded in every issued certificate and must remain stable for the life of the hierarchy.
The customer-managed DNS records, such as CNAME records that point the agreed host names to the EC publication endpoints, and the owner who creates them.
Confirmation that the CDP and AIA URLs use HTTP and are reachable by every relying party, including systems outside the corporate network where required.

Network Connectivity

Outbound HTTPS (TCP 443) from the customer network to the PKIaaS portal, the EC publication endpoints and, where used, the EC Issuing CA and CLM endpoints. EC provides the exact host names and IP addresses.
HTTP (TCP 80) from all relying parties to the CDP and AIA URLs, so that certificate chains and revocation status can be checked.
Firewall, proxy and TLS inspection rules approved through the customer's change process, including any proxy exceptions required for the EC endpoints.

Identity and Portal Access

The authentication method for the PKIaaS portal: local accounts, Active Directory, or an enterprise Identity Provider using OpenID Connect (OIDC). See Single Sign-On.
Where an Identity Provider is used: the application registration, the claims or groups that map to portal roles, and the multi-factor authentication policy.
The initial list of portal users and the roles assigned to each, following the principle of least privilege.

Trust Distribution Plan

The method used to distribute the Root CA and Issuing CA certificates to domain-joined systems, normally Group Policy or the publication of the certificates in Active Directory.
The method for non-domain systems, such as Intune or Jamf configuration profiles, Linux trust stores, Java keystores, network appliances and application-specific trust stores.
The owner and the target date for each trust distribution path, so that trust is in place before certificates are issued in production.

Enrollment Methods and Integrations

The enrollment methods in use, such as Windows Auto-Enrollment through the Certificate Enrollment Gateway, ACME, SCEP or NDES, Intune, Jamf, CSR-based enrollment through the portal, and the REST API.
For each integration: the system owner, the platform version, the authentication method and the test environment.
Where Windows Auto-Enrollment is required, the Gateway Deployment prerequisites are completed in parallel.

Security and Compliance Requirements

The compliance frameworks the PKI must support, such as NIST, FIPS 140-3, PCI DSS, HIPAA, SOC 2 or ISO 27001, and any evidence the customer requires from EC.
Requirements for the Root CA key ceremony, such as customer witnesses, recorded evidence and sign-off.
Audit log retention, SIEM integration and reporting requirements.
Data residency or regional hosting requirements, if applicable.

Existing PKI Information

When the deployment replaces or runs alongside an existing PKI, the following information is also required:

The current CA hierarchy, CA certificates, CRL locations and certificate templates.
An inventory of the certificates issued by the existing CAs, with their owners and expiry dates.
The applications that depend on the existing CAs, and any hard-coded trust or CRL locations.

Testing and Acceptance

Pilot users, computers, servers, applications or devices for each enrollment method.
The test cases for issuance, renewal, revocation, CRL and OCSP checking, and trust validation.
The acceptance criteria and the person who signs off the deployment before the production rollout.

Responsibilities

Customer: completes and approves the Client Intake Form, provides the named contacts, creates the DNS records, approves the firewall and proxy rules, configures the identity integration on the customer side, distributes trust, and provides the pilot systems.
Encryption Consulting: provides the Client Intake Form and the design workshops, specifies the DNS, network and identity values, builds and operates the Root CA, Issuing CA and HSM, publishes the CDP and AIA, and validates every prerequisite before the build.
Joint: the review of the design, the readiness review and the pilot testing.

Pre-Deployment Readiness Checklist

All items below are confirmed at the readiness review before the build is scheduled:

☐ Client Intake Form completed, reviewed by EC and approved by the customer.
☐ Executive sponsor and technical contacts named, and change windows agreed.
☐ CA hierarchy, CA names, cryptography, validity periods and revocation settings approved.
☐ Certificate use cases and template requirements documented.
☐ Portal, CDP and AIA host names agreed, and DNS records created or scheduled.
☐ Firewall and proxy rules for the EC endpoints approved.
☐ Portal authentication method and initial user roles confirmed.
☐ Trust distribution plan defined for domain-joined and non-domain systems.
☐ Enrollment methods and integrations confirmed, with owners and test environments.
☐ Security, compliance and key ceremony requirements recorded.
☐ Pilot scope, test cases and acceptance criteria agreed.

PKI-as-a-Service