SSL Certificate verification bug

[Matthew Thompson]

Hi everyone,

openconnect v5.01 gives the following error when connecting to my
university's vpn, vpn.ufl.edu:

[matthewbot at gas-powered-stick openconnect]$ openconnect https://vpn.ufl.edu/
POST https://vpn.ufl.edu/
Attempting to connect to server 128.227.166.118:443
SSL negotiation with vpn.ufl.edu
Connected to HTTPS on vpn.ufl.edu
Got HTTP response: HTTP/1.0 302 Temporary moved
POST https://ssrb230a-vpn-asa5500-1-g10-1.ns.ufl.edu/
Attempting to connect to server 128.227.166.117:443
SSL negotiation with ssrb230a-vpn-asa5500-1-g10-1.ns.ufl.edu
Connected to HTTPS on ssrb230a-vpn-asa5500-1-g10-1.ns.ufl.edu
Got HTTP response: HTTP/1.0 302 Object Moved
GET https://vpn.ufl.edu/
SSL negotiation with vpn.ufl.edu
Server certificate verify failed: certificate does not match hostname

Certificate from VPN server "vpn.ufl.edu" failed verification.
Reason: certificate does not match hostname
Enter 'yes' to accept, 'no' to abort; anything else to view: ^C
[matthewbot at gas-powered-stick openconnect]$ openconnect --version
OpenConnect version v5.01-dirty
Using GnuTLS. Features present: PKCS#11, DTLS

However, some publicly available SSL testers don't report any issues
with the certificate, and indeed, the error goes away in openconnect
v5.00. I haven't had time to look at the code yet, but I did
successfully bisect the problem to commit
152d4e4a296984a538d7d6b52a18b24ce32bffdb, "When falling back to
non-xmlpost, revert to original URL." I'm hazarding a guess that
something about the specific sequence of redirects used by my
university is breaking the logic introduced in this change? Or is
something actually wrong with our SSL setup? Thanks for the
assistance.

Matt Thompson