System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

PDF

System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

Certification authority interoperability facts

Want to summarize with AI?

Log in

Lists key facts, examples, and lookup details for certification authority interoperability to help you verify and plan certificate deployments.


he following reference information is provided to support certification authority interoperability:

  • Supported certificate authority types:

    • Root CA

    • Intermediate CA

    • External CA

    • Self-signed CA

  • Interoperability examples:

    • Certificate signing requests (CSRs) generated by device or software are compatible with root and intermediate certificate authorities using PEM encoding.

    • Import and validation of external CA certificates may require conversion to DER format.

  • Command outputs for validation:

    • Use the show crypto pki certificates to verify certificate installation.

    • Use the show crypto pki trustpoints to display certificate authority configuration

    • Use the show crypto pki and debug crypto pki events commands to check interoperability status.

Planning considerations

  • Ensure certificate chain includes both root and intermediate authorities for proper trust validation.

  • When configuring certificate authorities, align key usage and extended key usage attributes with interoperability requirements.

  • Validate certificate authority profiles against the latest security policy requirements.


Certification authority interoperability standards

Cisco supports the following standards:

  • Public-Key Cryptography Standard #7 (PKCS #7): Encrypts and signs certificate enrollment messages.

  • Public-Key Cryptography Standard #10 (PKCS #10): Provides syntax for certificate requests.

  • RSA keys: Developed by Ron Rivest, Adi Shamir, and Leonard Adelman; RSA keys come in pairs (one public key and one private key).

  • SSL: Secure Socket Layer protocol.

  • X.509v3 certificates: Enables IPSec-protected networks to scale by providing digital ID cards for devices. When devices communicate, they exchange digital certificates to prove identity, eliminating manual public key exchange. Certificates are obtained from a Certificate Authority (CA); X.509 is part of the X.500 standard of the ITU.

Note

The Internet Key Exchange (IKE) standard is not supported.


Certification authorities

A certification authority is a trust management entity that

  • issues digital certificates to validate the identity of devices and users

  • verifies certificate authenticity and manages certificate revocation, and

  • enables interoperability for certificate-based trust across Cisco IOS XR deployments.

Additional reference information

Certification authorities (CAs) play a critical role in establishing and maintaining secure communication within network environments. They handle certificate issuance, manage registration authorities, and define operational constraints for interoperability.

A typical deployment might use multiple certification authorities to ensure secure device authentication between routers running Cisco IOS XR. CA registration authorities may serve as intermediaries to facilitate certificate enrollment and lifecycle management.


Certification authority purposes

Certification authority purposes are certificate authority interoperability components that

  • manage certificate requests and issue certificates to participating IPSec network devices to provide centralized key management

  • simplify the administration of IPSec network devices across multiple IPSec-compliant devices, such as routers, and

  • enable digital signatures, using public key cryptography, to authenticate devices and individual users.

  • Digital signatures are enabled by public key cryptography. Each user possesses a key pair: a public and a private key. The keys complement each other—data encrypted with one key can be decrypted with the other. A signature is formed when data is encrypted with a user's private key; the receiver verifies the signature by decrypting the message with the sender's public key. Successful decryption indicates the sender is the holder of the private key, enabling trust.

  • Digital certificates provide the link. A digital certificate contains identifying information (such as name, serial number, company, department, or IP address) and a copy of the entity's public key. The certificate is signed by a certification authority (CA), a trusted third party. To validate the CA's signature, the receiver must know the CA's public key, usually set during installation or via configuration (for example, browsers preconfigured with several CAs, or IKE authenticating peer devices).

  • Without digital signatures, manual exchange of public keys or secrets is required between device pairs. Adding new devices necessitates changes across all devices. With certificates, each device enrolls with a CA; when two devices communicate, they exchange certificates and digital signatures to authenticate each other. Adding a new device requires only CA enrollment, no updates to other devices. Certificates are exchanged automatically, allowing authenticated secure connections.


CA registration authorities

A CA registration authority is a certificate authority interoperability component that

  • acts as a proxy server to handle certification authority (CA) functions when the CA is offline

  • supports certificate enrollment, validation, or trust management on Cisco IOS XR routers, and

  • facilitates interoperability and operational continuity for certificate-based trust deployments.

Some CAs include a registration authority (RA) as part of their implementation. The RA serves as a proxy for the CA, allowing CA functions to continue even when the CA itself is offline.

Additional reference information

Registration authorities play a crucial role in managing certificates in environments that require high availability and redundancy. By acting as intermediaries, they ensure that certificate lifecycle operations such as enrollment and validation are not disrupted during CA downtime.