Roku Developer Program

[RokuKevin]

Yes. The common name needs to match.

--Kevin

[joetesta]

OK I started from the top, create the self-signed cert and server keys with my common name on a test domain pointed to my LAN ip, test in the browser & the video plays on the https common name link, still with the same warning "The identity of this website has not been verified".

I followed everything exactly through step 3f and left the "VerifyClient require" & "VerifyDepth" commented out of my conf file.

When I try to access the video hosted on the common name link with the simplevideoplayer app I got the same result from roku:
"play failed: An unexpected problem (but not server timeout or HTTP error) has been detected."

EDIT: I forgot to update my package 'video.SetCertificatesFile()' with the new keys from this new time around - i did that and it worked this time!

So (theoretically at least) it was failing the first time because of common name mismatch; and the 2nd time I just needed to update the keys - now I need to see if I get the actual security part to work...

Thanks very much for your patience helping me with this Kevin!

[joetesta]

Hi Kevin -
Can the BIF files be served using this same authentication method?

I think that the answer is "No" from reading over here viewtopic.php?f=34&t=26258&p=161913&hilit=bif+auth#p161913
but I wanted to ask in case I'm misunderstanding your answer - it sure would be more convenient to serve everything from the same place!

Thank you in advance

[RokuKevin]

The ifHttpAgent interface does not yet affect the BIF file download, so there's no way to protect them using this method.

--Kevin

[joetesta]

Thank you Kevin -

Another question about the SSL Mutual Auth - do you know if this can be used with the streaming sever behind a proxy?

Ideally we'd like to have the content hosted on a server with only a LAN ip but so far I haven't been able to get it to work. I tried setting it up so that the proxy would handle the Auth and rewrite the request to an unprotected (HTTP, not S) stream on the LAN but I'm back to square 1 (video won't play).

Would I need the Auth happening on both the proxy and the backend streaming server?
thank you in advance for any advice or suggestion,
Joe

[RokuKevin]

My advice would be to forget about the proxy server. It would become very complicated and would not scale well.

The extra complication would probably lead to a less secure result.

--Kevin

[tojo]

Hi,
I have been trying to setup the mutual authentication security model as explained in the first post. But I am running into some https issues.
I did the changes to the simpleVideoPlayer Application as suggested by Kevin (SetCertificatesFile("common:/certs/ca-bundle.crt") and InitClientCertificates()).

When I try to play the video, I get the following error - "play failed: An unexpected problem (but not server timeout or HTTP error) has been detected."
If I add roSystemLog to the video player, the message status indicates - "UntrustedCert"

The certificate that is installed in my webserver/apache is proper purchased certificate. But, it is a wild-card certificate -- CommonName is *.mywebsite.com. Could wild-card be the problem?
But, when we use the roUrlTransfer directly for fetching the feed urls from the same server, https goes through fine. Is there any difference in the way https gets handled in roUrlTransfer and roVideoScreen?


--tojo

[tojo]

Found out from the forum that I have to call screen.SetCertificatesDepth(3). That fixed the problem.

[jshah]

From our experimentation, it seems that you cannot set your own client certificate on the Roku. All Roku's use the same "RokuClient" certificate. We had to load the RokuCA on the server so that we could validate the RokuClient certificate.

The consequences of this are that all Roku apps use the same client cert. This means another companies Roku apps could establish an SSL connection to our services. This doesn't provide very much security.

Am I missing something here?

Thanks.

[RokuKevin]

jshah--

Each Roku has it's own unique client cert. All the client certs are signed by the RokuCA.

You are correct that the client cert does not protect you against another company's Roku app establishing an SSL connection to your services. That protection is provided by the authoritative x-roku-reserved-dev-id header. If your web server is checking the value of this devid header, then only applications signed by your key can establish an SSL connection to your services.

This header cannot be forged as the firmware enforces its value. You must implement all pieces of this SSL mutual authentication with devid header to establish encrypted, authorized, secure SSL connections to your services.

Kevin