June 22, 2026
Introduction
A certificate authority list is a list of trusted root or intermediate certificate authorities used by a browser, operating system, or trust program to decide whether a certificate chain should be trusted. For signing and e-signature workflows, the list matters because it helps teams separate browser TLS trust, digital-certificate trust, and legally auditable signing evidence before they choose a platform.
What a certificate authority list actually means
A certificate authority, or CA, issues digital certificates that bind a public key to an identity, domain, organization, person, or device. A root CA sits at the top of a certificate chain. If a browser or operating system trusts the root, it can evaluate certificates that chain back to that root.
The phrase certificate authority list is often used loosely. In practice, teams should ask which list they mean:
This distinction is important because browser trust, document-signing trust, signer identity, audit records, and contract enforceability are related but not identical.
Where to find browser root certificate authority lists
Root lists change over time. A CA may be added, removed, constrained, distrusted, or limited to certain certificate types. For production work, use current official lists rather than a copied static table.
Mozilla and CCADB for public CA data
Mozilla publishes CA information through public CCADB reports. Start with the Mozilla included CA certificate report when you need a detailed public view of included roots, certificate uses, audit information, and related CA metadata.
Chrome Root Store for Chrome trust decisions
Chrome maintains a dedicated root store. The Chrome Root Store is useful when teams need to check which roots Chrome includes and whether any constraints apply.
Apple Root Stores for Apple platforms
Apple publishes platform-specific root store information. The Apple root certificate list for current operating systems is the right starting point for iOS, iPadOS, macOS, tvOS, visionOS, and watchOS trust-store checks.
CA/Browser Forum requirements for public TLS certificates
The CA/Browser Forum Baseline Requirements define requirements for publicly trusted TLS server certificates. They are useful background for understanding why browser-trusted CAs must follow documented issuance, validation, and audit expectations.
EU trusted lists for qualified trust services
For e-signature scenarios in Europe, browser root stores are not enough. The EU Trusted List Browser helps teams review qualified trust service status under the EU trust-services framework.
Browser trust is not the same as e-signature trust
A website TLS certificate proves that a browser can build a trusted connection to a domain. A document signature or electronic-signature workflow asks different questions: who signed, how their identity was verified, what evidence was captured, whether the signed record is retained, and which legal framework applies.
That is why a vendor comparison should not stop at a root CA list. A buyer should also verify:
- signer identity evidence and authentication options.
- audit trail details and event timestamps.
- certificate route for digital signatures, when a digital-signature level is required.
- signed-record retention and export.
- region and counterparty access.
- API and workflow integration needs.
- plan limits, user roles, identity checks, and support cost.
For global or APAC signing, this evaluation is often more important than asking whether a vendor name appears next to a familiar root CA.
How e-signature platforms compare for certificate and trust decisions
The right platform depends on the document type, signer region, identity assurance level, audit requirements, and internal workflow. The comparison below is a buyer checklist, not a legal conclusion or a live pricing table. Confirm current plan details and trust-service routes during procurement.
DocuSign for established enterprise signing programs
DocuSign is often evaluated by large organizations that already have global e-signature governance, admin processes, and procurement support. It can be a strong fit when the team needs a mature signing platform, but buyers should still verify plan scope, authentication add-ons, digital-signature routes, API needs, region support, and how audit evidence will be exported for review.
Adobe Acrobat Sign for PDF-led document teams
Adobe Acrobat Sign is usually considered when PDF workflows and Acrobat ecosystem familiarity matter. It may fit teams that already manage documents in Adobe tools, while procurement should still check whether the workflow depends too heavily on PDF preparation, which identity and certificate options are included, and whether regional signing or API requirements create extra work.
Dropbox Sign for lightweight SMB workflows
Dropbox Sign can be attractive for small teams that need straightforward signing and simple document routing. Teams with growing cross-border volume should confirm admin controls, identity evidence, audit trail depth, signed-record retention, API requirements, and whether a lightweight setup will still satisfy future compliance review.
Where Nota Sign fits for APAC and cross-border agreement control
Nota Sign is a stronger evaluation path when signing involves APAC counterparties, regional rollout, identity evidence, audit records, and agreement workflows that need more control than a simple signature step. The buyer question is not only which CA appears in a list. It is whether the whole workflow can produce reliable signing evidence across regions and teams.
If your team is using a certificate authority list to evaluate e-signature vendors, turn it into a broader trust checklist. Ask each vendor to show the certificate route, signer identity method, audit evidence, retention model, regional access, and total workflow cost before making a selection.
Practical checklist before relying on any CA list
Use this checklist before copying a static list into procurement notes or a compliance memo:
- Identify whether the list is for browser TLS, OS trust, EU qualified trust services, or an internal private PKI.
- Check the official source date and whether the root has constraints.
- Confirm whether the certificate use is TLS, code signing, email, document signing, or another purpose.
- Review the certificate chain, not just the root name.
- Confirm revocation handling, audit status, and policy documents when the decision is security-sensitive.
- For e-signatures, connect certificate trust to signer identity, consent, audit trail, and record retention.
- For cross-border signing, ask how the workflow behaves when senders, signers, and approvers are in different jurisdictions.
Final recommendation
Use a certificate authority list as a starting point, not as the final trust answer. For browser security, check the relevant official root store. For e-signatures, evaluate the complete signing workflow: identity, audit trail, certificate route, retained records, regional access, and cost triggers.
When your team needs to decide whether a signing workflow is ready for APAC or cross-border agreements, contact Nota Sign with your signing volume, signer regions, identity requirements, audit expectations, API needs, and migration constraints. The pricing overview can support budget planning, but the final evaluation should start with the workflow you need to govern.
