On Tue, Dec 13, 2016 at 11:04:46PM +0100, Michael Biebl wrote:
> Am 13.12.2016 um 18:22 schrieb Michael Biebl:
> > I've blocked the two bugs accordingly and forwarded the issue to
> > upstream.
> 
> This is upstream's response
> 
> 
> Thomas Haller:
> > I don't think there is anything to do.
> > 
> > nm-openvpn already supports the verify-x509-name option, which should
> > be used.
> > 
> > 
> > The problem is for users who have existing connections with
> > tls-remote setting.
> > 
> > For example, when you look at your NetworkManager ovpn connection
> > (for example, named "MyOVPN"):
> > 
> > $ nmcli connection show "MyVPN" | grep tls-remote
> > 
> > 
> > openvpn 2.4 breaks backward compatibility by removing the option.
> > There is nothing that nm-openvpn can do about it except requiring
> > users to fix their configuration.
> > 
> > E.g. the Gnome plugin of nm-openvpn for nm-connection-editor has a
> > "Server Certificate Check" combobox. Affected users have to move away
> > from the "Verify subject partially (legacy mode)" setting.
> 
> In light of that, I'll close this bug report.
> I suggest, openvpn either patches tls-remote support back in (for
> stretch) or it adds a NEWS file, telling users to check their VPN
> configuration files (including the NetworkManager config) and fix them
> up manually.

Michael,
 Indeed, changing that configuration did fix my setup. Thanks!
Since NM can detect this situation, could it provide this same advice
to the user, even if just via syslog?

  -dann

Reply via email to