Introduction
This white paper provides detailed design and implementation information relating to the deployment of Public Key Infrastructure (PKI) with the Cisco® Virtual Office.
Please refer to the Cisco Virtual Office overview at http://www.cisco.com/go/cvo further information about the solution, its architecture, and its components.
Cisco IOS® Software PKI provides certificate management to support security protocols such as IP Security (IPsec), Secure Shell (SSH) Protocol, and Secure Sockets Layer (SSL). As defined in the IPsec protocol, peers must be authenticated during Internet Key Exchange (IKE) phase 1 before secure communication is established. When pairs of Cisco IOS Software routers are configured as IPsec peers, the routers can use pre-shared keys (PSKs) to authenticate each other as part of security establishment. Using PSKs may be a better choice for customers deploying a small to midsize network containing few routers.
As networks become larger in size and scale, PSK configuration becomes very complex, and managing multiple keys is difficult. PKI offers a much more secure and scalable method for midsize to large enterprise deployments-whether a full mesh of security connections for Dynamic Multipoint VPN (DMVPN) or any of the newly supported VPN technologies, or spoke-to-spoke communications, or enterprises deploying site-to-site VPN for hundreds of remote branch offices needing to communicate with each other. PKI reduces management overhead and simplifies the deployment of the network infrastructure by using digital certificate exchange instead of PSKs for device authentication.
Document Scope
This document describes the integration of PKI within the Cisco Virtual Office deployment from a functional perspective. It explains some of the PKI enhancements available in recent Cisco IOS Software releases that strengthen the Cisco Virtual Office infrastructure. This document does not explain the details of PKI, IPsec, or any VPN concepts. You should be familiar with these concepts; for more information, you can refer to the links provided in the References section.
PKI Overview
To help you understand the use of PKI within Cisco Virtual Office, this section provides a brief introduction to PKI.
A PKI is composed of the following entities:
• Peers communicating on a secure network
• At least one certification authority (CA) that grants and maintains certificates
• Digital certificates, which contain information such as the certificate validity period, peer identity information, encryption keys that are used for secure communication, and the signature of the issuing CA
• An optional registration authority (RA) to offload the CA by processing enrollment requests
• A distribution mechanism (such as Lightweight Directory Access Protocol [LDAP] or HTTP) for certificate revocation lists (CRLs)
PKI provides customers with a scalable, secure mechanism for distributing, managing, and revoking encryption and identity information in a secured data network. Each entity (router or PC) participating in the secure communication is enrolled, a process by which the entity generates a Rivest, Shamir, and Adelman (RSA) key pair (one private key and one public key) and has its identity validated by a trusted entity (also known as a CA).
After each entity enrolls in a PKI, every peer (also known as an end host) in a PKI is granted a digital certificate that has been issued by a CA. When peers must negotiate a secured communication session, they exchange their digital certificates. Using the information in the certificate, a peer can validate the identity of another peer and establish an encrypted session with the public keys contained in the certificate.
RSA Key Overview
An RSA key pair consists of a public key and a private key. When setting up a PKI, the router (also called the certificate client) must include the public key in the certificate enrollment request. After the certificate request has been granted, the public key is included in the certificate so that peers can use it to encrypt data that is sent to the router. The private key is kept on the router and used both to decrypt the data sent by peers and to digitally sign transactions when negotiating with peers.
RSA key pairs contain a key modulus value. The modulus determines the size of the RSA key. The larger the modulus, the more secure the RSA key. However, keys with large modulus values take longer to generate, and encryption and decryption operations take longer with larger keys.
Certificate Authority
A CA, manages certificate requests and issues certificates to participating network devices. These services provide centralized key management for the participating devices and are explicitly trusted by the receiver to validate identities and to create digital certificates. Before any PKI operations can begin, the CA generates its own public key pair and creates a self-signed CA certificate; thereafter, the CA can sign certificate requests and begin peer enrollment for the PKI.
The CA can be a third-party vendor such as Microsoft or VeriSign or a Cisco IOS Certificate Server performing the role of a CA. The deployment described in this guide uses the Cisco IOS Certificate Server.
Recommended Platforms and Images
Images based on Cisco IOS Software Release 12.4(15)T are recommended for the Cisco IOS Certificate Server and Subordinate Certificate Server. The following platforms are suggested for various PKI roles:
CA: Cisco 1800 Series, 2800 Series, or 3800 Series Integrated Services Router running the Cisco IOS Certificate Server or Microsoft Certificate Authority.
Cisco Virtual Office hubs: Cisco 3800 Series Integrated Services Router or Cisco 7200 Series Router.
Cisco Virtual Office spokes: Cisco 871 Integrated Services Routers and above. For the Cisco 881 Integrated Services Router, Cisco IOS Software Release 12.4(20)T is required.
Deployment
The CA is best placed in the subnet connected behind the management VPN gateway. The reason is that PKI certificates are crucial for Cisco Virtual Office remote spokes to establish a DMVPN tunnel with data gateways for corporate access. Initially, the spokes can be enrolled with CA as part of in-house provisioning before shipment to the remote user. If PKI certificates have expired or become invalid, the tunnel cannot be set up for corporate access. Keeping the CA under the management subnet will give the spokes secure access through the management tunnel for new enrollment or reenrollment if certificates expire or become invalid. If the certificate from the same CA is used to set up secure connections with the management and data gateways and the certificate in the spoke becomes invalid, the management tunnel will also fail. Hence it is recommended to use different CAs to set up secure connections with management and data gateways.
Digital certificates are issued to each router, including the hub and spokes. Digital certificates are very difficult to spoof, so the use of the certificates for PKI authentication helps ensure that no unauthorized spokes are connected to the VPN. Unless marked as exportable, the RSA keys cannot be exported, so RSA keys cannot be transferred to another router.
Now we will look at how to configure the CA and the routers as PKI clients. As mentioned earlier, we can use a CA provided by a third-party vendor such as Microsoft or VeriSign, or a Cisco IOS Certificate Server. The following Cisco Virtual Office deployment uses the Cisco IOS Certificate Server; this guide does not discuss the Microsoft Certificate Authority or other third-party CAs.
Note: The Cisco IOS Certificate Server will be used to represent the CA in the remainder of this document.
Configuring the Cisco IOS Certificate Server
The first step in PKI deployment is to bring up the Cisco IOS Certificate Server, which is a router running Cisco IOS Software with IP connectivity enabled to reach resources such as Network Time Protocol (NTP), Trivial File Transfer Protocol (TFTP), and Domain Name System (DNS) servers necessary for proper functioning. Cisco IOS Certificate Server must be configured with ip http server to support enrollments done using Simple Certificate Enrollment Protocol (SCEP). This section describes only configurations relevant to Cisco IOS Certificate Server.
This configuration example uses a Cisco 2811 Integrated Services Router running Cisco IOS Software Release 12.4(15)T5.
! !!! hostname and domain name form a fully qualified domain name in certificates !!!
hostname cvo-pki-cs
ip domain name cisco.com
! !!! clock must be in sync between Cisco IOS Certificate Server and the clients, including timezone !!!
clock timezone PST -8
clock summer-time PDT recurring
ntp server 10.1.1.101
! !!! FTP access configuration for storing .crt, .cnm, and .crl files in external FTP server !!!
ip ftp username ftpusr
ip ftp password cisco
ip host ftpserver 10.1.1.100
! !!! To process enrollment requests and issue certificates !!!
ip http server
!
!!! RSA key pair is generated automatically when enabling Cisco IOS Certificate Server using 1024 bits. Optionally, RSA keys with the rsakeypair name matching the certificate server can be generated manually with different options such as higher modulus, exportable, etc. Keys must be generated with the exportable option to export them for later restoration in case of certificate server failure. However, the user needs to take the utmost care to store keys securely as it would be easy for someone to get access with the keys. !!!
cvo-pki-cs(config)#crypto key generate rsa general-keys label cvo-pki-cs modulus 1024 exportable
!!! The following Cisco IOS Certificate Server configuration uses a complete database that stores separate .crt and .cnm files for each certificate it issues. In general, router flash memory has less capacity to store all these files; hence, only essential files should be stored in router flash memory, and all other files can be stored on an external FTP server. The lifetime values shown here are for illustration purposes only. !!!
!
crypto pki server cvo-pki-cs !!! PKI server name must match rsakeypair name !!!
database level complete
database archive pkcs12 password cisco123 !!! Keys can be auto archived !!!
issuer-name cn=cvo-pki-cs,ou=cvo !!! Identification of the PKI server within Cisco Virtual Office !!!
grant auto !!! Certificate server automatically grants enrollment requests from routers !!!
lifetime crl 24 !!! Every 24 hours the CRL database is renewed and published !!!
lifetime certificate 60 !!! Issued router (client) certificates are valid for 60 days !!!
lifetime ca-certificate 75 !!! Root (certificate server) certificate is valid for 75 days !!!
cdp-url http://10.1.1.100/cvo-pki-cs.crl !!! PKI clients get CRL from this location !!!
database url ftp://10.1.1.100/pki !!! All files are stored on this external FTP server !!!
!
!!! The following trustpoint configuration is autogenerated when Cisco IOS Certificate Server is enabled. Optionally, this trustpoint configuration can be created manually before enabling Cisco IOS Certificate Server. !!!
!
crypto pki trustpoint cvo-pki-cs
enrollment url http://cvo-pki-cs:80 !!! Optional !!!
serial-number
revocation-check crl
rsakeypair cvo-pki-cs !!! rsakeypair name must match PKI server name !!!
!
!!! To enable the Cisco IOS Certificate Server, enter a "no shut" command in server config mode. !!!
!
cvo-pki-cs(cs-server)#no shutdown
!
Note: It is recommended to use the database archive command with strong password to archive RSA keys in a pkcs12 file instead of generating RSA keys with exportable option as mentioned earlier.
When Cisco IOS Certificate Server is enabled, this is how the root CA certificate appears:
cvo-pki-cs#show crypto pki certificates
CA Certificate !!! Root CA certificate !!!
Status: Available
Certificate Serial Number: 0x1
Certificate Usage: Signature
Issuer:
cn=cvo-pki-cs
ou=cvo
o=Cisco Systems
c=US
ea=admin@cisco.com
Subject:
cn=cvo-pki-cs
ou=cvo
o=Cisco Systems
c=US
ea=admin@cisco.com
Validity Date:
start date: 11:38:04 PDT May 01 2008
end date: 11:38:04 PDT Jul 15 2008
Associated Trustpoints: cvo-pki-cs
Storage: nvram:cvo-pki-cs#1CA.cert
cvo-pki-cs#
Now, save the configuration.
Configuring Cisco Virtual Office Routers for PKI
After the Cisco IOS Certificate Server is set up, the PKI client can enroll with the certificate server and download client certificates. For Cisco Virtual Office, both the hub and spoke are PKI clients, and they must enroll with the certificate server before using PKI authentication.
This configuration example uses a Cisco 881 Integrated Services Router running Cisco IOS Software Release 12.4(20)T.
Note: For certificates to be valid, the clock on the certificate server and clients must be in sync. All clients must have IP reachability to the certificate server and use the same clock source as the certificate server.
!
hostname cvo-spoke
ip domain name cisco.com
clock timezone PST -8
clock summer-time PDT recurring
ntp server 10.1.1.101
!
!!! Generate RSA keys in the client router. If not generated now, keys will be autogenerated during trustpoint authentication. !!!
cvo-spoke(config)#crypto key generate rsa general-keys modulus 1024
!!! Create the following trustpoint configuration in config mode in the router !!!
!
ip host cvo-pki-cs 10.1.1.105
!
crypto pki trustpoint cvo-pki-cs
enrollment url http://cvo-pki-cs:80
serial-number
!!! Using CRL check is desirable for Cisco Virtual Office hubs because it prevents any unauthorized router from setting up a secure session with Cisco Virtual Office hubs. The advantage of using CRL check improves the security of Cisco Virtual Office spokes when spoke-to-spoke communication is permitted. However, it can be disabled for Cisco Virtual Office spokes if they connect to the hub only by issuing a revocation-check none command. !!!
revocation-check crl
!!! To send enrollment requests securely, the router should use the internal address as the source when communicating with the certificate server. As defined in the Cisco Virtual Office spoke configuration, only the internal addresses are secured. !!!
source-interface Vlan10
!!! The router will attempt reenrollment after 60 percent of lifetime expires. If shorter lifetimes, such as 60 days, are used for router certificates, the auto-enroll period can be extended to 80 or 90 percent to avoid frequent reenrollment. !!!
auto-enroll 60
!!! Authenticate the client router with the certificate server, to download the root CA certificate so that the router will encrypt the enrollment request with the certificate server's public key. !!!
cvo-spoke(config)#crypto pki authenticate cvo-pki-cs
!!! Now enroll with the certificate server in config mode. Including the serial number and IP address in the subject name and password fields is optional. !!!
cvo-spoke(config)#crypto pki enroll cvo-pki-cs
!!! After the certificate is received, this message will pop up in the console !!!
"%PKI-6-CERTRET: Certificate received from Certificate Authority"
!!! Now save the configuration to make sure the certificate is stored !!!
When enrolled, the router should have two certificates. One is its own certificate signed by the Cisco IOS Certificate Server, and the other is the root CA certificate. An example of output follows:
cvo-spoke#show crypto pki certificates
Certificate !!! Router certificate !!!
Status: Available
Certificate Serial Number (hex): 04
Certificate Usage: General Purpose
Issuer:
cn=cvo-pki-cs
ou=cvo
o=Cisco Systems
c=US
ea=admin@cisco.com
Subject:
Name: cvo-spoke.cisco.com
Serial Number: FHK09312145
serialNumber=FHK09312145+hostname=cvo-spoke.cisco.com
CRL Distribution Points:
http://10.1.1.100/cvo-pki-cs.crl
Validity Date:
start date: 11:36:17 PDT May 01 2008
end date: 11:38:04 PDT Jun 30 2008
renew date: 11:38:04 PST Jun 15 2008
Associated Trustpoints: cvo-pki-cs
CA Certificate !!! Root CA certificate !!!
Status: Available
Certificate Serial Number (hex): 01
Certificate Usage: Signature
Issuer:
cn=cvo-pki-cs
ou=cvo
o=Cisco Systems
c=US
ea=admin@cisco.com
Subject:
cn=cvo-pki-cs
ou=cvo
o=Cisco Systems
c=US
ea=admin@cisco.com
Validity Date:
start date: 11:38:04 PDT May 01 2008
end date: 11:38:04 PDT Jul 15 2008
Associated Trustpoints: cvo-pki-cs
cvo-spoke#
A similar trustpoint configuration is required in the hub router for enrolling with the CS, and is shown as follows. When the certificate is received, both hub and spoke can use this certificate for PKI authentication.
crypto pki trustpoint cvo-pki-cs
enrollment url http://cvo-pki-cs:80
serial-number
ip-address none
revocation-check crl !!! CRL checking enabled in DMVPN hub !!!
auto-enroll 60
Configuring Conditional CRL Check
In Cisco Virtual Office, spoke-to-spoke router connections are permitted, and this can allow unauthorized spokes to set up secure connections with authorized spokes within the network. It is advisable to revoke the router certificates for spokes that become unauthorized-for example, when a Cisco Virtual Office user no longer works for the enterprise. Please refer to Appendix B for examples of how to revoke certificates. In these cases, the authorized spokes need to check the CRL database periodically to identify spokes that are invalid. However, the CRL database is typically placed behind the management gateway. Hence, the routers must set up a secure connection to the management gateway to access the CRL database. After the trustpoint in a spoke is configured to check the CRLs, the spoke needs to access the CRL database to bring up any secure connection, including the secure connection to the management gateway. If the management tunnel is cleared or the spoke is reloaded, the secure connection to the management gateway will fail because the CRL cannot be downloaded.
As mentioned earlier, spokes do not need to check the validity of VPN gateway certificates because they reside within the secured network and are supposed to be valid at all times. To allow spokes to check CRLs except for specific certificates such as gateways, use the CLI to enter the match certificate command with the skip revocation-check keyword.
Note: Only the relevant configuration is shown here. The rest of the configuration presented earlier in the document is still required.
Trustpoint config in management gateway:
-------------------------------------------------------
crypto pki trustpoint cvo-pki-cs
subject-name cn=cvo_smg !!! Certificate is generated with identification !!!
revocation-check crl
Trustpoint config in Cisco Virtual Office spoke:
-----------------------------------------
!!! The following spoke configuration will disable CRL checking for the management gateway but allow CRL checking for all other connections !!!
crypto pki trustpoint cvo-pki-cs
revocation-check crl
match certificate check-crl skip revocation-check !!! Spoke will skip CRL checking for management gateway !!!
!
crypto pki certificate map check-crl 1
subject-name co cn=cvo_smg !!! Peer certificate is verified for this subject-name !!!
!
Configuring Certificate Rollover
Cisco Virtual Office routers (clients) can renew their router certificates by reenrolling with the Cisco IOS Certificate Server before the existing router certificates expire. The timing of reenrollment is based on the auto-enroll configuration as discussed earlier. The validity of a router certificate is always bound by the lifetime of the root CA certificate. During any enrollment, the validity of the router certificate cannot be extended beyond the lifetime of the root CA certificate. However, a router can reenroll itself until the validity of the router certificate expires along with root CA certificate. After the root CA certificate expires, the router cannot successfully reenroll further. Either configure the certificate server certificate with a larger lifetime initially to allow longer validity or obtain a new certificate by reconfiguring both the certificate server and all routers as discussed earlier.
With Cisco IOS Software Release 12.4(4)T and later, the root CA certificate can be rolled over by the certificate server, a process by which the certificate server generates a shadow (or rollover) root CA certificate before the existing root CA certificate expires. Though the validity of the shadow root CA certificate starts at the expiration of the existing root CA certificate, the certificate server keeps both the root certificates for an overlapping period (or rollover period). During this overlapping period, all routers will reenroll with the certificate server and download the shadow root CA certificate along with shadow router certificates for further use. After the existing certificate expires, both the certificate server and the routers will delete the expired certificate and start using the shadow (or rolled over) certificate. In this way, root CA certificate rollover helps Cisco Virtual Office routers keep their certificates valid without incurring additional overhead for administrators to reconfigure.
To use certificate rollover, configure the certificate server as follows:
crypto pki server cvo-pki-cs
auto-rollover 5 !!! Five-day overlapping period for keeping shadow certificate !!!
No specific configuration is required in client routers; they will use the same process for reenrolling their router certificates. The routers will then determine whether the validity period of their certificates ends at the same time as the validity period of the root CA certificate. If so, they will download the shadow root CA certificate along with shadow router certificates. Shadow certificates are identified by the word rollover next to the certificate title.
Rollover can be performed manually by reenrolling during the rollover period.
cvo-spoke(config)#crypto pki enroll cvo-pki-cs
Trustpoint cvo-pki-cs is in rollover mode.
If you successfully re-enroll this trustpoint,
a shadow certificate will be obtained.
This will not effect the router certificate.
Do you want to continue with re-enrollment? [yes/no]: yes
Shadow enrollment will begin in 30 seconds and will
proceed in the background. You will be prompted to save
the configuration when the shadow enrollment completes
cvo-spoke#show crypto pki certificates cvo-pki-cs
Router Certificate (Rollover) !!! Shadow router certificate !!!
Status: Available
Certificate Serial Number: 2F
...
Validity Date:
start date: 11:38:04 PDT Jul 15 2008 !!! Validity period starts later !!!
end date: 11:38:04 PDT Sep 13 2008
Associated Trustpoints: cvo-pki-cs
CA Certificate (Rollover) !!! Shadow root CA certificate !!!
Status: Available
Certificate Serial Number: 23
...
Validity Date:
start date: 11:38:04 PDT Jul 15 2008
end date: 11:38:04 PDT Sep 28 2008
Associated Trustpoints: cvo-pki-cs
cvo-spoke(config)#
Note: If the database archive command is configured in the certificate server, remember to store the pkcs12 file in a secure location after the certificate server generates rollover keys and certificates.
Managing the Certificate Database
As shown in the certificate server configuration earlier, the database level complete command creates .crt and .cnm files for each certificate issued, requiring a very large storage capacity when hundreds of routers are enrolling with the certificate server. With Cisco IOS Software Release 12.4(2)T and later, this database can be split and stored in different locations for different type of files. For example, .crl and .ser files are essential for running the certificate server, so they can be stored within the certificate server router flash memory. The certificate files .crt and .cnm are huge, so they can be stored on an external FTP server. CRLs can also be stored on an external HTTP server, from which routers can download them.
Note: This configuration is optional, depending on user requirements for the database level and the size of the network.
!!! The following configuration shows the .crt and .cnm file types stored on an FTP server and all other file types-.ser, .crl, and .p12-stored by default in flash memory. !!!
crypto pki server cvo-pki-cs
database level complete
database url flash:
database url cnm ftp://10.1.1.100/pkifiles
database url crl publish ftp://10.1.1.100/pkifiles !!! CRL is published on the FTP server !!!
database url crt ftp://10.1.1.100/pkifiles
At this point, integration of PKI with Cisco Virtual Office is complete. This configuration may be good enough for a smaller Cisco Virtual Office network running with a single PKI server. For larger networks distributed across multiple locations, PKI servers can also be configured to form a hierarchy using subordinate certificate servers or RA mode certificate servers. Please refer to http://www.cisco.com/en/US/products/ps6664/products_ios_protocol_option_home.html for information about the various roles of PKI servers.
Following is just a portion of the configuration for a subordinate certificate server deployed with a root certificate server for Cisco Virtual Office. It follows the same configuration procedures as the root certificate server except the routers use trustpoint configuration for the subordinate certificate server.
Configuring a Subordinate Certificate Server
Because the root RSA key pairs are extremely important in a PKI hierarchy, it is often advantageous to keep them offline or archived. To support this requirement, PKI hierarchies allow for subordinate CAs that have been signed by the root authority. In this way, the root authority can be kept offline (except to issue occasional CRL updates), and the subordinate CA can be used during normal operation.
The Subordinate Certificate Server feature allows you to configure a subordinate certificate server to grant all or certain SCEP enrollment or manual certificate requests.
The subordinate certificate server provides all the same features as a root certificate server. Following are some points to remember when adding a subordinate certificate server:
• Enrollment requests that come from a subordinate certificate server must always be manually granted in the root certificate server.
• The root certificate server should be a Cisco IOS Certificate Server.
The same steps as for configuring the Cisco IOS Certificate Server described earlier are required to set up a subordinate certificate server: IP reachability to the root certificate server; access to other resources such as NTP, FTP, and DNS servers; IP HTTP server configuration; RSA keys generated; etc.
Note: Only the relevant configuration information is shown here; all other configuration details are required as for the root certificate server.
!!! The following trustpoint configuration should be created manually before enabling subordinate certificate server to provide a valid enrollment URL to the root certificate server !!!
crypto pki trustpoint cvo-pki-subcs
enrollment url http://cvo-pki-cs:80 !!! Enrolls with root certificate server !!!
serial-number
revocation-check crl
rsakeypair cvo-pki-subcs
!
crypto pki server cvo-pki-subcs
database level complete
database archive pkcs12 password cisco123
grant auto !!! Enrollment requests are automatically granted !!!
lifetime crl 24
lifetime certificate 45 !!! Valid period for router certificates !!!
lifetime ca-certificate 60 !!! Validity must match lifetime certificate defined in root certificate server !!!
cdp-url http://10.1.1.100/cvo-pki-subcs.crl
mode sub-cs !!! Certificate server runs in subordinate certificate server mode!!!
database url flash:
!
!!! The following configuration shows the client routers using a subordinate certificate server trustpoint. The rest of the configuration is still needed !!!
!
ip host cvo-pki-subcs 10.1.1.102
!
crypto pki trustpoint cvo-pki-subcs
enrollment url http://cvo-pki-subcs:80
serial-number
revocation-check crl
source interface Vlan10
auto-enroll 60
!
!!! The subordinate certificate server is enabled by entering the "no shut" command in server config mode. !!!
!
cvo-pki-subcs(cs-server)#no shutdown
!
Configuring Certificate Rollover for the Subordinate Certificate Server
If certificate rollover is set up for the root certificate server, it should also be set up for the subordinate certificate server because all the routers will enroll with the subordinate certificate server. From the perspective of the root certificate server, the subordinate certificate server is also a client. Just as routers keep shadow certificates for their own certificates and also for the root CA certificate, the subordinate certificate server also downloads shadow certificates for itself and the root certificate server during rollover. Although enrollment requests that the root certificate server receives from the subordinate certificate server must be granted manually, the root certificate server can automatically grant rollover enrollment requests from the subordinate certificate server.
!!! The following configuration is needed in the root certificate server !!!
!
crypto pki server cvo-pki-cs
grant auto rollover ca-cert !!! Root certificate server automatically grant rollover requests from subordinate certificate server !!!
auto-rollover 5 !!! Overlapping period to keep shadow certificates !!!
!
!!! The following configuration is needed in subordinate certificate server !!!
!
crypto pki server cvo-pki-subcs
auto-rollover 4 !!! Four-day overlapping period to keep shadow certificates !!!
As earlier, no additional configuration is needed in Cisco Virtual Office routers for certificate rollover.
Note: The rollover period in the root