SSL’s Trust Infrastructure portfolio enables organizations of all sizes to take ownership of their trust foundation. Whether you need a fully dedicated private CA hierarchy through Private Compliance PKI or Private Enterprise PKI, a cost-effective shared environment through Managed PKI Certificates, or a Custom-Branded Issuing CA that puts your organization’s name on every certificate you issue, SSL provides the infrastructure, the audit evidence, and the operational expertise to back it up.
The FAQs below address the questions our team hears most often from organizations evaluating their options:
Q: How does “Private Compliance PKI” differ from a shared Cloud CA?
A: In a shared environment, you typically share a CA hierarchy and infrastructure with other tenants. Private Compliance PKI provides an isolated, audited hierarchy and dedicated HSM partitions, enabling custom Certificate Policies (CP) and unique naming conventions that are not possible in public trust models. This audited status transforms your private PKI from a simple internal tool into a high-assurance trust anchor, providing documented proof of governance essential for securing supply chains, fulfilling contractual requirements in IoT ecosystems, and ensuring the legal non-repudiation of digital signatures.
How is the “Offline Root” managed in a cloud-hosted model?
A: Even in the cloud, the Root CA remains “air-gapped.” The private keys reside on a FIPS 140-2/3 HSM that is never connected to a network. To sign a new Issuing CA or update a Root CRL, authorized Trusted Custodians perform a formal key ceremony using multi-party control.
Q: Can we use our own Root CA, or must we use yours?
A: This service does not support bringing your own Root CA. The Root CA is generated and managed entirely within the provider’s audited infrastructure during a formally witnessed Key Ceremony. This is a deliberate design decision, as the WebTrust audit covers the full chain of trust from the root to the issuing CA, including the controls, procedures, and HSM protections for the root key.
Introducing an externally managed root would break the audit boundary and undermine the high-assurance guarantees on which the service is built. If you have an existing Root CA that you need to preserve, our team can discuss cross-certification or subordination options to bridge your current hierarchy into the audited environment.
Q: How do you protect the CA private keys?
A: All keys are stored in FIPS 140-2 Level 3 Hardware Security Modules (HSMs). Keys are generated within the hardware and cannot be exported in plaintext. Access to signing keys is protected by strict Role-Based Access Control (RBAC) and dual control requirements.
Q: What does “WebTrust Audited” actually mean for my organization?
A: It means an independent CPA has verified that our data centers, personnel, and cryptographic processes meet the rigorous WebTrust Principles and Criteria. Audits are conducted on the same cadence as our public trust CAs. For you, this provides an “audit pass-through,” allowing you to satisfy SOC 2, HIPAA, or specialized industry requirements (like those in the banking or automotive sectors) without having to build and audit the infrastructure yourself.
Q: When should I choose a Custom CPS over the Standard CPS?
A: Choosing between a Standard and Custom CPS comes down to the specificity of your operational requirements. The Standard CPS is the right choice for most organizations that need a fast, out-of-the-box, compliant PKI for general enterprise use cases like mTLS, VPN authentication, or internal device identity. It’s designed for immediate operational readiness without additional development overhead.
A Custom CPS makes sense when your situation demands more. If your organization operates under specific legal mandates, requires unique identity-vetting logic through a custom Registration Authority, or is part of a consortium (such as Matter or OCSF) that prescribes particular operational rules, a tailored CPS ensures your PKI governance aligns precisely with those requirements rather than working around them.
Q: Do we need a new API if we already use a public CA for our website?
A: No. One of the core strengths of our platform is the Unified REST API. You use the same authentication patterns, SDKs, and API calls for your public-trust SSL/TLS certificates as you do for your high-assurance private certificates. This means your existing integrations and automation workflows carry over directly. There is no need for separate tooling or a second integration effort.
Q: Which automation protocols are supported for IoT and DevOps?
A: The platform natively supports ACME for automated web server and container certificates and the REST API for custom application integrations and CI/CD pipelines. These can be combined to cover heterogeneous environments. For example, ACME for Kubernetes workloads using Server Authentication certificates alongside SCEP for MDM-managed devices using Client Authentication certificates, all managed through the unified REST API and management console.
__________________________________________________________________________________
The infrastructure underpinning your certificate operations affects your compliance posture, your audit readiness, your supply chain credibility, and ultimately your customers’ ability to trust you. SSL brings more than two decades of experience operating an audited, high-assurance PKI to every engagement. Our operations are independently reviewed annually under WebTrust for CA by BDO, our CA keys are protected by FIPS 140-2 Level 3 hardware security modules, and our platform is built to scale from small enterprise deployments to factory-floor IoT provisioning at volume.
By working with SSL, you’re building on a trust foundation that regulators, auditors, and technology ecosystems already recognize. If you’re ready to take ownership of your organization’s digital trust, our specialists can walk you through your Private PKI options.
Contact a Trust Infrastructure specialist today:
The FAQs below address the questions our team hears most often from organizations evaluating their options:
Q: How does “Private Compliance PKI” differ from a shared Cloud CA?
A: In a shared environment, you typically share a CA hierarchy and infrastructure with other tenants. Private Compliance PKI provides an isolated, audited hierarchy and dedicated HSM partitions, enabling custom Certificate Policies (CP) and unique naming conventions that are not possible in public trust models. This audited status transforms your private PKI from a simple internal tool into a high-assurance trust anchor, providing documented proof of governance essential for securing supply chains, fulfilling contractual requirements in IoT ecosystems, and ensuring the legal non-repudiation of digital signatures.
How is the “Offline Root” managed in a cloud-hosted model?
A: Even in the cloud, the Root CA remains “air-gapped.” The private keys reside on a FIPS 140-2/3 HSM that is never connected to a network. To sign a new Issuing CA or update a Root CRL, authorized Trusted Custodians perform a formal key ceremony using multi-party control.
Q: Can we use our own Root CA, or must we use yours?
A: This service does not support bringing your own Root CA. The Root CA is generated and managed entirely within the provider’s audited infrastructure during a formally witnessed Key Ceremony. This is a deliberate design decision, as the WebTrust audit covers the full chain of trust from the root to the issuing CA, including the controls, procedures, and HSM protections for the root key.
Introducing an externally managed root would break the audit boundary and undermine the high-assurance guarantees on which the service is built. If you have an existing Root CA that you need to preserve, our team can discuss cross-certification or subordination options to bridge your current hierarchy into the audited environment.
Q: How do you protect the CA private keys?
A: All keys are stored in FIPS 140-2 Level 3 Hardware Security Modules (HSMs). Keys are generated within the hardware and cannot be exported in plaintext. Access to signing keys is protected by strict Role-Based Access Control (RBAC) and dual control requirements.
Q: What does “WebTrust Audited” actually mean for my organization?
A: It means an independent CPA has verified that our data centers, personnel, and cryptographic processes meet the rigorous WebTrust Principles and Criteria. Audits are conducted on the same cadence as our public trust CAs. For you, this provides an “audit pass-through,” allowing you to satisfy SOC 2, HIPAA, or specialized industry requirements (like those in the banking or automotive sectors) without having to build and audit the infrastructure yourself.
Q: When should I choose a Custom CPS over the Standard CPS?
A: Choosing between a Standard and Custom CPS comes down to the specificity of your operational requirements. The Standard CPS is the right choice for most organizations that need a fast, out-of-the-box, compliant PKI for general enterprise use cases like mTLS, VPN authentication, or internal device identity. It’s designed for immediate operational readiness without additional development overhead.
A Custom CPS makes sense when your situation demands more. If your organization operates under specific legal mandates, requires unique identity-vetting logic through a custom Registration Authority, or is part of a consortium (such as Matter or OCSF) that prescribes particular operational rules, a tailored CPS ensures your PKI governance aligns precisely with those requirements rather than working around them.
Q: Do we need a new API if we already use a public CA for our website?
A: No. One of the core strengths of our platform is the Unified REST API. You use the same authentication patterns, SDKs, and API calls for your public-trust SSL/TLS certificates as you do for your high-assurance private certificates. This means your existing integrations and automation workflows carry over directly. There is no need for separate tooling or a second integration effort.
Q: Which automation protocols are supported for IoT and DevOps?
A: The platform natively supports ACME for automated web server and container certificates and the REST API for custom application integrations and CI/CD pipelines. These can be combined to cover heterogeneous environments. For example, ACME for Kubernetes workloads using Server Authentication certificates alongside SCEP for MDM-managed devices using Client Authentication certificates, all managed through the unified REST API and management console.
__________________________________________________________________________________
The infrastructure underpinning your certificate operations affects your compliance posture, your audit readiness, your supply chain credibility, and ultimately your customers’ ability to trust you. SSL brings more than two decades of experience operating an audited, high-assurance PKI to every engagement. Our operations are independently reviewed annually under WebTrust for CA by BDO, our CA keys are protected by FIPS 140-2 Level 3 hardware security modules, and our platform is built to scale from small enterprise deployments to factory-floor IoT provisioning at volume.
By working with SSL, you’re building on a trust foundation that regulators, auditors, and technology ecosystems already recognize. If you’re ready to take ownership of your organization’s digital trust, our specialists can walk you through your Private PKI options.
Contact a Trust Infrastructure specialist today:
