Skip to content

CONCEPT Cited by 1 source

Cross-signed certificate trust (double-signed certificates)

Definition

A PKI design where two (or more) isolated root certificate authorities cross-sign each other's certificates, producing a bidirectional chain of trust so relying parties in either trust domain can validate certificates issued by the other. Sometimes called double-signed certificates in the AWS-partition context: each partition retains its own root CA; each partition also holds a certificate from the other partition's root signed by its own root, making chains valid in both directions.

Why it exists

When the PKI substrate itself is partitioned (e.g. AWS Private CA certificates are bound to individual partitions), two workloads in different partitions attempting mTLS both present valid certificates in their own trust domain that the peer's trust store can't validate.

Three available design answers:

  1. Separate PKIs, no bridging. Each partition trusts only itself; no cross-partition mTLS. Rules out authenticated encrypted cross-partition service-to-service traffic as a whole category.
  2. Manual private-key transfer between partition CAs. A single logical root is installed in both partitions by copying keys; makes the "partition isolation" property a lie at the PKI layer.
  3. Cross-signed root CAs. Each partition's CA signs a cross- certificate for the other partition's CA; trust stores in both partitions learn the cross-certificate; mTLS chains validate bidirectionally without key material ever leaving its home partition.

The AWS Sovereign Failover post names option 3 as the regulated-environment answer: "A more advanced solution involves using double-signed certificates, where root CAs in each partition cross-sign each other's certificates, creating a bidirectional chain of trust." (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)

Operational requirements

The post names the moving pieces:

  • Root CAs in each partition via AWS Certificate Manager Private CA.
  • Cross-signing agreements — the organizational / legal / procedural contract defining who cross-signs whose CA and under what constraints.
  • Trust-store management across partitions — every relying service must load both the local CA and the cross-certificates so chains validate.
  • Certificate validation and revocation checks across partitions — CRL / OCSP endpoints must be reachable from the verifying partition, which intersects the cross-partition authentication and connectivity problems.
  • Differing regulatory requirements and detailed audit trails — compliance obligation in regulated environments.

"Although this approach adds operational complexity, it is essential for enabling authenticated, encrypted communication across isolated partitions, particularly in regulated environments where security and compliance are paramount." (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)

Where it shows up outside AWS partitions

The same shape appears in any scenario where two trust domains need to interoperate without collapsing into one:

  • Browser CA bridging (historical) — one CA cross-signs another so a newly-audited CA gets client trust through an existing root.
  • Government CA bridging — Federal Bridge CA cross-signs agency CAs to enable inter-agency PKI trust.
  • Acquisitions / M&A — two enterprise PKIs cross-sign instead of migrating all certificates to one.
  • Partner federation — two companies cross-sign to allow authenticated service-to-service TLS without merging identity stores.

The AWS-partition case is structurally identical; it happens at a boundary a cloud provider chose to enforce rather than at a corporate / governmental one.

Tradeoffs vs alternatives

  • vs. single shared CA across partitions: cross-signing preserves partition-isolation property — private keys never leave their home partition; a sovereignty breach in one partition doesn't automatically mint valid certs in the other.
  • vs. public-CA-issued certs on both sides: public CAs aren't available inside most regulated partitions for internal-service PKI; cross-signed private CAs solve the case where neither side wants public-web-PKI semantics (and the economic cost of issuing short-lived certs per internal service at scale).
  • vs. mutual-auth over a shared private-key-material pair: trust-scope failure isolation is the main win — a root key compromise in partition A revokes A's presence in B's trust store without touching B's own keys or services.

Seen in

Last updated · 200 distilled / 1,178 read