While all trustpoint configurations should be reviewed to ensure they are configured for their desired purpose, the primary risk is when using:
- The ASA/FTD devices as a remote access VPN endpoint.
- Client certificate authentication where certificates are issued by certificate authority A.
- A certificate for the identity of the ASA/FTD device issued by certificate authority B.
The intention would be that the administrators of the ASA/FTD VPN endpoint only wish to consider client certificates issued by certificate authority A. For example, the client-issued certificates could come from a company’s private CA (CA A), while the ASA/FTD identity certificate may have been issued by a public CA (CA B).
To determine whether a Cisco ASA or FTD device is affected by the issue described in this advisory, use this process:
1) Confirm if the device is configured to allow remote access VPN.
|Cisco ASA Feature
|AnyConnect IKEv2 Remote Access (with client services)
||crypto ikev2 enable <interface_name> client-services port <port #>
|AnyConnect SSL VPN
|Clientless SSL VPN
Alternatively, on FMC, go to Devices -> VPN -> Remote Access and see if any profiles exist.
If enabled, proceed to the next step.
2) Confirm if using client certificate authentication.
Administrators can use the show running-config all tunnel-group command from either the ASA CLI or FTD CLI to determine whether any of the connection profiles are using an authentication method that contains a certificate. If either the Authentication, Authorization and Accounting (AAA) or Security Assertion Markup Language (SAML) 2.0 method alone is used, the device is not affected. The following example shows the output of the command for an ASA device that is using both AAA and client certificate authentication:
ciscoasa# show running-config all tunnel-group
authentication aaa certificate
Alternatively, on FMC, go to Devices -> VPN -> Remote Access and click the Remote Access profile name. For the different connection profiles, examine the AAA column; if any of the Authentication fields indicate Client Certificate Only or Client Certificate & AAA, then client certificates are in use. Proceed to the next step.
Note: If alternative authentication methods are configured, those authentication methods will still need to be fulfilled to pass authentication and be granted access to the network.
3) Determine if using a certificate for the identity of the ASA/FTD issued by a certificate authority that the administrator doesn't control.
Administrators can first use the show running-config ssl | include trust-point command to identify the device’s identity certificate used on the remote access VPN-enabled interface:
ciscoasa# show running-config ssl | include trust-point
ssl trust-point IDENTITY outside
In the previous example, the interface named outside is associated with the identity certificate configured within the trustpoint named IDENTITY.
Administrators can view the certificates included in this trustpoint and specifically look at the Subject Name of the CA Certificate to identify whether this certificate has been issued by a public CA:
ciscoftd# show crypto ca certificate IDENTITY
cn=Go Daddy Secure Certificate Authority - G2
start date: 07:16:53 UTC Jul 26 2020
end date: 07:16:53 UTC Jul 26 2021
Associated Trustpoints: FPR2100-FTD.cisco.com
Alternatively, on FMC, go to Devices -> VPN -> Remote Access and click the Remote Access profile name. Click Access Interfaces. This will show you the identity certificate presented on the remote access VPN interface in the SSL Global Identity Certificate field.
When a new certificate is imported to the configuration, the default settings for the trustpoint usage are for ipsec-client and ssl-client validation, so by default, that trustpoint can be used to authenticate VPN users. Administrators should review all their trustpoint usage configurations. If the trustpoint holds the certificates for server authentication, that trustpoint should be configured with the validation-usage ssl-server configuration command. Any trustpoint not used explicitly for client authentication should have the no validation-usage configuration applied as per the following procedures:
For ASA, administrators can log into the device and reconfigure the trustpoint using the validation-usage command:
crypto ca trustpoint <name of identity trustpoint>
For FTD managed via FMC, administrators can use FlexConfig. Proceed with the following steps:
1. Validate the configuration of the trustpoint that needs reconfiguring via the show running-config all crypto ca trustpoint FTD CLI command and confirm that validation-usage is set to ipsec-client ssl-client.
2. On FMC, go to Objects -> Object Management -> FlexConfig -> FlexConfig Object, and fill in the Name and Description fields. Complete the text box with the command as shown in the following example. Note you could define the TrustPointName as a variable or just enter the name of the TrustPointName you wish to alter:
Description: no validation-usage ipsec-client ssl-client
crypto ca trustpoint TrustPointName
3. Apply FlexConfig to the affected devices by selecting Devices -> FlexConfig.
4. Click New Policy, create a name, and select the devices to assign the policy to. On the next screen, select Add FlexConfig Object and click the object you created in the previous steps; in this example, NoValidationUsage.
5. Save the FlexConfig.
6. Deploy the FlexConfig.
7. Validate the configuration was a success by logging into the device and issuing the show running-config all crypto ca trustpoint FTD CLI command. Under the public trustpoint, it should say no validation-usage.
If the client certificates are issued from a different CA than the identity certificate, that trustpoint will still be required to have the default settings of validation-usage ipsec-client ssl-client or just validation-usage ssl-client, depending on the designed usage.
For FTD managed via Firepower Device Management (FDM), there is currently no way to alter the trustpoint configuration via FlexConfig. A new version will be released that supports the ability to reconfigure the trustpoint.