IPSec with certificate broken after update from 6.44.3 to 6.45.6

sithmein · September 28, 2019, 10:49am

After updating a CHR from 6.44.3 to 6.45.6 all IPSec connection using certificates are broken. We are using StrongSwan for roadwarrior dial-in with RSA certificate. Prior to the update a successful connection looked as follows:

initiating IKE_SA production[33] to xxx.xxx.xxx.xxx
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 192.168.1.17[500] to xxx.xxx.xxx.xxx[500] (1004 bytes)
received packet: from xxx.xxx.xxx.xxx[500] to 192.168.1.17[500] (429 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
local host is behind NAT, sending keep alives
remote host is behind NAT
sending cert request for "C=CH, ST=Zurich, L=Zurich, O=KNIME AG, CN=KNIME Root CA, E=syst@knime.com"
sending cert request for "C=CH, ST=Zurich, O=KNIME AG, CN=KNIME Intermediate CA for internal usage, E=syst@knime.com"
sending cert request for "C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA"
sending cert request for "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
authentication of 'C=CH, ST=Zurich, L=Zurich, O=KNIME AG, CN=ABC DEF, E=yyy@knime.com' (myself) with RSA signature successful
sending end entity cert "C=CH, ST=Zurich, L=Zurich, O=KNIME AG, CN=ABC DEF, E=yyy@knime.com"
sending issuer cert "C=CH, ST=Zurich, O=KNIME AG, CN=KNIME Intermediate CA for internal usage, E=syst@knime.com"
establishing CHILD_SA production{145}
generating IKE_AUTH request 1 [ IDi CERT CERT CERTREQ IDr AUTH CPRQ(ADDR DNS DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 192.168.1.17[4500] to xxx.xxx.xxx.xxx[4500] (3984 bytes)
received packet: from xxx.xxx.xxx.xxx[4500] to 192.168.1.17[4500] (2128 bytes)
parsed IKE_AUTH response 1 [ CERT IDr AUTH N(INIT_CONTACT) CPRP(ADDR MASK SUBNET) TSi TSr SA ]
received end entity cert "C=CH, L=Z??rich, O=KNIME.com AG, CN=*.knime.com"
  using trusted intermediate ca certificate "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
  reached self-signed root ca with a path length of 0
  using trusted certificate "C=CH, L=Z??rich, O=KNIME.com AG, CN=*.knime.com"
authentication of 'C=CH, L=Z??rich, O=KNIME.com AG, CN=*.knime.com' with RSA signature successful
IKE_SA production[33] established between 192.168.1.17[C=CH, ST=Zurich, L=Zurich, O=KNIME AG, CN=ABC DEF, E=yyy@knime.com]...xxx.xxx.xxx.xxx[C=CH, L=Z??rich, O=KNIME.com AG, CN=*.knime.com]
scheduling reauthentication in 10059s
maximum IKE_SA lifetime 10599s
handling INTERNAL_IP4_NETMASK attribute failed
handling INTERNAL_IP4_SUBNET attribute failed
installing new virtual IP 172.30.0.127
selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
CHILD_SA production{145} established with SPIs ccf64712_i 097d3a40_o and TS 172.30.0.127/32 === 172.31.0.0/16
connection 'production' established successfully

After the update the connection fails with

initiating IKE_SA production[32] to xxx.xxx.xxx.xxx
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 192.168.1.17[500] to xxx.xxx.xxx.xxx[500] (1004 bytes)
received packet: from xxx.xxx.xxx.xxx[500] to 192.168.1.17[500] (429 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
local host is behind NAT, sending keep alives
remote host is behind NAT
sending cert request for "C=CH, ST=Zurich, L=Zurich, O=KNIME AG, CN=KNIME Root CA, E=syst@knime.com"
sending cert request for "C=CH, ST=Zurich, O=KNIME AG, CN=KNIME Intermediate CA for internal usage, E=syst@knime.com"
sending cert request for "C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA"
sending cert request for "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
authentication of 'C=CH, ST=Zurich, L=Zurich, O=KNIME AG, CN=ABC DEF, E=yyy@knime.com' (myself) with RSA signature successful
sending end entity cert "C=CH, ST=Zurich, L=Zurich, O=KNIME AG, CN=ABC DEF, E=yyy@knime.com"
sending issuer cert "C=CH, ST=Zurich, O=KNIME AG, CN=KNIME Intermediate CA for internal usage, E=syst@knime.com"
establishing CHILD_SA production{142}
generating IKE_AUTH request 1 [ IDi CERT CERT CERTREQ IDr AUTH CPRQ(ADDR DNS DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 192.168.1.17[4500] to xxx.xxx.xxx.xxx[4500] (3984 bytes)
received packet: from xxx.xxx.xxx.xxx[4500] to 192.168.1.17[4500] (2208 bytes)
parsed IKE_AUTH response 1 [ CERT IDr AUTH CPRP(ADDR MASK SUBNET) TSi TSr SA ]
received end entity cert "C=CH, L=Z??rich, O=KNIME.com AG, CN=*.knime.com"
  using trusted intermediate ca certificate "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
  reached self-signed root ca with a path length of 0
  using trusted certificate "C=CH, ST=Zurich, L=Z??rich, O=KNIME.com AG, CN=*.knime.com"
signature validation failed, looking for another key
  using certificate "C=CH, L=Z??rich, O=KNIME.com AG, CN=*.knime.com"
  using trusted intermediate ca certificate "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
  using trusted ca certificate "C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA"
certificate policy 2.16.840.1.114412.1.1 for 'C=CH, L=Z??rich, O=KNIME.com AG, CN=*.knime.com' not allowed by trustchain, ignored
certificate policy 2.23.140.1.2.2 for 'C=CH, L=Z??rich, O=KNIME.com AG, CN=*.knime.com' not allowed by trustchain, ignored
  reached self-signed root ca with a path length of 1
authentication of '*.knime.com' with RSA signature successful
constraint check failed: identity 'C=CH, L=Z??rich, O=KNIME.com AG, CN=*.knime.com' required 
selected peer config 'production' unacceptable: constraint checking failed
no alternative config found
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
sending packet: from 192.168.1.17[4500] to xxx.xxx.xxx.xxx[4500] (80 bytes)
establishing connection 'production' failed

Apart from the update no other configurations were changed. Could it be the that german umlaut (Zürich) in the certificate CN causes the issue?

surlydre · September 29, 2019, 6:02pm

I ran into a problem with certificate based site-to-site tunnels as well after upgrading from 6.45.4 to 6.45.6. My certificate only contains plain ASCII characters. Downgrading back to 6.45.4 got the StrongSwan end of the re-key process working again.

I need to turn up debugging on the Mikrotik end, to get more details, but since it’s working with the downgrade, I might wait for the next version before trying again.