When setting up ssl access to URL’s, the method SetCertificatesFile returns ‘true’ and works fine when transferring data via SSL with roUrlTransfer objects, but always returns false when called (via the ifHttpAgent interface) on screen objects such as roVideoScreen and roPosterScreen using the same .pem cert file as the argument.
Any ideas why a cert file would work with roUrlTransfer and not roVideoScreen; I thought the standard curl library is being used to access data?
Thanks
[UPDATE]
After spending (way too) much time playing with this, it looks to me like SSL support in screen components is currently either broken or disabled - can one of the Roku devs confirm this please?
We have a bug in the ifHttpAgent interface that doesn’t allow the certificates file to be read properly. Therefore, all screens that support the ifHttpAgent interface such as roVideoScreen and roPosterScreen cannot currently work with SSL.
This will be fixed in a future update to the firmware, but we do not have a date on when this will happen.
We have a fix included in a firmware update that is currently in beta. Assuming there are no issues, our current goal is to update our user base to this version of firmware the week of Feb 15.
We are rolling out v2.4 build 357 to our entire user base. Just about everyone should have it by Monday. If you want to force an update, you can navigate to Settings->Player Info->Check for Update.
This version of the firmware includes the fix for SetCertificatesFile.
“mosten” wrote:
I’ve asked about the same thing previously, I don’t think it’s even on the roadmap.
SSL is finally working for streams with the build pushed out late last week, which is great, but they haven’t made the client certificate available for SSL from these components. From the component documentation for roUrlTransfer:
Add the Roku CA certificate to the web server’s certificate authorities keychain. The Roku CA certificate is available in the SDK distribution package, in certs/cacert.pem
Configure your web server to reject any connection that does not have a valid client certificate.
Doing the above would block a streams request to the same server.
If you’re serving streams from another computer/3rd party and are not bothered about client verification, SSL works fine for both feeds and streams. It seems insane to me though, that client-side verification wasn’t included in last week’s build.
Note that arbitrary client certificates do not work with the SDK. Only Roku signed client certificates generated by the firmware work.
Roku signed client certificates should work with this build. They provide the ability for your web server to authenticate that its connecting to a Roku box.
The client certificates are unique on each box. The client certificates are signed by a Roku CA, and the Roku CA signing cert is included in the SDK.
If you would like to authenticate that your web server is connecting to a Roku box, you must configure your web server to accept client certs signed by the Roku CA cert.
If you would like to authenticate that your web server is connecting to your particular application on the box, you should also configure your web server to accept connections only from requests with an x-roku-reserved-dev-id that matches the devid from your application pkg.
“RokuKevin” wrote:
Roku signed client certificates should work with this build.
They don’t - the Roku client certificate isn’t being made available by ssl connections made by screen objects such as roVideoScreen, they only work with feed connections made by roUrlTransfer. Please can you confirm this.
The AddHeader() method works in the ifHttpAgent interface… So you could add standard Basic Authentication to access of your video streams.
Assume you’ve setup “video” as an roVideoScreen and specified all the parameters to play a video. Now you want to add basic authentication to it. (You’re already using SSL, so no one can snoop the passwd in the authorization header that is sent in the clear). You can now turn Basic Authentication on your server, test with curl, and then change your brightscript app like so:
video = CreateObject(“roVideoScreen”)
REM setup videoclip associative array to play your video
REM setup SSL on the video object
ba = CreateObject(“roByteArray”)
ba.FromAsciiString(“yourUserName:yourPassword”)
video.AddHeader(“Authorization”, "Basic " + ba.ToBase64String())
OK, this just burned me too. I need to be able to use something like “video.SetUsernameAndPassword(user, passwd)” and apparently thats not there. I just had the webserver folks recompile/reconfigure to use DIGEST auth, because it seemed like BASIC auth is purposely disabled. Now I am starting to get the hint that I need to use basic auth again
