Bug 1370864

Downgrading ca-certificates to 2016.2.7-1.0 did not help, same unacceptable TLS certificates message, so probably not that component.

why do you think this is a bug? Perhaps the airport certificates are in fact complete bogus certificates? Do you have a copy of those certificates?

I am sure that the same login at Schiphol, with the same laptop functioned without failure on Monday evening 22 August, but failed with the Unacceptable TLS certificate message on Saturday afternoon 27 August. I use that airport often, but had not been there with the fresh install (not upgrade) of Fedora 24 before. Worked 22 August, ca-certificates and possibly other packages updated via the Gnome updater about 25 August (where do I find the log - it is not in /var/log/dnf.log?), didn't work 27 August. Are you suggesting that the bug occurred because both Vienna and Amsterdam airports degraded their handshakes to the web authorization screen during this period? An Android handset (at that time on Fairphone OS 1.5.1 on Android 5.1) logged in passing the challenge screen without any issues.

Of course I do not have any copies of any certificates. I'm simply trying to help, as I've done before with a Firefox regression, but that was a case which I could log and reproduce. This I cannot, firstly because I know too little about the internals and you have not tried to tell me where to look, and secondly because I'm no longer trying to work at that airport between flights. But two airports with a similar failure doesn't look like chance to me.

You need to establish which components give the reported message and under what conditions, and which software components might have need updated immediately before 25/26 August (and/or where the Gnome updater aka Software logs what it does, so that I can provide the complete log. In addition, if the TLS handshake failures are logged, where might that be?

Created attachment 1196617 [details]
screenshot of Web Authentication Redirect

Typical screenshot of Web Authentication Redirect, here in a hotel without content and thus not succeeding in registering acceptance of login rules.

Roger, thanks for your intention to help.

I'm afraid the report has too little information to find out what's happening.

It seems you have refuted your own suspicion, by testing that a downgrade to the old ca-certificates version didn't fix your connectivity issue, so it must be something else.

In the future, if you travel to the airports again and experience the same issue again, you could test to produce a dump of the certificates that you are presented in that environment, for example using the following command:

tstclnt -D -b -CCC -p 443 -h some-hostname

The above doesn't follow redirects. So, if you are redirected to a specific web site for the wifi login, please use the hostname of that login site in the above command.

Also, please state which browser you used when you got the error message (it's not clear from the screenshot).

I'm closing this bug, because we apparently have insufficient data to work on it. Please reopen when you have more details. Thanks

Correction, because tstclnt isn't in the default path:
/usr/lib64/nss/unsupported-tools/tstclnt -D -b -CCC -p 443 -h some-hostname

No browser at all. On choosing the unsecured network, the Web Authentication Redirect window is pushed to cover the whole screen without any user intervention. Previously, it might include acceptance of use conditions, entry of a token by typing, etc. Now, it doesn't handshake at all. What triggers the launching of the Web Authentication Redirect window?

Maybe this is triggered by a GUI component of NetworkManager that detects that the connected WIFI requires authentication?

Yes, that sounds very likely - I use standard Gnome as the desktop. 

In some cases earlier, the unsecured network just connected, and the challenge (to agree to conditions etc.) was issued in the first browser window to be opened after connecting. 

Recently, the Web Authentication Redirect window has become more typical - I think because the same wifi systems are largely used by smartphones, which also use a challenge notification. Probably the GUI component mimics the behaviour of phones, on which the browser is not the default way of "looking at the world".

The hotspot detection is in gnome, not networkmanager, these days.

If that is the case you can test this by ignoring the "pop up" authenitcation window that covers the entire screen (gnome) and using firefox directly and browse to 1.2.3.4 and see what kind of warning/acceptance you see for the certificate there.

Good, thanks. 

Where could I look to see which relevant rpms were updated on or before 26-27 August that might bear on the problem? Updating was by Gnome Software, so I can't see anything in the dnf log. 

Are there preferred ways of logging what reaches Firefox? I can try to lurk near the hotel where I could reproduce the problem 1st September, to see if I can provoke it.

Is this where we might be heading:

https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver