Branded Issuing CA
Your name in the certificate chain, publicly trusted from day one
A Branded Issuing CA is an intermediate CA under SSL's publicly trusted root, with your organization's name in the CA field of every certificate. Offered by engagement to qualified partners, and hosted and operated by SSL.
Your name in the certificate chain. SSL's trusted root underneath.
When SSL issues you a 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.
A Branded Issuing CA is publicly trusted and covers public-trust certificates only. For private or internal use, see Private Compliance PKI or Managed PKI Certificates.
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, so it is trusted immediately by every browser and operating system, exactly as SSL's own issuing CAs are. 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, so certificates issued must comply with CA/B Forum Baseline Requirements.
You appear as the CA; SSL hosts and operates it and maintains the root. Every certificate your Branded Issuing CA issues is trusted by every browser and operating system immediately, without any root distribution effort on your part.
Key benefits
Your brand in the CA field
Certificates carry your organization's name in the issuing CA field, visible to certificate inspectors, security tools, and enterprise trust configurations.
Publicly trusted from day one
Chains to SSL's globally trusted root, trusted by every browser and operating system immediately.
No root management
No Root CA key, no Key Ceremony, no root program applications, SSL handles the full chain 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 Baseline Requirements.
HSM-backed sub-CA key
Your Issuing CA private key is stored in FIPS-compliant hardware under SSL's infrastructure.
Defined certificate profiles
Certificate profiles for your Issuing CA are defined per the CA/B Forum requirements and your use case.
Who qualifies?
Branded Issuing CAs are offered by exception. A dedicated CA that puts a partner’s name in the public certificate chain only makes sense when the partner’s size and brand justify it. We review every request individually and work with partners that meet all five criteria:
- Established brand whose name in the public certificate chain carries weight in the market
- Real scale in certificate volume or spend, enough to justify a dedicated CA
- Strategic value to both SSL and the partner
- Compliance maturity to operate within SSL’s WebTrust audit program, CP/CPS, and the CA/B Forum Baseline Requirements
- Full commercial commitment to the engagement
Resellers and technology partners that do not meet these criteria can issue certificates under SSL’s brand through the SSL reseller program.
Start a qualification review
Tell us about your brand, expected issuance volumes, use case, and compliance posture. SSL’s enterprise team reviews every request individually, and an SSL executive approves each engagement before terms are discussed. Pricing is set per engagement and is not published.
Important constraints
CA/B Forum Baseline Requirements apply
Because your Issuing CA chains to SSL's publicly trusted root, all certificates issued must comply with CA/B Forum Baseline Requirements, domain and identity control must be validated per BR rules.
No private or internal namespaces
This Issuing CA cannot issue certificates for private namespaces, internal-only names, or non-FQDN identifiers. For private certificate needs, see Managed PKI Certificates or Dedicated PKI.
Subject to SSL audit obligations
Your issuance operations are subject to SSL's CP/CPS constraints and the same audit program that governs our public trust platform.
SSL hosts and operates your CA
Your Branded Issuing CA is hosted and operated by SSL, on the same infrastructure that underpins our public trust platform.
Publicly disclosed, shared accountability
Your Branded Issuing CA is publicly disclosed under your organization's name. SSL remains accountable to the root programs for every certificate issued, so an incident on your CA is also an SSL incident.
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 Branded Issuing CA operates within SSL's audit scope.
RFC 5280 (X.509)
FIPS-compliant HSMs
Your Issuing CA private key is stored in FIPS-compliant 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.
SSL hosts and operates it on SSL's infrastructure, the same infrastructure that underpins our public trust platform. Your organization receives the branded CA; certificates you issue are issued through SSL's issuance API.
Your Branded Issuing CA is publicly disclosed under your organization's name, and SSL remains accountable to the root programs for every certificate issued under its roots. An incident affecting your CA is therefore also an SSL incident, and SSL may require remediation or revoke the Issuing CA.
Pricing is set per engagement after a qualification review and is not published. Issuing CA terms and certificate terms are agreed separately.
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 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 start a qualification review?
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.