L2TP based VPN with OpenS/WAN server, OpenSSL machine certificates
I cannot seem to get OSX to accept the machine certificates for a VPN connection using Internet Connect.
I have generated OpenSSL x509 certificates for the server and client side, the same process has generated certificates that work just dandy with WindowsXP. The certificates have "subjectAltName=" key/value pairs assigned to the IP address of the VPN server.
Once generated I import the certificates into OS X (you have to run KeyChain Access with "sudo" from the console to get this to work). The certificate authority seems to be ok, the CA has been added to the x509Roots, and when I examine the machine certificate for my OS X install using KeyChain Access the certificate is marked valid.
I generated the hash link for the certificate:
ln -s /etc/racoon/certs/certname.pem /etc/racoon/certs/'openssl x509 -noout -in certname.pem'.0
From the console I run '
openssl verify certname.pem
It fails unless I specify '-CAPath /etc/racoon/certs', then it passes.
When Internet Connect is setup to use the certificates I can see in the OpenS/WAN logs that the OS X box connects and negotiates IPSEC to MAIN_3. At this point pluto logs the following:
ignoring informational payload, type INVALID CERTAUTHORITY
This repeats for several re-tries before the OS X side gives up. No useful logging is generated on the OS X side for me to debug, and everything from the OpenS/WAN side seems to be kosher, it appears to be an oakley/racoon issue with validating the machine certificate provided by OpenS/WAN to the OS X side, with the OS X side unable to verify the certificate.
Has anyone solved this? Any ideas on how to improve the logging output from OS X so I can see what racoon/oakley is carping about in the certificate files it is using?
I have generated OpenSSL x509 certificates for the server and client side, the same process has generated certificates that work just dandy with WindowsXP. The certificates have "subjectAltName=" key/value pairs assigned to the IP address of the VPN server.
Once generated I import the certificates into OS X (you have to run KeyChain Access with "sudo" from the console to get this to work). The certificate authority seems to be ok, the CA has been added to the x509Roots, and when I examine the machine certificate for my OS X install using KeyChain Access the certificate is marked valid.
I generated the hash link for the certificate:
ln -s /etc/racoon/certs/certname.pem /etc/racoon/certs/'openssl x509 -noout -in certname.pem'.0
From the console I run '
openssl verify certname.pem
It fails unless I specify '-CAPath /etc/racoon/certs', then it passes.
When Internet Connect is setup to use the certificates I can see in the OpenS/WAN logs that the OS X box connects and negotiates IPSEC to MAIN_3. At this point pluto logs the following:
ignoring informational payload, type INVALID CERTAUTHORITY
This repeats for several re-tries before the OS X side gives up. No useful logging is generated on the OS X side for me to debug, and everything from the OpenS/WAN side seems to be kosher, it appears to be an oakley/racoon issue with validating the machine certificate provided by OpenS/WAN to the OS X side, with the OS X side unable to verify the certificate.
Has anyone solved this? Any ideas on how to improve the logging output from OS X so I can see what racoon/oakley is carping about in the certificate files it is using?
MacBook Pro 15", Mac OS X (10.4.7), 1.8Ghz/1GB/120GB