Cisco Systems

 

Cisco offers Trusted Root Store bundles for configuring the default trusted Certificate Authorities of applications, operating systems, and products we ourselves use, and those which go into the products and offerings we sell to customers.

The Trusted Root Stores are a collection of Certificate Authorities used in Public Key Infrastructure, and cover a variety of protocols and usages, such as HTTPS (SSL / TLS), VPN, SMPTS / STARTTLS, FTPS, LDAPS, S/MIME, Code Signing, etc. The usage of such bundles is context dependent, and we offer a few public bundles:

Core Bundle - Used for communication throughout and back to Cisco. Only Cisco private CAs and approved public CAs.

(Download Core Bundle)

Intersect Bundle - Required for products and services that require TLS connections to services not operated by Cisco. and consists of Core plus only the public CAs that are trusted by all the major Root Store programs. If your app / product speaks to the public internet, this bundle is likely the best choice.

(Download Intersect Bundle)

Union Bundle - Used where connectivity is favored at the cost of security, and generally used by devices like proxies that require wide connectivity. Union bundle is similar to Intersect, but includes every public CA that are trusted by any of the major Root Store programs.

(Download Union Bundle)


FedRAMP Bundle - Used for US federal operations, this bundle consists of the Core bundle, plus the USA CAs from the Intersect bundle, plus root CAs from the US DoD External PKI Trust Chains.

(Download FedRAMP Bundle)

 

Table of Contents

 

 

 

What is a Trusted Root Store?

Public Key Infrastructure (PKI) is built on the concept of a trust model: when presented with a new public key, an entity must have some basis for deciding whether or not to trust that the key presented is actually associated uniquely with the entity presenting it. In SSL-secured HTTP or SMTP, S/MIME, and similar services, this trust is based on a centralized, hierarchical trust model known as a trust chain: the presenter has had its public key validated and signed by a third party whose key is already known to the recipient and trusted to make such decisions. Examples of this type of third party include VeriSign, Thawte, and IdenTrust. This third party’s signed key, since it forms the root of the trust chain, is known as a root certificate.

 

Cisco has built numerous products that rely on a set of root certificates that pre-instantiate trust with a common set of certificate vendors: this set of root certificates is known as a root store. In alignment with Cryptographic Services’ function as the centralized provider of cryptographic materials for Cisco, Cryptographic Services has created multiple centralized sets of root certificates that will be validated and maintained by Cryptographic Services for development teams to use when building products that rely on this type of root store. By centralizing this service and the process of approving root certificate authorities for inclusion, Cisco intends to reduce redundancy in development resources, increase communication between development teams integrating this function into their products, and increase the security and trust level of each of its products.

 

What is Cisco Providing?

Cryptographic Services currently offers three root store bundles for products to use in anchoring TLS trust, ranging from minimized trust (most secure) to a wide range of public CAs (least secure). Per PSB requirements (SEC-509-CALIST), teams must choose the root store with the smallest trust possible that will still meet their needs.

At the moment, Cryptographic Services is providing these trust bundles as amalgamated collections of certificates from other trust stores.

 

What is in the different bundles?

See the Root Store Public cisco.com Page which has copies of the latest bundles, manifests showing the contents of each of the current bundle files, as well as historical records of the bundle contents over time. There is also a page documenting the Cisco Internal Certificate Authoritiesthat are included with each bundle.

 

How can I download these Trust Store bundle files?

Each Trust Store bundle is provided as a digitally signed PKCS#7 bundle file (.p7b), available for download from Cisco's public website at the main Cryptographic Services page (https://www.cisco.com/security/pki/trs/current/). Each bundle has been signed with a digital signing certificate that chains to Cisco's Root CA M1 embedded in most Cisco products (and also available publicly from that same site).

 

What is the difference between the various Trust Stores?

Core Trust Store

Cisco provides a small bundle intended to facilitate services connecting specifically to Cisco-owned resources, such as products connecting to tools.cisco.com to look for software updates. This bundle includes only the certificates considered necessary to connect to Cisco resources, including the main Cisco-operated roots as well as specific third-party roots that are commonly used to issue Cisco production SSL certificates, as well as the Approved Public CAs.

 

Recommended Uses

The Core bundle makes an excellent default set of trust anchors for products, since it contains no more trust than is necessary to obtain updates and data directly from Cisco. This makes it a good choice as the default trust bundle for products; the products may then offer customers the option to expand trust to external CAs with the Intersect bundle where appropriate.

 

Download

The core bundle is available for download directly here: https://www.cisco.com/security/pki/trs/current/ios_core/

 

Intersect Trust Store

The collection of root certificates in the intersect bundle consists of the most significant industry root certificate authorities. Cryptographic Services collects and analyzes the following root stores:

 

  • Microsoft Root Store Program (used for Windows/Internet Explorer)
  • Mozilla Root Store Program (used for Firefox)
  • Google Root Store Program (used for Android OS)
  • Apple Root Store Program (used for all Apple products such as Mac OS and iOS).

 

The Intersect bundle consists of a mathematical intersect of these root stores: only roots in all three of the root stores are included in the Intersect bundle. In addition, Cisco may include specific Cisco root certificate authorities in this bundle for product compatibility or security reasons, such as the Licensing CA to support license verifications. Cisco also verifies, wherever possible, that each selected provider has at a minimum completed the AICPA WebTrust for CA certification audit and filed the results appropriately. A complete list of the certificates included in this bundle is available from Cryptographic Services on request.

 

Recommended Uses

The Intersect bundle is the required choice for products and services that require TLS connections to services not operated by Cisco. As an example, when connecting to a website operated by a customer, the product may not be able to anticipate which CA the customer has purchased their certificate from. The Intersect bundle provides a reasonable set of default trust for this situation, containing the most common industry CAs from the customer might have obtained a certificate.

 

Download

The intersect bundle is available for download directly here: https://www.cisco.com/security/pki/trs/current/ios/


 

Union Trust Store

Cisco also provides a Union bundle to support specific applications that require wider trust support at the expense of lower overall security. This bundle analyzes the contents of the four root stores referenced above, and then constructs a bundle consisting of all the certificate authorities in any of the three root stores (a mathematical union). As with the Intersect bundle, Cisco may include specific Cisco root certificate authorities in the Union bundle for product compatibility or security reasons. Because the Union bundle is significantly larger than the Intersect bundle and is considered to have a lower trust level, Cisco may not manually verify the completion of annual AICPA WebTrust for CA certification audits for all CAs included. A complete list of the certificates included in this bundle is available from Cryptographic Services on request.

 

Recommended Uses

Recommended uses for the Union bundle include applications such as SSL circuit proxy functions, where the product needs to trust the widest possible array of certificate authorities in order to provide maximum compatibility.

 

Because the Union bundle offers a significantly lower security profile due to vastly wider trust, it is intended only for use in applications where this wider trust will not compromise the overall product trustworthiness.

 

**WARNING** : The Union bundle MUST NOT be used as the primary trust bundle for default TLS connections in a product.

 

Download

The union bundle is available for download directly here:https://www.cisco.com/security/pki/trs/current/ios_union/

 

FedRAMP Trust Store

The FedRAMP (Federal Risk and Authorization Management Program) trusted root store is a collection of digital certificates that have been deemed trustworthy by the U.S. government for use in securing federal information systems. These certificates are issued by trusted Certificate Authorities (CAs) and are used to establish secure connections between users and federal systems, ensuring the integrity, confidentiality, and authenticity of data transmitted over these connections. The FedRAMP trusted root store helps standardize security practices across federal agencies by providing a common set of trusted certificates that meet rigorous security standards.

 

Recommended Uses

The FedRAMP bundle should be used for establishing the secure connections in the context of the Federal Risk and Authorization Management Program (FedRAMP). This bundle is created from the intersect bundle for exclusive use in US FedRAMP environment.

 

Download

The FedRAMP bundle is available for download directly here: https://www.cisco.com/security/pki/trs/current/fedramp/

 

TRS Bundles: New Features and Functionalities

 

This section outlines the new features in the Cisco Trusted Root Store (TRS) bundles.

 

Downloading the new bundles

The new trusted root store bundles can be downloaded from subdirectories of the existing TRS index:

 

Current Directory

The /current/ directory contains all the latest bundles, each organized into its own subdirectory. The structure of the /current/ index is as follows:

A screenshot of a computer AI-generated content may be incorrect.

Each bundle's latest version is located in its respective subdirectory.

 

Archive Directory

The /archive/ directory houses historical versions of each bundle. The structure mirrors that of the /current/ directory:

A screen shot of a computer AI-generated content may be incorrect.

Each bundle’s directory contains a list of prior versions, with each version stored in its own subdirectory named after the version.

 

Directory Contents

Both the /current/ and /archive/ directories include the following types of content:

 

Here is a preview of the /archive/ios/ and /current/ios/ directory.

A screen shot of a computer AI-generated content may be incorrect.

 

A screenshot of a computer AI-generated content may be incorrect.

 

 

Log Files

Each bundle directory contains two log files:

  1. manifest.log : Lists the certificates included in the bundle.
  2. rejected.log : Lists the certificates excluded from the bundle, along with the reasons for exclusion.

 

File Naming Convention

Files follow a consistent naming convention to indicate their type and format. For example: 

e22df10076c90c5e62bf88a389ef51a9d66eae23fc1245e8bcbbb6632cdb7057da1fb457969fa601f312ae6d951375e398dfd97c710a143b2ccc35443f6fd407

Additionally,

JSON Diff

Each bundle includes a JSON diff file that details changes between the current and previous versions. These files are human-readable and can be parsed by SHA to identify added or deleted certificates. Example structure:

{
  "currentVersion": "20250513",
  "prevVersion": "20250417",
  "additions": [
    {
      "certSha256": "6AB2AB75F51CB4F4F0156203FBF6F646232F514BE059F62833308B82B4D72DB1",
      "certSubjectDn": "CN=SECOM TLS ECC Root CA 2024,O=SECOM Trust Systems Co.\\, Ltd.,C=JP"
    },
    {
      "certSha256": "1435F225C5D252D7A21948CC3CE62AECFA88001E3DD72D1CC3555100EB372F93",
      "certSubjectDn": "CN=SECOM TLS RSA Root CA 2024,O=SECOM Trust Systems Co.\\, Ltd.,C=JP"
    }
  ],
  "deletions": [
    {
      "certSha256": "16AF57A9F676B0AB126095AA5EBADEF22AB31119D644AC95CD4B93DBF3F26AEB",
      "certSubjectDn": "CN=Baltimore CyberTrust Root,OU=CyberTrust,O=Baltimore,C=IE"
    }
  ]
}

Release Scheduling

The release process for TRS bundles has been updated:

Bundle Versioning

The version system for the new bundles has changed. The old TRS bundles were versioned sequentially. Since not all bundles release at the same pace, this versioning system did not provide any info as to how old or new a particular version was. The new versions are a UTC date string in the format yyyyMMdd. This date is the date that the bundle was built, signed, and published.

Bundle Signing

The old bundles are signed by the same offline root signer (Cisco Root CA M1). The new bundles use a new signing cert for each version, issued from the TRS Bundle SubCA. The signing certs are obtained from a Cryptographic Services internal CA. This process allows for revocation checking in the event that a signing key is ever compromised.

 

Frequently Asked Questions

 

Question: How do I extract the certificates from this bundle?

 

You can also extract the information from the bundle with OpenSSL, provided you are using OpenSSL v1.0 or greater.

 

To do this, you will need:

  1. The bundle file you want to extract (e.g. 'ios.p7b') (see Trust Store Sections above or see https://www.cisco.com/security/pki/)
  2. A copy of the signing certificate for the bundles

 

Then run these commands:

# This command extracts the certificate bundle as a message into the
# file iosBundleBodyVerified.p7b if the signature verifies
openssl cms -verify -nointern -purpose any -inform DER -in ios.p7b -outform DER \
  -out iosBundleBodyVerified.p7b -certfile RootBundleSigningCertificate.cer -CAfile RootBundleSigningCertificate.cer

# This command extracts the certificates from the bundle into a separate
# file, iosCerts.PEM, containing only the PEM-formatted certificates from the bundle.
openssl pkcs7 -inform DER -print_certs -outform PEM < iosBundleBodyVerified.p7b \
  |grep -v 'subject=' |grep -v 'issuer=' |sed '/^$/d' > iosCerts.PEM

# If you are on Linux, use this command to split the PEM bundle into individual certificate files
# (Does not work on a Mac due to GNU awk)
awk 'BEGIN {c=0;} /BEGIN CERT/{c++} {print > c ".pem"}' < ../iosCerts.PEM

# If you are on a Mac, use this command to split the PEM bundle into individual certificate files
# (Does not work on Linux due to split not supporting the -p flag)
split -p "-----BEGIN CERTIFICATE-----" iosCerts.PEM individual-

# If you want to see the SubjectDN for all the root certs you just split into individual files,
# here's an example using OpenSSL to parse (modify to extract any field you may be interested in)
for i in individual-*; do openssl x509 -in $i -text | grep "Subject:"; done

 

Question: This bundle only seems to have few certificates in it when I check it with OpenSSL. Why?

 

Answer: The bundles are provided as a signed message file: by default, OpenSSL's PKCS#7 handler will only see the signature envelope on the file and not the contents. If you are only seeing few certificates, then you have not fully unpacked the certificate bundle.

To extract the certificates, follow the instructions above.

 

Question: I'm currently using the Mozilla/NSS trust store for my product. Why should I switch to this? Do I have to switch?

 

Answer: At this time, the use of the Cisco Trust Stores is a PSB requirement per requirement SEC-509-CALIST. This means teams must convert to using these bundles for TLS connections originating from Cisco product or service code (if you run into problems with this, we want to hear from you!).

 

All Cisco-developed code must use these Trust Stores as an anchor when originating TLS connections. Third-party software such as operating systems or browsers should not use these trust stores, to ensure compatibility and support. So if your Linux server needs to connect to Debian to download a patch, it should continue using the manufacturer-provided trust store to do so. If your Cisco-developed Java application needs to connect to something, it must use the Cisco Trust Stores.

 

The use of these trust stores offers several compelling features over the use of a third-party trust store:

 

 

Question: How often are the bundles updated? How do I find out about updates?

 

Answer: Bundles are built daily but published only when there’s a change in CCADB. Cryptographic Services also reserves the right to publish an emergency update in the event of a CA compromise. All updates are announced in advance (wherever possible) and after the fact on the Trusted Root notification mailer: trusted-root-notify@cisco.com (NOTE: Internal Cisco-only mailer). We urge all developers consuming or working with the Cisco Trust Store bundles to subscribe to that mailer (it's very low-traffic, we promise!).

 

Question: How do I find the version of a bundle?

 

Answer: Bundle files include a signed attribute designating the version number of the bundle.  It is contained in a custom OID: 1.3.6.1.4.1.9.21.2.3.1 .  Programmatically that OID can be parsed like so (the value in PRINTABLESTRING is the version number of the bundle):

openssl cms -in ios_union.p7b -noout -cmsout -print -inform DER | grep -A 2 "1.3.6.1.4.1.9.21.2.3.1"

 

Example output (showing v15 for ios_core.p7b):

 

JKS format does not support signed attributes like PKCS7. So to store the version in the JKS format bundles, a workaround is used. The version is added as a PKCS12 attribute to the trusted cert entry for the bundle signer. Since this is not supported in JKS format, the Java keytool is unable to read it. The version can be extracted by converting the JKS file to a p12 file and using OpenSSL. An example is shown below:

 

# Extract version from JKS bundle by converting to PKCS12 and parsing attributes
keytool -importkeystore -srckeystore ios.jks -srcstoretype JKS -srcstorepass password \
        -destkeystore _TEMPP12 -deststoretype PKCS12 -deststorepass password > /dev/null 2>&1 && \
openssl pkcs12 -in _TEMPP12 -nokeys -nodes -passin pass:password \
        -info -nomacver 2> /dev/null | \
grep "1.3.6.1.4.1.9.21.2.3.1:" | \
awk "{print $2}" && \
rm -rf _TEMPP12

 

(Note, this creates and deletes a temporary file "_TEMPP21")

 

Example Output:

20250513

 

Using Java code, finding the version of a JKS bundle is much easier:

import java.io.*;
import java.nio.file.Files;
import java.nio.file.Path;
import java.security.KeyStore;
import java.security.Signature;
import java.security.cert.Certificate;
import java.util.*; 

try {
    final KeyStore keystore = KeyStore.getInstance(new File(jksFilename), (char[])null);
    final KeyStore.TrustedCertificateEntry entry =
            (KeyStore.TrustedCertificateEntry)keystore.getEntry("signer-cert", null);
    final Set<KeyStore.Entry.Attribute> attributes = entry.getAttributes();
    for (KeyStore.Entry.Attribute attr : attributes) {
        if (attr.getName().equals("1.3.6.1.4.1.9.21.2.3.1")) {
            return attr.getValue();
        }
    }
    throw new RuntimeException("Failed to find version attribute");
} catch (Exception e) {
    throw new RuntimeException(e);
}

 

Question: How do I verify a bundle?

 

Answer: Please use this shell utility to verify the bundle:  https://wwwin-github.cisco.com/sto-cryptosvcs/trs-verify/tree/dev

 

Highlights of this script's key features:

 

Single command to verify TRS bundles

 

Files needed to complete the following commands:

Cisco M1 Root
TRS Bundle SubCA
TRS Bundle Root CA 
# Option 1: Verify with Cisco M1 Root certificate
openssl cms -verify -inform DER -in <your TRS bundle.p7b> -out verified.p7b -certfile <crcam1.pem>

# Option 2: Verify with New TRS Signer certificates
openssl cms -verify -inform DER -in <your TRS bundle.p7b> -out verified.p7b -certfile <tbsca.pem> -CAfile <tbrca.pem>

 

Question: How does JKS verification work?

 

Answer: Since JKS format does not support signed messages, detached signatures are published which can be used to verify integrity of the entire keystore file. This is a rather straightforward process in Java code:

import java.io.*;
import java.nio.file.Files;
import java.nio.file.Path;
import java.security.KeyStore;
import java.security.Signature;
import java.security.cert.Certificate;
import java.util.*; 

public boolean verifySignature() {
    try {
        if((signatureFilename == null) || (signatureFilename.isEmpty())) {
            System.out.println("No signature filename specified");
            System.exit(1);
        }

        final KeyStore keystore = KeyStore.getInstance(new File(jksFilename), (char[])null);
        final Certificate signerCert = keystore.getCertificate("signer-cert");

        final String sigStr = Files.readString(Path.of(signatureFilename)).strip();
        final byte[] sigBytes = HexFormat.of().parseHex(sigStr);

        final ByteArrayOutputStream keystoreBytes = new ByteArrayOutputStream();
        keystore.store(keystoreBytes, null);

        final Signature sig = Signature.getInstance("SHA256withRSA");
        sig.initVerify(signerCert);
        sig.update(keystoreBytes.toByteArray());
        return sig.verify(sigBytes);
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
}

 

Signature verification can also be performed using keytool and OpenSSL on the command line:

 

# Export the signer certificate from the JKS keystore
keytool -exportcert -alias "signer-cert" -keystore ios.jks -rfc -file _TEMP_signer-cert.pem

# Download the signature file
curl -fsSL "https://www.cisco.com/security/pki/trs/current/ios/ios.jks.signature.sha256" -o "ios.jks.signature.sha256"

# Convert hex signature to binary
xxd -r -p "ios.jks.signature.sha256" "ios.jks.signature.sha256.bin"

# Extract public key from certificate
openssl x509 -in "_TEMP_signer-cert.pem" -pubkey -noout > "_TEMP_pubkey.pem"

# Verify the signature
openssl dgst -sha256 -verify "_TEMP_pubkey.pem" -signature "ios.jks.signature.sha256.bin" "ios.jks"

# Clean up temporary files
rm -rf _TEMP_signer-cert.pem ios.jks.signature.sha256 ios.jks.signature.sha256.bin _TEMP_pubkey.pem

 

 

Question: How do I extract all the certs from the JKS?

 

Answer: You can extract all certificates from a JKS keystore using the following Java code:

 

import java.io.*;
import java.nio.file.Files;
import java.nio.file.Path;
import java.security.KeyStore;
import java.security.Signature;
import java.security.cert.Certificate;
import java.util.*; 

    public Certificate getCertificate(final String certSha256) {
    try {
      final KeyStore keystore = KeyStore.getInstance(new File(jksFilename), (char[])null);
      return keystore.getCertificate(certSha256);
    } catch(final Exception e) {
      throw new RuntimeException(e);
    }
  }
  
  public Set<Certificate> getAllCertificates() {
    try {
      final KeyStore keystore = KeyStore.getInstance(new File(jksFilename), (char[])null);
      final Set<Certificate> certs = new HashSet<>();
      final Iterator<String> iter = keystore.aliases().asIterator();
      while(iter.hasNext()) {
        final String alias = iter.next();
        if(keystore.isCertificateEntry(alias)) {
          certs.add(keystore.getCertificate(alias));
        }
      }
      return certs;
    } catch(final Exception e) {
      throw new RuntimeException(e);
    }
  }

 

 

Question: None of my questions are answered here, who can I contact?

Answer: Please write to us: trust-root-store@external.cisco.com