However, it is relatively safer to configure this, than not having an authoritative source of time at all. While configuring this, it is key to understand that the system clock will go out of sync if the system battery dies, and PKI will start trusting an out-of-sync clock. clock calendar-valid acts as a safeguard in such situations. At this stage, PKI timers will stop functioning, which in turn leads to Certificate Renewal/Rollover failures. This can be configured along with NTP, and the key reason for doing this is to keep the system clock authoritative when a router reloads, for example due to a power outage, and the NTP servers are not reachable. In IOS, the hardware clock can be marked as authoritative using: config terminal !! define an access-list to which the local time-server will serve time-synchronization services !! first allow the local router to synchronize with the local time-server !! optinally, an access-list can be configured to restrict NTP clients !! optionally, NTP authentication can be enforced In small-scale PKI deployment, the PKI server can be configured as an NTP server for its PKI clients: configure terminal
IOS can also be configured as an NTP server, which will mark the local system clock as authoritative. !! optionally an access-list can be configured to restrict time-updates from a specifc NTP server !! optional, if the NTP Server requires the clients to authenticate themselves An IOS Router can be configured as an NTP client to a well-known and stable NTP server in the network: Synchronising the system clock with a Time Server is the only true way of making the system clock trustworthy. Without an authoritative source of time, PKI server may not function as expected, and it is highly recommended to make the clock on IOS authoritative using these methods: Hence, in IOS, the clock must be made authoritative or trustworthy. The system clock defines whether a certificate is valid or not. One of the foundations of PKI infrastructure is Time. NA īefore getting into PKI Server configuration, the administrator must understand these core concepts. PKI ClientĪny device requesting for a certificate based on a resident public-private key-pair to prove its identity to other devices is known as a PKI client.Ī PKI client must be capable of generating or storing a a public-private key-pair such as RSA or DSA or ECDSA.Ī certificate is a proof of identity and validity of a given public-key, provided the corresponding private-key exists on the device. This way, RA stands between the PKI clients and the CA, thus protecting the CA from any kind of denial of service attacks. The main role of an RA is to offload basic client certificate request validation from the CA, and protect the CA from direct exposure to the clients. RA does not issue certificates to PKI clients, instead it decides which PKI-Client can or cannot be issued a certificate by the Sub-CA or the Root-CA.
PKI defines a special certificate authority known as Registration Authority (RA), which is responsible for authorizing the PKI clients from enrolling to a given Sub-CA or Root-CA. However, in an enterprise deployment with more than 3 levels of certificate authorities may become difficult to manage. PKI imposes no limit on the number of Sub-CAs in a given hierarchy. Evidently, a Sub-CA certificate is issued by the CA, which is one level above. In PKI Trust-hierarchy all the certificate authorities below Root are known as Subordinate Certificate Authorities (Sub-CA). Because the Root-CA is at the top of the hierarchy, it has a self-signed certificate. PKI is based on trust, and trust-hierarchy starts at Root Certificate Authority (Root-CA). PKI InfrastructureĬertificate Authority (CA), also referred to as PKI Server throughout the document, is a trusted entity that issues certificates.
It addresses IOS PKI initial design and deployment considerations. This document describes IOS PKI Server and client functionalities in detail.