Topic: Unable to upload to Weather Underground: getting SSL: CERTIFICATE_VERIFY_FAILED

[flainn]

Hi all,

About 24 hours ago, weewx stopped being able to upload to Weather Underground. After turning on debugging, I'm seeing this ovr and over:

Jan 30 17:42:41 raspberrypi weewx[18116]: restx: Wunderground-RF: Failed upload attempt 1: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)>

I have emailed Weather Underground about it too. Anyone else experiencing this issue? Did WU's SSL certificate expire?

[vreihen]

I do not see any gaps in my WU data to indicate an upload error.

Did you check the clock on your Raspberry Pi to see that it has the correct time and year 2020?

Is your ISP playing "man in the middle" to intercept your traffic for "virus/malware scanning" and re-encrypting it with their own certificate?????

[flainn]

As we've seen before, it's entirely possible for some weather stations to experience issues uploading to WU, while others continue working fine; I have past threads here which detail that experience. It's possible WU is using multiple SSL certs, with some clients using different ones.

The clock on my rpi is syncing via ntp and is correctly set.

While it's not impossible my ISP (HughesNet) might be doing that, I've never noticed it and, like I said, this only started happening in the last 48 hours. Moreover, uploads to other sites is unaffected (CWOP, PWSWeather).

Been uploading successfully for 2.5 years and made no changes on my end.

From Googling, this issue does seem to come up every few years with WU. I haven't seen a fix other than turning off strict SSL cert verification, which doesn't seem like a fix at all.

[mcrossley]

Try updating your root certs?

Their wildcard cert is for *.wunderground.com and validates OK on my Windows machine - valid from Aug 2019 to Jan 2021

[flainn]

Will look into a way to download a copy of WU's cert. I don't recall that being a part of the process for setting up weewx, which is odd.

[mcrossley]

It's not the WU cert you need, but the root certificate from Digicert. Instructions here: https://www.digicert.com/ssl-certificate-installation.htm

[flainn]

I downloaded the newest Baltimore Cyber Trust root cert from Digicert, attempted to install and it wouldn't -- and it turned out that's because I already had the latest one. No joy.

[flainn]

I came up with a workaround that will do until the folks at WU can respond to my support request.

I changed the lines:

  # the rapidfire URL:
  rf_url = "https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php"
  # the personal weather station URL:
  pws_url = "https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php"

in the file /usr/share/weewx/weewx/restx.py to "http" rather than "https" and uploads to WU started succeeding again.

It's clear something about https uploads broke, but I'm scratching my head as to what that is. It's fortunate that plain-old http uploads still work.

[vreihen]

I'm just going to leave this quote right here:

"This server's certificate chain is incomplete. Grade capped to B." 

https://www.ssllabs.com/ssltest/analyze.html?d=rtupdate.wunderground.com

https://www.ssllabs.com/ssltest/analyze.html?d=weatherstation.wunderground.com

Three different servers/interfaces, and IBM can only score a B on setting up SSL properly..... 

[flainn]

At least that provides some insight. Thanks.

Personally, I don't really care whether my telemetry is encrypted. All the info is public anyway. I suppose someone *could* intercept it, modify it, and submit wrong data, but I doubt anyone would go to the trouble.

[openvista]

Using a certificate is pointless if all WU is doing is processing GET (query variable) requests. I don't even think they are set up to accept encrypted post data are they?

In other words, you are sending all your info, including your id and password, as part of your initial, plain-text request to the server regardless of protocol (HTTP or HTTPS). Literally nothing is transmitted securely from your station. At least that's how all the scripts I've examined worked, including my custom script.

It would appear WU has to support lots of legacy devices transmitting to the HTTP address, so that's why it's still available as an option. 

[vreihen]

More info.  It's not you, it's WU (TM):

https://www.wxforum.net/index.php?topic=38656.0

[MagnetFinch]

Using a certificate is pointless if all WU is doing is processing GET (query variable) requests. I don't even think they are set up to accept encrypted post data are they?

In other words, you are sending all your info, including your id and password, as part of your initial, plain-text request to the server regardless of protocol (HTTP or HTTPS). Literally nothing is transmitted securely from your station. At least that's how all the scripts I've examined worked, including my custom script.

It would appear WU has to support lots of legacy devices transmitting to the HTTP address, so that's why it's still available as an option.

This isn't correct, GET requests still benefit from https. The only thing seen on the wire is the server being connected to. The GET parameters are all passed in the encrypted session.

[openvista]

This isn't correct, GET requests still benefit from https. The only thing seen on the wire is the server being connected to. The GET parameters are all passed in the encrypted session.

My bad. I should have said that all the requested information via "GET" goes into plain-text LOGS on most servers allowing anyone with access to the logs (authorized or unauthorized) to see everything recorded there including user ids and passwords using only a text editor.

[flainn]

Oh, heck, it never occurred to me to post a question in the WU forum rather than the WeeWX forum. I'm glad to see I'm not completely crazy.