Have you run software updates recently? If not, I suggest you do so. If you have, then ubuntu are probably shipping an out of date certificate. Unfortunately the error message does not identify the expired intermediate certificate (in fact, the libcurl error message is next to useless).

I doubt the nexdef streams are going to go away, because they are at present used by the MLB.TV web client and are the focus of their attention. The rtmp streams are much more likely to be for the chop. (The web client does not happen to use the java nexdef plugin any more when accessing the nexdef streams except when in legacy/audio overlay mode, but that's a different issue.)

Yep, updated yesterday. It doesn't seem likely that Ubuntu would ship bad certs, but it seems very likely that mlbhls's use of libcurl might get tripped up by something else. I'm at work now but I'll try re-updating when I get home and maybe switching the version of libcurl (I think there's an openssl flavour as well as a couple others available). And who knows, it might just start working again magically...

Right, got it, that makes sense -- so then the video format would stay the same but they have some new way to play it in the web client and so can advertise "no more nexdef". That would be nice, since it means mlbhls might just keep working forever... (Assuming I can get it to work at all, of course. )

This is the reason I've moved onto Kodi (formerly XBMC) as my media player. They have ports that support accelerated video for almost every hardware platform/operating system (x86/x86_64, ARM, MIPS, Android, Linux, Windows, Mac, etc). Not all platforms have properly accelerated video but if you're careful in what you buy, like the raspberry pi, you'll be OK.

I use the opensssl flavor of libcurl so that's a data point of what works. Hope that helps.

Well, I still can't get this working, after trying just about everything I could think of short of diving into any actual code. Resintalled libcurl, reinstalled libssl, tried the other libcurl flavors, tried an unpatched mlbhls, upgraded the system... and I get the error every time. The problem does seem to be limited to my Ubuntu boxen though -- I tried installing everything on an old machine running Debian Squeeze and it worked a treat. But the Ubuntu machines still get the same curl error.

So I guess this is either an Ubuntu bug or a bug somewhere else that only Ubuntu (and maybe just 14.04) notices? And I guess the only thing to do is... wait for an update (and use the rtmp streams in the meantime)? That isn't a disaster for me, especially during spring training, but if anybody has any other thoughts on what might be going on I'd appreciate it.

Try the --insecure option to curl which tells it to ignore the certificate verification result. You can put this in .curlrc as the word "insecure" on a line by itself.

I have Ubuntu 14.10 so there's another data point for you. If all else fails, the live CD works very well through VirtualBox if you use the install script to create the template with hardware acceleration for graphics. I don't know what the minimum requirements are but a relatively new machine like dual-core and 1 GB RAM or more should work for running it in virtual machine mode. The virtual machine itself is only a single core and 512 mb memory.

Well, I've done some more digging, and I think I've found something strange. The short version is: it looks like there is indeed a self-signed certificate in MLBAM's chain, which my 'broken' Ubuntu machines (sensibly?) don't trust, but which my 'working' Debian machine silently ignores. This is strange because it seems like my 'broken' machines are actually showing the expected behavior, while 'working' machines are not.

The longer version:

On an up-to-date 'broken' Ubuntu 14.04, I used curl on the command line to download the url in the error message, with the same result:

That's not very specific, so I tried downloading the same link with wget, and lo, the same behavior, with a more specific message:

Some Googling revealed that openssl has a command-line client that can be used to debug further:

I'm no SSL expert, but that last one does look like a self-signed cert to me: unlike the others (or any in a chain for a url like wikipedia.org), its subject is the same as its issuer.

Then I checked on my up-to-date Debian Squeeze (now LTS) machine, on which mlbhls works as expected. I don't want to keep cluttering the post with output messages, but suffice it to say that the openssl s_client command above produced the exact same certificate chain as above, the same error 19 message, and the same hang afterwards. So this machine's openssl command was seeing the same error as the Ubuntu box.

Then I tried curl on the Debian box:

(That 'bammmws' looks to be the correct content of that page -- Firefox will also show that, even on the Ubuntu box.) I also tried wget on the Debian box and it downloaded the page just fine. That box does not have a ~/.curlrc or a ~/.wgetrc file.

So, that makes it look to me like the Ubuntu boxes are refusing to accept a self-signed certificate, which seems like a reasonable thing to do, and the Debian box (and maybe all of your working setups?) are accepting it without complaint (which seems bad?).

pajamian, your suggestion to have curl ignore the verification works a treat when I use curl on the command line, but doesn't seem to affect the behavior of libcurl (which is what mlbhls uses). But anyway, is it really a good idea to just disable a security warning (indeed, *all* security warnings that curl might raise)? Frankly, now I'm getting more worried about my Debian box silently ignoring cert errors than I am about getting mlbhls working...

But maybe I'm overlooking something stupid here? Do other people see the same error when running 'openssl s_client -connect mlb-ws.mlb.com:443'? Is there some sort of new/old SSL exception that changes the expected behavior in this case? Can I or should I change the way libcurl handles this error?

Sorry for a long post for a problem only I seem to be having, but if it makes sense to anybody else I'd appreciate it if you could let me know.

In the meantime, I'm loving the RTMP streams!

Oh, and thanks for the suggestion, but this pretty much rules it out I'm afraid -- the computers I use for mlbviewer are two first-gen Asus EEEs and an OLPC! (Indeed, mlbviewer is a lifesaver for these machines, since they don't have the juice to run the bloated official in-browser setup. )

Well, the root CA certificate is always self-signed, it has to be because there is no higher-level cert to sign it with. That's not the problem, but this does show what the actual issue is.

The root CA certificate is not supposed to be included in the certificate chain, various browsers already have it installed so it's not needed to include it twice. MLB is including it in the certificate chain, though and that appears to be confusing your version of libcurl (mine handles it just fine). It would appear that most SSL/TLS libraries can handle this minor infraction but some can't, so this is really an issue from MLB.

From your end, I would try a different curl implementation (as daftcat originally suggested try the openssl flavor instead of the nss one or vice-versa). I'm not sure if there is anyone here who has a contact at MLB or knows how to file a bug report to get them to fix their server to not send the root certificate with the rest of the chain?

Oh, incidentally, s_client isn't "hanging", it's connected to a http server which is now waiting for your input. Typing QUIT will tell the server to close the http connection. I normally include the QUIT on the command line when doing my diagnostics:

1 members found this post helpful.

In addition to what pajamian said (that you don't need the root certificate in the server's announced certificate chain), I should check that in the non-working machines you have the root certificate ValiCert_Class_2_VA.pem or ValiCert_Class_2_VA.crt (or whatever ubuntu happens to call it) in both /etc/ssl/certs and /usr/share/ca-certificates/mozilla (the first is usually a symbolic link to the second). If you haven't, copy the certificate across from one of your working machines and run c_rehash.

1 members found this post helpful.

Wow, terrific, thanks pajamian! I'm still a little fuzzy on some of the TLS details, but apparently unlike me you actually know what you're doing with this stuff, so I'm happy to take your word for it based on your diagnosis of the cert chain.

Unfortunately, I already am running the openssl flavor of libcurl (libcurl4-openssl-dev on Ubuntu 14.04), and I've also tried the nss and gnutils flavor with the same results. But the fact that wget shows the same behavior (on Ubuntu 14.04 only) makes me wonder if the workaround might be happening somewhere else?

I suppose worst-case, I could go hunting through mlbhls's source to add the insecure flag to (at least) this particular curl call... But that seems neither easy nor a very good solution to an upstream problem, so any other suggestions of how to work around it would be appreciated!

WINRAR! That certificate was indeed missing from the broken machines and present on the working one. For reference, in case anybody else runs into this problem, I actually had to copy the ValiCert_Class_2_VA.crt file from the working machine to the /usr/share/ca-certificates/mozilla folder of the broken machine and setup the symlink to the /usr/ssl/certs/ folder like so: At that point, c_rehash could find it all right, and running it (as root) with no arguments found the new cert and I get on an Ubuntu 14.04 machine.

I guess that leaves me with three follow-up questions:

1. Is there someplace online where that ValiCert file can be safely downloaded in case this happens to anyone who doesn't have a working system handy?
2. If having that cert fixes the problem, is it really still an MLB bug, and should we bother trying to report it?
3. Is the missing cert also/instead an Ubuntu bug and should I try to report that?

Thanks a heap for everyone's help on this, trying to understand that openssl stuff felt like reading hieroglyphics. Really glad I posted that output and that you guys knew what it meant and where to look for a fix.

Oh yeah and I forgot to mention -- mlbhls works perfectly now, just in time for me to see Bob Uecker call the Cubs game!

Thanks again guys!

You can download it from https://certs.godaddy.com/repository as "valicert_class2_root.crt" under "ValiCert Legacy Certificate Chain".

EDIT: Take care. It is legacy because it only has 1024 bits of encryption (see next post).

Chris