Digital Certificate Issues
Digital Certificate can be used to authenticate peers for both LAN-to-LAN and Remote Access VPN connections. As the creation and usage of Certificate for peer authentication is very similar for both LAN-to-LAN and Remote Access VPN connections, this section describes the Digital Certificate implementation only for the Remote Access VPN connection. One important point to note is that when a digital certificate is used for the peer authentication, both Remote Access VPN and LAN-to-LAN connections perform Main Mode negotiation. As you have seen before, with the pre-shared key, however, although the LAN-to-LAN connection performs Main Mode negotiation, Remote Access VPN connection uses Aggressive Mode negotiation for phase I tunnel establishment. The sections that follow provide detailed information on these topics:
Digital certificate on the VPN client
Digital certificate on the VPN concentrator
Troubleshooting steps
Digital Certificate on the VPN Client
Work through the following steps to configure a VPN client with the digital certificate:
Step 1. Enroll or import the CA root certificate and digital certificate for the VPN client connection entry by clicking on Certificates > Enroll or Import and refer to the following links:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/client/4_6/ugwin/vc6.htm#wp1173362
http://www.cisco.com/en/US/partner/products/sw/secursw/ps2308/products_configuration_example09186a00801c8c41.shtml
Step 2. Under the Certificate Tab, Select Verify. This will check if the certificate has a complete chain and its validity dates are acceptable.
Step 3. Assign the certificate to the connection entry through the Authentication tab by selecting the Certificate Authentication radio button and selecting the certificate from the drop-down list of Certificate name.
Step 4. Optionally choose Send CA Certificate Chain option if you want to send the chain of the certificate to the Concentrator.
Digital Certificate on the VPN Concentrator
Just as with a VPN Client, you must import the CA root and digital certificate on the VPN Concentrator. Work through the following steps to import the CA root certificate and the digital certificate on the VPN Concentrator:
Step 1. On VPN 3000 Concentrator GUI, go to Administration > Certificate Management, and import/install the CA root certificate and the VPN Concentrator. Identity the certificate (Digital certificate) by using the instructions in the following links:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/4_7/admon/certCAn.html
http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_tech_note09186a00800946f1.shtml
http://cisco.com/en/US/products/hw/vpndevc/ps2284/products_tech_note09186a008044acb7.shtml
Step 2. Go to the Administration > Certificate Management page to verify both the root and the to identity the certificates and their validity. The concentrator does not allow the installation of an ID certificate that does not have a complete chain. Remember that the concentrator cannot install an ID cert that was not requested by the specific concentrator. Select the View option of the Identity (ID) certificate to verify its validity. If the certificate validity dates have expired, you will see a message that is similar to this: The certificate is not yet valid. Regenerate the certificate to correct the problem. Also be sure that the VPN Concentrator time is not off by much; otherwise, a valid certificate may be shown as invalid, as the VPN Concentrator time may not fall between the validity dates of the certificate.
Step 3. Go to Configuration > Tunneling and Security > IPsec > IKE Proposals on the VPN Concentrator GUI, and be sure that the VPNClient-3DES-MD5-RSA rule is under ActiveProposals. By default this is not under Active Proposals.
Step 4. Configure a custom or modified IPsec SA that will use the certificates that you have installed and verified by going to the Configuration > Policy Management > Traffic Management > Security Associations > Add page. The Issuer CN field designates the certificates in the SA configuration. The Negotiation Mode must be set to Main Mode. If the client does not have the full certificate chain installed you, may have to send the entire certificate chain. The IKE Proposal must support digital certificates.
Step 5. Group Matching is performed based on one or more fields in the incoming client certificate DN. If you are matching to a group from the OU field in the certificate, the defined group name must match the OU exactly. If you "Default to Group", that group must have an SA that supports certificates. Select the options by going into Configuration > Policy Management > Group Matching > Policy.
Step 6. The group that matches must have an IPsec SA assigned that supports certificates. You can also enable peer identity checking. Be sure that the configuration setting matches the certificates in use by the clients. To configure the group to use the certificate, go to Configuration | User Management | Groups | Modify, which will allow you to modify the group. Click on the IPsec tab, and select IPsec SA from the drop-down list that you have created earlier.
Troubleshooting Steps
As mentioned before, when a certificate is used for IKE phase I authentication, Main mode negotiation takes place between two IPsec peers for both LAN-to-LAN and Remote Access VPN connections. Before looking into the details of how to troubleshoot the IKE phase I negotiation when the Certificate is used, it is important to go through the event log on both the VPN Client and Concentrator and become absolutely comfortable with the sequence of events that takes place to isolate the problem with certification failure.
Example 8-14 shows the event log on the VPN Client with a successful phase 1 Main Mode negotiation.
Example 8-14. Event Log for a Successful Phase I Main Mode Negotiation on VPN Client with Certificate for Authentication
! Following message indicates that the tests for the Certificate Chain, its Validity
! dates and the Presence of the Private Key are successful.
850 16:03:23.964 05/28/05 Sev=Info/4CERT/0x63600013
Cert (cn=HTTS,ou=TAC,o=Cisco,l=San Jose,st=CA,c=US) verification succeeded.
! The VPN Client Sends Main Mode Message 1 with IKE Proposals that required certificate.
! If the VPN Concentrator doesn't have an Active IKE Proposal with Certificate
! Capability, the Negotiations Fails at this stage on the Concentrator.
857 16:03:25.105 05/28/05 Sev=Info/4IKE/0x63000013
SENDING >>> ISAKMP OAK MM (SA, VID(Xauth), VID(dpd), VID(Nat-T), VID(Frag),
VID(Unity)) to 172.16.172.157
! The VPN Client Receives Main Mode Message 2 from Concentrator indicating that the IKE
! Proposal Was OK.
862 16:03:25.198 05/28/05 Sev=Info/4IKE/0x63000014
RECEIVING <<< ISAKMP OAK MM (SA, VID(Frag)) from 172.16.172.157
! VPN Client is sending Main Mode Message 3
865 16:03:25.214 05/28/05 Sev=Info/4IKE/0x63000013
SENDING >>> ISAKMP OAK MM (KE, NON, VID(?), VID(Unity)) to 172.16.172.157
! The VPN Client receives Main Mode Message 4 containing the Cert Request
871 16:03:25.370 05/28/05 Sev=Info/4IKE/0x63000014
RECEIVING <<< ISAKMP OAK MM (KE, NON, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ,
CERT_REQ, VID(Unity), VID(Xauth), VID(?), VID(?)) from 172.16.172.157
! The VPN Client sends Main Mode Message 5 with the Client Cert to the Concentrator.
875 16:03:25.511 05/28/05 Sev=Info/4IKE/0x63000013
SENDING >>> ISAKMP OAK MM *(ID, CERT, CERT_REQ, SIG, NOTIFY:STATUS_INITIAL_CONTACT)
to 172.16.172.157
! The VPN Client receives Main Mode Message 6 Containing the Concentrator Cert.
885 16:03:25.792 05/28/05 Sev=Info/4IKE/0x63000014
RECEIVING <<< ISAKMP OAK MM *(ID, CERT, SIG, VID(dpd)) from 172.16.172.157
! VPN Client validates the Concentrator Cert signed by the right Root certificate
and is
! ready to Start X-AUTH
886 16:03:25.886 05/28/05 Sev=Info/4CERT/0x63600013
Cert (cn=ID from Break,ou=TAC,o=Cisco,l=San Jose,st=CA,c=US) verification succeeded.
! Phase 1 SA is established here
889 16:03:25.886 05/28/05 Sev=Info/4CM/0x6310000E
Established Phase 1 SA. 1 Crypto Active IKE SA, 0 User Authenticated IKE SA in the
system
Example 8-15 shows the corresponding event log on the VPN 3000 Concentrator with a successful phase 1 Main Mode negotiation.
Example 8-15. Event Log for A Successful Phase I Main Mode Negotiation on Concentrator with Certificate for Authentication
! Main Mode message 1 sent by the VPN Client with IKE proposals is received by the VPN
! Concentrator
12 05/16/2005 16:15:01.910 SEV=8 IKEDBG/81 RPT=19017 172.16.172.1570
RECEIVED Message (msgid=0) with payloads :
HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR
(13) + NONE (0)
total length : 1144
! As the Concentrator does not log sending Main Mode Message 2 unless there is a failure
! you do not see the MM Message 2. If there is misMatch on Active IKE Proposals, you will
! receive "All SA Proposals Found Unacceptable". As there is no message logged, this is
! an indication that IKE proposals are accepted by the VPN Concentrator.
! Main Mode message 3 is received on the Concentrator from the VPN Client. You May
! receive duplicate of this message in certain version of code, which you can ignore.
1305 05/16/2005 16:15:02.110 SEV=8 IKEDBG/81 RPT=19018 172.16.172.1570
RECEIVED Message (msgid=0) with payloads :
HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + NONE (0)
total length : 224
! Following is the Main Mode Message 4 sent to the VPN Client Requesting for the
! Client Certificate.
1319 05/16/2005 16:01:37.690 SEV=9 IKEDBG/0 RPT=30523 172.16.172.1570
constructing certreq payload
1332 05/16/2005 16:01:37.710 SEV=8 IKEDBG/81 RPT=18861 172.16.172.1570
SENDING Message (msgid=0) with payloads :
HDR + KE (4) + NONCE (10)
total length : 961
! The following is Main Mode message 5 that the Concentrator Receives from the VPN client
! which contains the Client Cert and a Request for Concentrator's cert by the client
1334 05/16/2005 16:01:37.920 SEV=8 IKEDBG/81 RPT=18862 172.16.172.1570
RECEIVED Message (msgid=0) with payloads :
HDR + ID (5) + CERT (6) + CERT_REQ (7) + SIG (9) + NOTIFY (11) + NONE (0)
total length : 1555
! The VPN Concentrator first tries to Match a Group to the incoming client Cert
! based on the IP address.
1343 05/16/2005 16:01:37.930 SEV=9 IKEDBG/23 RPT=42 172.16.172.1570
Starting group lookup for peer 172.16.172.1570
! VPN Concentrator will be unable to find out the group based on the IP address of the
! client, which is expected, and you can ignore the following failure.
1344 05/16/2005 16:01:37.930 SEV=5 IKE/21 RPT=10 172.16.172.157
No Group found by Matching IP Address of Cert peer 172.16.172.157
! Now Concentrator will perform the group Match based on the Cert subject and DN. You
! need to raise the CERT class up to level 1-9 to see the following level of details.
1345 05/16/2005 16:01:37.930 SEV=9 CERT/107 RPT=5
Performing group Match for cert peer 172.16.172.157
using the following cert subject DN info:
OID: CountryName (26) value: US
OID: StateProvinceName (28) value: CA
OID: LocalityName (27) value: San Jose
OID: OrganizationName (30) value: Cisco
OID: OrganizationalUnitName (31) value: TAC
OID: CommonName (23) value: HTTS
1353 05/16/2005 16:01:37.930 SEV=9 CERT/108 RPT=5
Performing group Match for cert peer 172.16.172.1570
using the following cert issuer DN info:
OID: EmailAddress (13) value: xyz@cisco.com
OID: CountryName (26) value: US
OID: StateProvinceName (28) value: CA
OID: LocalityName (27) value: San Jose
OID: OrganizationName (30) value: Cisco
OID: OrganizationalUnitName (31) value: TAC
OID: CommonName (23) value: system
! Following three messages indicates the group Cisco is found based on issuer value
! O=Cisco.
1362 05/16/2005 16:01:37.930 SEV=9 CERT/109 RPT=5
Group Match component succeeded for cert peer 172.16.172.1570
OID (30) "CISCO" = "CISCO"
1364 05/16/2005 16:01:37.930 SEV=5 CERT/110 RPT=10
Group Match for cert peer 172.16.172.1570 succeeded using rule
issuer-o="cisco"
1365 05/16/2005 16:01:37.930 SEV=5 CERT/105 RPT=10
Group [Cisco] found for cert peer 172.16.172.157 by group Match rule
issuer-o="cisco"
! Finally, Group Cisco meets the Criteria
1367 05/16/2005 16:01:38.040 SEV=7 IKEDBG/80 RPT=42 172.16.172.1570
Group [Cisco]
Found Phase 1 Group (Cisco)
! Following message indicates the Concentrator finds the Client Certificate to be valid
! in terms of Dates and Certificate Authority (CA).
1376 05/16/2005 16:01:38.050 SEV=7 CERT/1 RPT=5
Certificate is valid: session = 9
! Certificate Revocation List (CRL) checking is done here.
1390 05/16/2005 16:01:38.050 SEV=5 CERT/116 RPT=5
Requesting CRL using HTTP. The HTTP URL is: http://xyz.com/CertEnroll/system.crl
! If you want to see the details of CRL http transaction, you need to use the CLIENT
! Event Class.
1392 05/16/2005 16:01:38.060 SEV=7 CLIENT/28 RPT=1
CLIENT_InitiateRequest(718d9b8, 7)
1407 05/16/2005 16:01:38.210 SEV=9 CLIENT/23 RPT=1
Total HTTP data bytes received: 327
! The following message shows the CRL Check
1427 05/16/2005 16:01:38.210 SEV=7 CERT/2 RPT=5
Certificate has not been revoked: session = 9
! The Concentrator validates it's own Certificate as shown below.
1429 05/16/2005 16:01:38.220 SEV=5 IKE/79 RPT=8 172.16.172.1570
Group [Cisco]
Validation of certificate successful
(CN=HTTS, SN=44B4C7C8000000000030)
! All Client and Concentrator Certificate Processing is SuccessfulSending Main Mode
! Message 6 as shown by the following lines.
1438 05/16/2005 16:01:38.240 SEV=8 IKEDBG/81 RPT=18863 172.16.172.1570
SENDING Message (msgid=0) with payloads :
HDR + ID (5) + CERT (6)
total length : 1549
Now that you are comfortable with the event log for a successful phase 1 negotiation of a Main Mode Remote Access VPN connection, work through the following steps to troubleshoot the digital certificate issues:
Step 1. If the VPN client does not send Main Mode Message 1, there is a problem with the certificate on the client. Check the validity dates, and make sure the personal certificate ties back to a trusted root. If the certificate is stored on the local system, ensure that it can be read by VPN client software.
Step 2. If the tunnel establishment fails in Main Mode Message 1 and 2, there may be a problem with active IKE proposals on the Concentrator. Be sure there is an active proposal that supports certificates.
Step 3. If the Concentrator does not receive Main Mode Message 5 from the VPN client, it could be because of IKE fragmentation. The certificate sent from the VPN client might be big enough to cause the packet to be fragmented.
Step 4. One of the following reasons could cause the Concentrator to receive the Main Mode message 5, but fails:
- Group Matching Be sure your rules are defined properly so that the VPN Concentrator can perform group matching properly. Raise the CERT and IKEDBG Event Classes to level 19 to see group Matching information.
- The group may not have the right IPsec SA associated with it You must have right IPsec SA associated with the group. The default logging gives you this information.
- The Client certificate does not validate If the VPN client certificate does not validate, be sure the certificates matched to the group are from the same Root CA as the certificates from the VPN client. If there is a tiered CA structure, set the client to Send CA Certificate Chain. If the certificate fails due to certificate chain issues, you might receive the following message on VPN Concentrator:
Unable to complete certificate chain, reason = Incomplete certificate chain
- CRL checking Failure Be sure the search strings and URLs are defined correctly. For LDAP, take a sniffer trace to analyze the response from the LDAP server. The Cert Event Class shows the DN you are sending. For http, the Client Event Class will add detail to the exchange. If the search is all right, be sure the cert has not been revoked (Cert Event Class can be used to find details).
- After CRL checking, the concentrator validates its own certificate before sending it to the client If this validation fails, default logging provides you the information. To correct the problem, check and correct the time and date on the Concentrator.
Step 5. Finally the Concentrator sends Main Mode Message 6 to the VPN ClientThis may fail at the VPN client primarily due to a chaining issue. Set the Certificate Transmission parameter in the IPsec SA to entire certificate chain for tiered CA structures.