Trust points, also known as trust anchors, are cryptographic entities that represent a trusted root or intermediate Certificate
Authority (CA) whose certificates are implicitly trusted by the device. These trust points are used to validate the authenticity
of peer certificates during the IKEv2 handshake.
Installed Trust Points:
These are certificates (Root CA, Intermediate CA, or end-entity) that have been loaded onto the device's certificate store.
The device generally trusts these certificates for various PKI operations.
Trust Points Configured Under IKEv2 Profile:
For IKEv2, specific trust points must be explicitly referenced within the IKEv2 profile configuration. This tells the IKEv2
engine which CAs it should use as trusted anchors when validating the certificate presented by the peer.
Consider two devices, an Initiating Device and a Responding Device, attempting to establish an IKEv2 tunnel using certificates.
During the IKEv2 negotiation, the Responding Device typically sends a Certificate Request payload, indicating which Certificate
Authorities (CAs) it trusts. These trusted CAs are derived from the trust points installed on the device.
The Initiating Device then selects an appropriate identity certificate from its own installed certificates that is issued
by one of the CAs trusted by the Responding Device. It constructs and sends the necessary certificate chain (its identity
certificate and its issuing CA certificates) to the Responding Device.
It's important to note that the certificate chain sent by the Initiating Device can be optimized. If the Initiating Device
determines that the Responding Device already possesses certain intermediate CA certificates (e.g., if they are installed
on the Responding Device), it might omit those intermediate certificates from the chain it sends, assuming the Responding
Device can build the chain locally.
Below is an example scenario.
Trust Points Installed on Device A
crypto pki trustpoint <root-tp-1> (Contains root certificate 1) (Root CA 1)
crypto pki trustpoint <root-tp-2> (Contains root certificate 2) (Root CA 2)
crypto pki trustpoint <root-tp-3> (Contains root certificate 3) (Root CA 3)
crypto pki trustpoint <intermediate-tp-2> (Contains intermediate certificate issued by Root CA 2) (Intermediate CA 2)
crypto pki trustpoint <intermediate-tp-3> (Contains intermediate certificate issued by Root CA 3) (Intermediate CA 3)
crypto pki trustpoint <secondary-intermediate-tp-3> (Contains secondary intermediate certificate issued by Intermediate CA
3) (Secondary Intermediate CA 3) + ID certificate issued by Secondary Intermediate CA 3 (ID 3)
Trust Points Configured Under IKEv2 Profile on Device A
pki trustpoint <secondary-intermediate-tp-3> (Secondary Intermediate CA 3) + (ID 3)
pki trustpoint <root-tp-1> (Root CA 1)
pki trustpoint <root-tp-2> (Root CA 2)
pki trustpoint <root-tp-3> (Root CA 3)
Trust Points Installed on Device B
crypto pki trustpoint <root-tp-1> (Contains root certificate 1) (Root CA 1)
crypto pki trustpoint <root-tp-2> (Contains root certificate 2) (Root CA 2)
crypto pki trustpoint <root-tp-3> (Contains root certificate 3) (Root CA 3)
crypto pki trustpoint <intermediate-tp-1> (Contains intermediate certificate issued by Root CA 1) (Intermediate CA 1) + ID
certificate issued by Intermediate CA 1 (ID 1)
Trust Points Configured Under IKEv2 Profile on Device B
pki trustpoint <intermediate-tp-1> (Intermediate CA 1) + (ID 1)
pki trustpoint <root-tp-1> (Root CA 1)
pki trustpoint <root-tp-2> (Root CA 2)
pki trustpoint <root-tp-3> (Root CA 3)
With the above config Device A is able to connect to Device B because the common trust anchors are picked from trust points
installed on the box instead of trust points configured in IKEv2 profile. But note that verification of certificate happens
against the trust points configured under IKEv2 profile and certificates sent by the peer.
During negotiation, Device B asks Device A to send an ID certificate trusted by either Root CA 1 or Root CA 2 or Root CA 3.
Device A finds out it has an ID cert issued by Secondary Intermediate CA 3 and Secondary Intermediate CA 3 in turn issued
by Intermediate CA 3 and in turn Intermediate CA 3 issued by Root CA 3.
So, Device A sends 3 certificates to Device B.
-
ID 3
-
Secondary Intermediate CA 3
-
Intermediate CA 3
Now, Device B sends these 3 certificate to PKI for verification. PKI verifies ID 3 using Secondary Intermediate CA 3 and Secondary
Intermediate CA 3 using Intermediate CA 3 as they already came to PKI as a chain.
Now PKI has to verify Intermediate CA 3, so it looks in to all the trust points configured under IKEv2 profile and it figures
out suitable trust point based on issuer name. PKI finds out <root-tp-3> as suitable trust point as Root CA 3 is issuer of
Intermediate CA 3 and verification completes.
Scenario:
As soon as a new trustpoint <intermediate-tp-3> which contains Intermediate CA 3 is installed on Device B, the Device A no
more able to connect to Device B.
Because, this time Device A sends 2 certificates to Device B instead of 3 certificates because Intermediate CA 3 is now common
between Device A and Device B.
1.ID 3
2.Secondary Intermediate CA 3
Now, Device 2 sends these 2 certificates to PKI for verification. PKI verifies
ID 3 using Secondary Intermediate CA 3 as they already came to PKI as chain
Now PKI has to verify Secondary Intermediate CA 3, so it looks into all the trust points configured under IKEv2 profile with
issuer name. PKI couldn’t find a suitable trust point under IKEv2 profile and verification failed.
Solution :
As soon as the trust point <intermediate-tp-3> which contains Intermediate CA 3 is configured under IKEv2 profile, PKI finds
the suitable trust point with issuer match and verification is success and Device A is able to connect to Device B.