Server Certificate Verification Method

First, confirm that your UTM Hostname conforms to #0 in https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/22065.

On the 'Advanced' tab, see which 'Server certificate' is in use and then look in 'Certificate Management' to confirm that the certificate shows the same hostname in 'VPNId [Hostname]' as is the hostname of the UTM.

Cheers - Bob
PS I always recommend that the SSL VPN be switched to UDP protocol on the 'Settings' tab.  You'll need to reload the config in your Android.

Thanks for the reply. 

I have a dyndns name that works, so I think I clear #1

If I go to Remote Access->SSL->Advanced, the Server Certificate is 'Local X509 Cert'
If I go to Remote Access->SSL->Certificate Management, the Local X509 Cert VPNid is SOPHOS

A few weeks ago, my DynDNS name changed, and I noticed a certificate (Don't remember which one, probably this one) had my old name. I deleted it, expecting it would regenerate properly.

That's what I was afraid of.  Changing the Hostname creates all kinds of problems, so I think for most people the best solution is to do a Factory Reset and start over. 

You can open the Printable Configuration, go to the bottom of the page, select to see everything in WebAdmin format and save it.  You probably can work through a new installation in two hours.   Good luck!

Cheers - Bob
PS As RChadwick notes below, using slickone27's trick reduces this to just a few minutes if you don't have UTM Endpoint activated.

Thanks for the response Bob. I would have replied sooner, but I'm still trying to process this. 

Is there anything else I can try? It's running on a VM, so it's easy to restore if something gets worse.

Any idea if this might be addressed in a future update? I suspect my Dynamic DNS names may change from time to time, and I can definitely think of more productive things to do with 2 hours [:)]

I don't know of a comprehensive list of what needs to be done to make the changes manually.  In a complex installation where it would take too much time to start over, I would just work my way through everything to make 20+ changes.  You might not know where those are.

It's the difference between investing some planned time now all-at-once and spending more time and confusion and delay in fixing things in the future.

Get a real domain name, like rchadwick.com, and create a CNAME entry in public DNS for utm.rchadwick.com that refers to your DynDNS name.  If, in the future, you have a new DynDNS name and setting in UTM DynDNS, you will then only need to change the CNAME record, as the Hostname can stay the same and all will be copacetic!

Cheers - Bob

I hate to dig up an old thread, but I have the same problem again. I just upgraded to 9.201-25. I saved the config, without the certs (As mentioned in Rule 0), did a fresh install, and restored the config. I used a real domain name (office.mydomain.com). I re-downloaded the Android SSL client config, and it connects fine. However, I see the error in the Android client: "WARNING: No Server certificate verification method has been enabled". Trying to use the above advice, it seems things are a little different in 9.2. Looking around in the certs, they all either mention an email address, or my new domain name. Any advice?
Thanks!

Thanks for digging this up - I added a PS with a link to my post above. 

This shouldn't be any different.  Have you tried deleting the configuration and program from the Android and then re-installing?  What do the Android forums say about this error?

Cheers - Bob

I did reinstall OpenVPN on my Android tablet, but I still have the same error. It doesn't stop things from working, so I'm not terribly concerned about it.

One possible clue... When I download the configuration (Android, or Windows), instead of pointing to the domain name office.mydomain.com, it's just 'office'. I have to manually change the config to point to my domain name. I did find a setting to force the name to something, so I forced it to office.mydomain.com, and the config files produced are now correct. Maybe for some reason the certificate is based on simply 'office', and not the full domain name?