Unacceptable TLS certificate

[hwaterer]

Hi Daniel,

As of today, after signing in with 2FA I'm left with a window that says Unacceptable TLS certificate. I then close that window and gp-saml-gui terminates. Everything worked fine Friday last week. I guess that they've made some changes over the weekend.

Looking for SAML auth tags in response to https://vpn.company.com/ssl-vpn/prelogin.esp...
Got SAML POST, opening browser...
[PAGE   ] Finished loading page about:blank
[PAGE   ] Finished loading page https://xxx.okta.com/app/panw_globalprotect/exkmuy9k5dT1PXpfd0x7/sso/saml
[PAGE   ] Finished loading page https://xxx.okta.com/login/sessionCookieRedirect
[PAGE   ] Finished loading page https://xxx.okta.com/login/sessionCookieRedirect

(process:12775): GLib-GIO-CRITICAL **: g_tls_connection_get_peer_certificate_errors: assertion 'G_IS_TLS_CONNECTION (conn)' failed
Traceback (most recent call last):
  File "/path/to/gp-saml-gui/gp-saml-gui.py", line 103, in get_saml_headers
    h = rs.get_http_headers()
AttributeError: 'NoneType' object has no attribute 'get_http_headers'
[PAGE   ] Finished loading page about:blank
Login window closed by user.

Any ideas?

Thanks, Hamish

[dlenski]

As of today, after signing in with 2FA I'm left with a window that says Unacceptable TLS certificate.

To be clear… this is in the browser window?

I'm guessing it means that you need to include a client certificate, which you can do with --cert. But without any other information it's hard for me to speculate.

If that's off-base, then what happens if you do the login in a "real", external browser using --external?

[hwaterer]

To be clear… this is in the browser window?

In the SAML Login pop-up window launched by gp-saml-gui.

I'm guessing it means that you need to include a client certificate, which you can do with --cert. But without any other information it's hard for me to speculate.

Where do I find the client certificate? I have access to the GlobalProtect client under Windows.

If that's off-base, then what happens if you do the login in a "real", external browser using --external?

Using --external and pasting the output into a browser yields a successful login but how do I now get the cookie I need to proceed with openconnect, or am I pasting the cookie? If I set the string that appears after data:text/html;base64, as the cookie and echo that to openconnect then I get Server certificate verify failed: certificate expired and a bunch of certificate information. Presumably this is what I need for the client certificate but I'm not sure how that works.

[hwaterer]

Oops! Sorry. I marked this closed by mistake.

[dlenski]

If you don't need a client certificate in the official client, then that's clearly not the problem here.

It seems that the problem is more likely to be that the server's TLS certificate is trusted by a "real" browser, but not by the WebKitGtk pop-up browser window.

This is likely OS/distribution/browser-dependent.

1. Who is the issuer of the server's cert?
2. What "real" browser are you using?
3. What Linux distribution are you using?
4. What version of WebKitGtk?

[hwaterer]

1. Issuer: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Organization Validation Secure Server CA
2. Firefox 76.0.1+build1-0ubuntu0.16.04.1
3. Ubuntu 16.04 LTS
4. python3-gi 3.20.0-0ubuntu1 gir1.2-gtk-3.0 3.18.9-1ubuntu3.3 gir1.2-webkit2-4.0 2.20.5-0ubuntu0.16.04.1

[elehmer]

I had the exact same issue: Unacceptable TLS certificate in the response of my GUI popup. I'm running Ubuntu 18.04 LTS. It was fixed by doing a system update with the apt upgrade installing this package:

ca-certificates (20190110~18.04.1)

[dlenski]

@hwaterer and @lehmer, okay, so clearly this is a problem with SERVER certificates.

Did either of you try running with --no-verify, which was specifically created for this purpose, and listed in the --help output? (And if not why not? :face_with_head_bandage:)

https://github.com/dlenski/gp-saml-gui/blob/6133ffeb7a47a12afff2e7eb404434d24ddc01e1/gp-saml-gui.py#L43-L44

[elehmer]

Yep, I sure did! I was still rebuffed by the server. Unfortunately, I forget the exact response I received and I've done a reboot in between to try and resolve this issue. --no-verify works now after updating my system.

[dlenski]

@elehmer You write that --no-verify works now, but I'm guessing it also works now without --no-verify, because you updated the Python cert store.

Is that correct?

[elehmer]

Yes, I run without the --no-verify normally. I just added it to test that it works correctly after updating cert store.

[dlenski]

Okay, but what if you don't run with --no-verify? What we're trying to figure out here is if --no-verify actually does what it's supposed to (which is to ignore an inability to verify the server certificate, both using the python-native requests module, used for the initial prelogin fetch, as well as using WebKitGtk, for the popup window).

[elehmer]

After updating my cert store, I believe --no-verify is doing what it is supposed to do because the only difference I can see with and without this flag is that with it I get this warning:

/home/elehmer/.virtualenvs/vpn/lib/python3.6/site-packages/urllib3/connectionpool.py:1004: InsecureRequestWarning: Unverified HTTPS request is being made to host 'campus.vpn.berkeley.edu'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings

Using either option connects me to the VPN.

Before I updated the python cert store the -no-verify flag did not help connect me to the VPN, and I got either a cert expired or invalid error, I can't remember which it was. Maybe @hwaterer can verify that if they haven't updated their OS yet.

[hwaterer]

I can confirm that ---no-verify did the right thing and ignored the inability to verify the server certificate (with an appropriate InsecureRequestWarning) thus allowing gp-saml-gui to complete successfully.

The issue is then that openconnect fails with Server certificate verify failed: certificate expired which is to be expected. When I was floundering around in the dark yesterday I did try the --servercert option without success but I could have been doing it wrong.

Anyway, an update for the ca-certificates package came through overnight. After the update to ca-certificates (20190110~16.04.1) everything works as it did previously. Unfortunate timing, but I've learnt something. Thanks for the help. Greatly appreciated.

[philchang]

I recently had an issue with the an unacceptable TLS certificate as well. I just upgraded to ubuntu 22.04 and this problem appeared. After alot of research, I found a workaround, but this involved hacking gp-saml-gui. Here is the hack.

First --no-verify does not work. The error it spits back is ValueError: Cannot set verify_mode to CERT_NONE when check_hostname is enabled.

However, if you modify gp-saml-gui.py

class SAMLLoginView -> init so that

self.ctx.set_tls_errors_policy(WebKit2.TLSErrorsPolicy.IGNORE) is called even with verify=False, then it works fine.

Thought this might be helpful -- it might suggest a command line argument to --ignore-tls-errors