Your organization's name in the certificate chain ā publicly trusted from day one
Private Compliance PKI is a cloud-hosted, WebTrust-audited CA hierarchy that belongs entirely to your organization. Your own Root CA and Issuing CA(s), HSM-backed keys, auditor-witnessed Key Ceremonies, and independently verified compliance controls ā operated by SSL on the same infrastructure that underpins our public trust platform.
Your name in the certificate chain. SSL's trusted root underneath.
When SSL issues you a Custom-Branded Issuing CA, your organization receives an X.509 intermediate CA certificate signed by SSL’s publicly trusted root. The issuing CA’s subject contains your organization’s name ā so certificates you issue carry your brand in the CA field, not SSL’s.
What your customers and end users see:
Certificate issued by: Your Organization
The issuing CA visible to certificate inspectors, security tools, and enterprise trust configurations carries your organization's name ā not SSL's.
Publicly trusted from day one
Chains to SSL's globally trusted root ā trusted by Chrome, Firefox, Safari, Edge, iOS, Android, Windows, and macOS immediately. No browser warnings.
No root distribution required
SSL handles root program membership (Mozilla, Microsoft, Apple, etc.), ongoing root store maintenance, and compliance obligations above your Issuing CA.
CA/B Forum compliant
SSL's root program compliance obligations flow down to your Issuing CA ā certificates issued must comply with CA/B Forum Baseline Requirements.
You appear as the CA; SSL maintains the root. Every certificate your Issuing CA issues is trusted by all major browsers and operating systems without any root distribution effort on your part.
Key benefits
Your brand in the CA field
Inherit SSL's WebTrust audit evidence for your PKI ā without building or funding your own audit program.
Publicly trusted from day one
Partners, regulators, and customers can inspect your CA's audited governance ā not just its certificates.
No root management
ACME, SCEP, EST, REST API enrollment ā built for DevSecOps, Kubernetes, MDM, and factory-floor issuance.
CA/B Forum compliant
All CA private keys generated and stored in certified hardware ā never exportable in plaintext.
HSM-backed sub-CA key
Hybrid post-quantum profiles (ML-KEM, ML-DSA, SLH-DSA) available at the Ecosystem/IoT tier.
Defined certificate profiles
Same API used for public-trust certificates ā no separate integration required.
Who is this for?
Custom-Branded Issuing CA is ideal for:
- Technology partners and resellers who issue SSL certificates under their own brand to end customers ā your customers see your CA name, not SSL’s
- SaaS and platform providers who need to issue TLS or client certificates within their platform with their own brand
- Enterprises with a strong public-facing CA identity requirement who need their name in the public certificate chain without the overhead of a root program
- Organizations building partner certificate programs where partner-issued certificates need to chain to a globally trusted root
Important constraints
CA/B Forum Baseline Requirements apply
Medical devices, IIoT, automotive. Devices need an audited "birth certificate" for secure boot, firmware signing, and mTLS. The WebTrust audit proves the issuance process meets bank-grade security standards.
No private or internal namespaces
When government agencies or large enterprises require vendors to prove security infrastructure meets strict standards, the WebTrust seal on your dedicated PKI is the documented proof.
Subject to SSL audit obligations
The WebTrust-audited foundation pre-certifies the PKI component of your compliance audit. Signatures issued under an audited CA are legally defensible.
How engagement works
Compliance & standards
CA/B Forum Baseline Requirements
All certificates issued under your Issuing CA must comply with CA/B Forum Baseline Requirements ā enforced through SSL's CP/CPS.
WebTrust for CAs
SSL's root operations are covered by an annual WebTrust audit ā your Issuing CA inherits this compliance posture.
RFC 5280 (X.509)
All certificates conform to X.509/RFC 5280.
FIPS 140-2 Level 3 HSMs
Your Issuing CA private key is stored in FIPS-certified hardware under SSL's infrastructure.
Frequently asked questions
End users inspecting the certificate will see your organization's name as the issuing CA. The root CA ā which SSL controls ā will appear in the full chain, but the issuing CA visible to most users and tools will carry your name.
Yes ā because the Issuing CA chains to SSL's publicly trusted root, all issuance must comply with CA/B Forum Baseline Requirements. SSL's audit obligations and CP/CPS constraints apply to your Issuing CA. This is the fundamental difference between a Custom-Branded Issuing CA (publicly trusted, BR-constrained) and a Dedicated Private PKI (not publicly trusted, full policy flexibility).
Certificate types must comply with CA/B Forum requirements. TLS/SSL certificates are the primary use case. Contact SSL to discuss specific profiles and EKUs for your use case.
No ā because this Issuing CA chains to a publicly trusted root, it cannot issue certificates for private namespaces or internal-only identifiers that violate BR requirements. For that use case, see Managed PKI Certificates or Dedicated PKI.
As the trust chain depends on SSL's root, any distrust of SSL's root would affect certificates issued by your Issuing CA. SSL maintains full compliance with all major root programs to protect against this risk.
Ready to put your name in the certificate chain?
Related Products
Private Compliance PKI
Need your own Root CA + WebTrust audit coverage ā full hierarchy ownership.
Private Enterprise PKI
Need your own Root CA for internal use ā no public trust constraints.
Managed PKI Certificates
Issue private certificates on shared infrastructure ā internal namespaces, no BR constraints.