I have been trying to get the MLBMC addon (MLB.TV) installed in OSMC RC2 but have been running into an SSL issue. Granted, I know 3rd party add-ons are not what these support forums are for - and to that end I am not requesting support for it. More so, I wanted to provide some details on the SSL error itself along with my research/troubleshooting into the issue as I believe it is not due to the add-on itself but the current OpenSSL implementation in RC2. In terms of Pi OS’s, Openelec currently does not suffer from this issue (Raspbmc has not been tested as it is not supported on the Pi 2 and is depreciated in favor of OSMC). The issue is this:
When connecting to certain SSL based servers (mainly HTTPS) an error is thrown by ssl.c CERTIFICATE_VERIFY_FAILED. At first I thought this was a python error (OSMC RC2 uses 2.7.9) but I tried out python 2.7.8 compiled with SSH support (1.0.1K) via secure-shell to no avail (along with breaking OSMC-settings in the process ). After a day of trail and error, I ran across a very thoughtful and concise post over at stack exchange that clearly lays out the issue (included below).
Essentially, with the current OpenSSL implementation in OSMC RC2 (1.0.1K), there is a subtle difference in how it handles verifying chained certificates. Due to how the current version of OpenSSL deals with traversing a chain up to the root, you can end up with SSL verification errors. In the discussion link I’ve included below there is a patch to fix this and is apparently fixed in OpenSSL 1.0.2 with the inclusion of the new option X509_V_FLAG_TRUSTED_FIRST.
I thought I would post this since this bug can affect connecting to a multitude of secure servers and that providing this information may help the developers. If OpenSSL 1.0.2 could be included in the next release or the current patch implemented and incorporated via the OSMC System Update feature to fix this bug in current RC2 installations, that would be absolutely fantastic.
Oh and to the developers, really, really great job on OSMC. I’ve learned a ton about it’s underpinnings via SSH shell and it has taught me so much! Thanks again for all of your efforts.
There is one on depth of certificate verification, but it does not seem applicable to your issue. I suggest you report a bug to Debian as we cannot fix this unless we choose to ship our own version of OpenSSL, which does not seem ideal, considering it should be fixed soon.
Thanks for the quick response! It should have dawned on me that the packages come upsteam from Debian (I’ve been messing around with these packages after all - I’ll go with a little lack of sleep as well) and isn’t something you can include directly. The bug has already been submitted. I’m pretty bored at the moment so maybe I’ll take a stab at compiling 1.0.2 myself and see where that gets me - probably nowhere other than a reformatting of my sdcard by the end of my journey but it’s all in good fun.
This is semi-off-topic, but it’s interesting to see that there is a lot of chatter about moving away from OpenSSL in favor of LibreSSL. There is a portable deb version available now the openBSD repository. It’s obviously not something Debian supports in their repo but it looks interesting at the very least.
We can include it directly, but it’s not going to give us any longterm benefit, unlike other Debian packages which we have packaged and decided to ship ourselves.
If it has identical symbols to OpenSSL then it’s feasible. Whether it provides us any benefit over the current implementation is yet to be proven. I’m wary of adding something new like this. Yes OpenSSL has had some vulnerabilities in the past year, but every time I see a hipster fork of something (Debian without SystemD), LibreSSL, I always think it’s best to sit back.
). After a day of trail and error, I ran across a very thoughtful and concise post over at stack exchange that clearly lays out the issue (included below).