Roku Developer Program

[bmckim]

I can not get HLS to play over SSL. When making regular HTTPS requests in a separate app I am able to use
SetCertificatesFile("common:/certs/ca-bundle.crt") and it works fine. I have also tried my own .pem with both certificates included. I am using DigiCert as my CA. The cert is a wildcard for *.telvue.com.

video.SetCertificatesFile("common:/certs/ca-bundle.crt")
'video.SetCertificatesFile("pkg:/source/telvueCA.pem")
'video.SetCertificatesDepth(3)
video.InitClientCertificates()
video.SetContent(videoclip)
video.show()

------ Running ------
srt = 
SYS LOG: Status: untrustedcert
LogType: http.error
TargetIp: xx.xx.xx.xx
HttpCode: -1

[OddScott]

Just in case it was accidentally overlooked... you did try with video.SetCertificatesDepth(3) not being commented out, right?

[bmckim]

Correct, I tried that as well.

[bmckim]

Anyone? 😞

[eviljames]

Hi there,

For what it's worth, I've been seeing very inconsistent results with my own HLS / SSL implementation. I'm also using DigiCert as my CA, as is Amazon's CloudFront service.

What I find a bit odd is that other HTTPS requests to the server complete without issue, but should I feed https into the roVideoScreen (even with code exactly as yours) the https calls to the m3u8 fail (apparently prior to request, because there no log noise about them). When I remove https from the m3u8, and the TS chunks within are over https, the same result:

request failure: -3 An unexpected problem (but not server timeout or HTTP error) has been detected.

If assets are sent over HTTP, things succeed. The most baffling part is that my HTTPS requests (mp4 video assets, https/m3u8, https/TS chunks) were working fine on Friday, and without any code changes they no longer succeed on Monday.

[RokuRobB]

Something that worked in another case was to just take the top level cert (and not the rest of the lower level ones in the chain of trust heirarchy) and save that as your PEM file. Then make sure that SetCertificatesDepth is set to the right depth and try again.

[eviljames]

Something that worked in another case was to just take the top level cert (and not the rest of the lower level ones in the chain of trust heirarchy) and save that as your PEM file. Then make sure that SetCertificatesDepth is set to the right depth and try again.

Thanks for this suggestion, it may work for some. However, if you are securely connecting to a web service, followed by attempting to securely connect to a CDN where you don't set the SSL Cert, this method would not work - for example in the case of HLS assets where the m3u8 is fetched from one service, and it references TS chunks on another.

I find it very odd that HTTPS calls to my service to get asset information work very well, but if I provide an https link to the roVideoScreen object, with SetClientCerfiticates("common:/certs/ca-bundle.crt"), that the request fails BEFORE any call is attempted to the server. Is there any way to get better debug information to see what precisely is failing?

[eviljames]

PROGRESS! I've cranked SetCertificatesDepth(8) - much higher than I would've expected it to need being. Things are working well on this end.

This might arise from DigiCert CA being signed by another (more valid?) authority. Instead of just verifying your cert against the ca-bundle, the device appears to need to validate DigiCert against something higher up in the chain.

[bmckim]

"RokuRobB" wrote:
Something that worked in another case was to just take the top level cert (and not the rest of the lower level ones in the chain of trust heirarchy) and save that as your PEM file. Then make sure that SetCertificatesDepth is set to the right depth and try again.

So I should just put the DigiCert cert in my .pem file and not the one for my domain? What would the depth then be? 2?