[strongSwan] IKEv1 Renegotiation Issues with Cisco Devices Using Certificate Authentication
John Marrett
johnf at zioncluster.ca
Fri May 15 17:47:37 CEST 2015
This email is intended to document an interop issue with Cisco routers
using certificates for authentication.
I sucessfully built a VPN connection between a Cisco IOS Router and a
strongswan router, authentication was performed using certificates and
IKEv1. Unfortunately the Cisco router tore down the ISAKMP and IPSEC
session during the renegotiation (received DELETE for IKE_SA). Noel helped
me to understand that we were setting N(INITIAL_CONTACT) which was why the
Cisco router tore down the connection.
Adding substantial debugs into the strongswan source code allowed us to
understand that, despite being identical in textual representation, the
certificate did not match the rightid specified in the ipsec.conf. Detailed
analysis of the certificate revealed that the ASN.1 representation of the
subject DN was slightly unusual, containing two sets, the second with two
sequences. This behaviour will occur if the router is used to generate it's
own CSR. strongSwan encoded the textual representation of the subject DN,
as configured in rightid, into a more standard ASN.1 structure with three
sets and sequences.
I resolved the issue by directly specifying the binary ASN.1 encoding using
the rightid="asn1dn:#<hex encoded asn1 string" this encoding is a new
feature in 5.2.2 and 5.3.
In order to generate the string you will need a pem encoded copy of the
certificate (On the router in configuration mode cry pki exp <trustpoint
name> pem terminal). You can then determine the ASN offsets:
johnf at johnf-T420s:~$ openssl asn1parse -i -in/etc/i router.pem
0:d=0 hl=4 l=1012 cons: SEQUENCE
4:d=1 hl=4 l= 476 cons: SEQUENCE
8:d=2 hl=2 l= 3 cons: cont [ 0 ]
10:d=3 hl=2 l= 1 prim: INTEGER :02
13:d=2 hl=2 l= 2 prim: INTEGER :021B
17:d=2 hl=2 l= 13 cons: SEQUENCE
19:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
30:d=3 hl=2 l= 0 prim: NULL
32:d=2 hl=2 l= 45 cons: SEQUENCE
34:d=3 hl=2 l= 43 cons: SET
36:d=4 hl=2 l= 41 cons: SEQUENCE
38:d=5 hl=2 l= 3 prim: OBJECT :commonName
43:d=5 hl=2 l= 34 prim: PRINTABLESTRING :XXXXXX Internal CA
L=Montreal C=CA
79:d=2 hl=2 l= 30 cons: SEQUENCE
81:d=3 hl=2 l= 13 prim: UTCTIME :150420125731Z
96:d=3 hl=2 l= 13 prim: UTCTIME :170304015051Z
111:d=2 hl=2 l= 108 cons: SEQUENCE
113:d=3 hl=2 l= 39 cons: SET
115:d=4 hl=2 l= 37 cons: SEQUENCE
117:d=5 hl=2 l= 3 prim: OBJECT :commonName
122:d=5 hl=2 l= 30 prim: PRINTABLESTRING :
router0003.internal.XXXXXX.com
154:d=3 hl=2 l= 65 cons: SET
156:d=4 hl=2 l= 18 cons: SEQUENCE
158:d=5 hl=2 l= 3 prim: OBJECT :serialNumber
163:d=5 hl=2 l= 11 prim: PRINTABLESTRING :MI2DZNnDHuk
176:d=4 hl=2 l= 43 cons: SEQUENCE
178:d=5 hl=2 l= 9 prim: OBJECT :unstructuredName
189:d=5 hl=2 l= 30 prim: IA5STRING :
router0003.internal.XXXXXX.com
With this specific certificate the representation starts at offset 111 and
has a length of 110 (hl=2 + l=108 = 100) characters. (The actual string
will be hex, this is redacted here).
johnf at johnf-T420s:~$ openssl x509 -in router.pem -outform der | xxd -s 111
-l 110 -c 110 -g 0 -p
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
You can then load this identifier into the strongswan configuration as
follows:
rightid="asn1dn:#XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
You will now be able to rekey correctly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150515/032bbb8c/attachment-0001.html>
More information about the Users
mailing list