[strongSwan] IKEv1 Pubkey Auth Fails from Windows to Linux
Detweiler, Quinn
Quinn.Detweiler at unisys.com
Wed Feb 3 15:24:37 CET 2016
Hi all,
I am unable to establish a host-to-host IPsec tunnel using pubkey authentication initiated by a Windows 7 system (Windows native IPsec software) to a Red Hat 6.6 system with strongSwan 5.3.5. I see the following in the charon logs:
charon: 16[CFG] reached self-signed root ca with a path length of 0
charon: 16[CFG] using trusted certificate "C=US, O=Org, OU=Unit, CN=QdCertSaIke2P384"
charon: 16[IKE] signature validation failed, looking for another key
charon: 16[IKE] no trusted ECDSA public key found for 'C=US, O=Org, OU=Unit, CN=QdCertSaIke2P384'
charon: 16[CFG] no alternative config found
I know that I have the correct trusted root certificate installed and available (it shows up earlier in the log and in the output of "ipsec stroke listcacerts"). Even more strange, using the exact same certificates (both trusted root and end-entity) and the same configuration, I can establish a tunnel between two Red Hat 6.6 strongSwan systems. In this Linux to Linux case, "ipsec stroke listcacerts" shows that the same trusted root cert is configured as in the Windows to Linux case. In fact, the entire charon trace looks almost identical except that I see "authentication successful" messages:
charon: 13[CFG] reached self-signed root ca with a path length of 0
charon: 13[CFG] using trusted certificate "C=US, O=Org, OU=Unit, CN=QdCertSaIke2P384"
charon: 13[IKE] authentication of 'C=US, O=Org, OU=Unit, CN=QdCertSaIke2P384' with ECDSA successful
charon: 13[IKE] authentication of 'C=US, O=Org, OU=Unit, CN=QdCertSaIke2P384' (myself) successful
Why might there be a difference in the result of pubkey authentication between Windows and Linux versus two Linux systems? Even with IKE, CFG, and NET logging turned up to the highest level, I don't see anything to indicate why the same certificates / signatures are validated in one case but not the other.
I have attached my ipsec.conf files and syslog files for both the Linux to Linux and Windows to Windows cases. The IP addresses were as follows:
Windows to Linux: Windows (192.168.9.2) --> Red Hat 6.6 (192.168.9.12)
Linux to Linux: Red Hat 6.6 (192.168.9.11) --> Red Hat 6.6 (192.168.9.12)
I also attached the output of 'ipsec stroke listcacerts', which was identical in both cases.
Thank you,
Quinn Detweiler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: windows-to-linux-syslog
Type: application/octet-stream
Size: 11365 bytes
Desc: windows-to-linux-syslog
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160203/5fec15ca/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: windows-to-linux-ipsec.conf
Type: application/octet-stream
Size: 684 bytes
Desc: windows-to-linux-ipsec.conf
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160203/5fec15ca/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: listcacerts-output
Type: application/octet-stream
Size: 477 bytes
Desc: listcacerts-output
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160203/5fec15ca/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-to-linux-syslog
Type: application/octet-stream
Size: 13790 bytes
Desc: linux-to-linux-syslog
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160203/5fec15ca/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-to-linux-ipsec.conf
Type: application/octet-stream
Size: 687 bytes
Desc: linux-to-linux-ipsec.conf
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160203/5fec15ca/attachment-0009.obj>
More information about the Users
mailing list