[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   :
  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         :

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

You can then load this identifier into the strongswan configuration as


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