no trusted RSA public key found, strongswan, IKEv2

My setup:

Linux running strongswan server, 5.3, latest version.
Client is iPhone iOS 9.2

Trying to setup IKEv2 with certificate authentication. MS-CHAPv2 authentication works fine.

Issue: no trusted RSA public key found

After spending hours on the Internet, combing through the strongswan forums and even looking at the source code, I was able to finally find out the issue:

The issue was with the client certificate I generated for iPhone.

The certificate did not have a SAN (Subject Alternative Name). I never knew it was REQUIRED to have one.  This is how the check on the server goes:

1. Server needs to make sure a certificate is received from the client.
2. It then does the following checks:
    - cert is signed with a known CA.
    - cert date is valid
    - IMPORTANT: "local ID" specified on iOS has to be a FQDN, and has to match the SAN in the certificate.  SAN for FQDN starts with "DNS:". In theory, the ID can also be IPv4 address (IP:) or USER_FQDN with is an email address (email:). If no SAN is found in the cert, the server is supposed to match the DN of the cert, but iOS always submit the local ID as FQDN therefore breaking that, and therefore requiring an SAN for the client cert with the "DNS:" name.

strongswan log will not tell you this if the SAN and local ID does not match, even if turning debug level all the way to 3. It will just say "no trusted RSA public key found". Very confusing.

Well, now you know it.

linuc iptables, NAT and bridge interface

There are some issues using Linux iptables, bridge interface and NAT together. See details from the blog:

http://www.woitasen.com.ar/2011/09/confusion-using-iptables-nat-and-bridge/

The summary is packets forwarded between the bridged interfaces also go through iptables, therefore potentially creating connection-tracking states before it gets to the NAT-enabled outbound interface. Then later, when the packet is routed to the NAT-enabled outbound interface, the NAT table will not be consulted anymore because the conn-track entry already exists for that packet.

The two possible solutions:

• echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables #To disable Iptables in the bridge.
• Raw table: This table can be used to avoid packets (connection really) to enter the NAT table: iptables -t raw -I PREROUTING -i BRIDGE -s x.x.x.x -j NOTRACK.

supervisor add new a process

after adding the process.conf file in /etc/supervisor/conf.d/, run:

supervisorctl reread
supervisorctl update

http://www.onurguzel.com/supervisord-restarting-and-reloading/

nmap test ciphers of remote server

 nmap --script ssl-enum-ciphers -p 443 your-test-site.com