Here is what appears to be the problem from the log:
2013:03:03-15:51:20 utm9 openvpn[20476]: VERIFY OK: depth=2, C=NA, ST=None, L=None, O=Mullvad, CN=Mullvad CA, emailAddress=info@mullvad.net
2013:03:03-15:51:20 utm9 openvpn[20476]: VERIFY OK: depth=1, C=NA, ST=None, L=None, O=Mullvad, CN=master.mullvad.net, emailAddress=info@mullvad.net
2013:03:03-15:51:20 utm9 openvpn[20476]: VERIFY X509NAME ERROR: C=NA, ST=None, L=None, O=Mullvad, CN=se2.mullvad.net, emailAddress=info@mullvad.net, must be C=NA, L=None, O=Mullvad, CN=se2.mullvad.net, emailAddress=info@mullvad.net
2013:03:03-15:51:20 utm9 openvpn[20476]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2013:03:03-15:51:20 utm9 openvpn[20476]: TLS Error: TLS object -> incoming plaintext read error
It seems to be complaining about the ST field in the server DN.
Here is a link to a screen capture of the apc file that was loaded into utm and resulted in the log file above, opened in notepad++:
You can see that there is no ST field in the server DN. (In case you're wondering, the vpn server does not rely upon authentication. It simply uses the key. The username and password fields are placeholders.)
Since I have nothing else to try, if I assume the problem is that utm is unhappy with the format of the server DN due to the missing ST field, and correct it to what utm seems to be asking for, it rejects the apc file when I try to load it, saying the config is corrupt. I'm quite sure the file is formatted correctly (the character preceding the server DN is the length in hex), but it obviously utm is not happy with it.
Here is a link to apc file that seems like it should be correct, but is rejected:
I was able to partially decode the apc file from this snip out of here.
0x04 0x06 0x04 1234 0x04 0x04 0x04 0x08 0x03 0x0C 0x00 0x00 0x00 0x0d 0x0a
0x03 tcp 0x08 0x00 0x00 0x00 protocol 0x0d 0x0a
0x03 MD5 0x18 0x00 0x00 0x00 authentication_algorithm 0x01 0x49 0x0e 0x00 0x00 0x0a
0x0b 0x00 0x00 0x00 certificate 0x01 0x77 0x0c 0x00 0x00 0x0a
0x07 0x00 0x00 0x00 ca_cert 0x01 0x77 0x03 0x00 0x00 0x0a
0x03 0x00 0x00 0x00 key 0x0a
0x0e REF_1234567890 0x08 0x00 0x00 0x00 username 0x08 0x81 0x0b 0x00 0x00 compression 0x0a
0x0b AES-128-CBC 0x14 0x00 0x00 0x00 encryption_algorithm 0x0a
0x20 1234567890123456789012 0x08 0x00 0x00 0x00 password 0x0a
0x61 /C=country/L=Town/O=Organization/CN=hostname/emailAddress=me@my.org 0x09 0x00 0x00 0x00 server_dn 0x0a
0x03 443 0x0b 0x00 0x00 0x00 server_port 0x0a
0x08 astaro01 0x0e 0x00 0x00 0x00 server_address 0x00
ASIDE: My editorial comment on the apc file format, as an engineer, is that it's one the most bizarre formats I've ever seen. Whoever thought it was a good idea to intermix ascii and hex in one file really deserves to be locked up in stocks and have peasants throw rotten eggs and tomatoes at him. The file is very difficult to decode and also very difficult to edit. It would be impossible without notepad++ or another hex editor. Ever heard of XML?
I have found a number of changes in the apc file format since Patrick Schneider was looking at it, including the header and the field for compression, which I was able to figure out, but I have no idea what the "engine" field in the third last line of the apc file is, nor do I know why utm is not happy with the modified file that it's rejecting.
If someone else who's trying to get this working wants to collaborate, let me know. I'd be happy to share my work.
However, I've said this before and I'll say it again. Sophos could make this matter a lot simpler if someone would disclose the format of the apc file. Why the silence? What do you have to hide? Surely you don't think anyone will copy the apc file format do you?
PS. If the tone of my post gives you the impression that I'm not very happy with sophos, it's because I'm not very happy with sophos.
This thread was automatically locked due to age.
