Roku Developer Program

[RokuTomC]

This Saturday, May 30 at 10:48:38 2020 GMT, the widely-used "AddTrust External CA Root” certificate will expire. If your Roku channel still includes this certificate at this time it will have connection issues. These issues may manifest themselves in a variety of ways, including failures with channel launches, video playback, image rendering, or analytics.

Here are some details about the expiration and how it impacts OpenSSL 1.0.0 platforms like Roku OS:

https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-ex...

Certificates that have multiple chains of trust where the "AddTrust External CA Root” certificate is in only one trust chain will get an SSL handshake failure on Roku OS, but not on other platforms that can authenticate the second trust chain.

Please check that the trust chain for any SSL certificates used to support your channel do not include the "AddTrust External CA Root" certificate. You can check this by hitting the SSL endpoints your channel uses with the script shown at the bottom of this post. The script must run on in a linux environment with OpenSSL installed.

If you find a cert that lists the "AddTrust External CA Root" certificate, please update the certificate to avoid any connection issues. As an exception to our standard policy, Roku will publish channel updates that resolve issues related to this cert expiration throughout the weekend. If you submit a channel update during the weekend, please also open a ticket with our Partner Success team to request that they publish your channel.

If it is impossible for you to update the certificate and you could avoid validating the trust chain on a connection, you could modify your BrightScript channel using: roUrlTransfer.EnablePeerVerification(False)

Please be sure to share this message with your Roku engineering team. If you have any questions pertaining to this issue, you can submit a question to Roku’s Partner Success team.

Thanks for your prompt attention to this issue. Below is the script you can use to hit your SSL endpoints:

#/bin/bash

openssl s_client -no_alt_chains -showcerts -verify 5 -servername ${1} -connect ${1}:443 < /dev/null | awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; out="cert"a".crt"; print >out}' && for cert in *.crt; do newname=$(openssl x509 -noout -subject -in $cert | sed -n 's/^.*CN=\(.*\)$/\1/; s/[ ,.*]/_/g; s/__/_/g; s/^_//g;p').pem; mv $cert $newname; done

[andro23]

Hi,

Thanks for the heads-up. Will this affect SSL connections using common:/certs/ca-bundle.crt?

Example: 

object.SetCertificatesFile("common:/certs/ca-bundle.crt")
object.AddHeader("X-Roku-Reserved-Dev-Id", "")
object.InitClientCertificates()

 Thanks!

[RokuTomC]

Good question, thanks for asking.

The common:/certs/ca-bundle.crt file does currently contain the cert which is expiring. We may deploy a patch Roku OS 9.3 update which removes this cert, but there are no commitments just yet and you should not rely on this from Roku.

The main urgency is around fixing the cert in your servers. In our internal testing, we did not encounter major issues when the cert was included client-side.

So, while there is a non-zero risk of your channels being impacted if they’re using our common cert bundle file, the risk is low.

[RokuTomC]

The following links may be useful references:

https://ohdear.app/blog/resolving-the-addtrust-external-ca-root-certificate-expiration

https://access.redhat.com/articles/5117881

[OddScott]

Tom,

I'm seeing this issue with a 3rd-party CDN.  I'm a bit confused because the script that you provided does not indicate that the CDN is using the AddTrust certificate:

verify depth is 5
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = cdn2.instanttvchannel.com
verify return:1
DONE

Here's an example URL. The SSL version no longer works on the Roku platform, but it does work correctly in current browsers.

https://cdn2.instanttvchannel.com/sample_ad.mp4
http://cdn2.instanttvchannel.com/sample_ad.mp4

I have two questions:

1) The suggested roUrlTransfer.EnablePeerVerification(False) workaround seems to only affect that particular instance of roUrlTransfer instead of being a system-wide setting. Can you provide a specific example of how roUrlTransfer is used to prevent Video nodes from failing to verify certificates for SSL stream URLs?

2) If I understand the UC Berkeley advisory correctly, OpenSSL 1.0.0 currently used in Roku OS has "broken certificate path validation logic". I believe this is what you are referring to when you mentioned that Roku OS will have a handshake failure under certain circumstances. In addition to updating the certificates list, are there plans to update Roku OS to use the current stable version 1.1.1 of OpenSSL sometime in the very near future?

Thanks,

Scott Musser

Instant TV Channel

[tifroz]

Is there a workaround for Channels that do not directly control the streaming servers? The suggested roUrlTransfer.EnablePeerVerification(False) does not apply to requests sent by the Video Player

[OddScott]

After some further experimentation, it seems that my problem was caused, at least in part, by an SSL certificate purchased last year from Namecheap.com and configured into the CDN. After installing a new SSL certificate purchased from GoDaddy.com today, the problem is resolved!

[RokuTomC]

Unfortunately, your only option is to add this API call to your channel source. If this isn't possible or isn't resolving your issue, then the only remaining option is to wait until Roku OS 9.3.0 v4170 is fully deployed. 4170 includes a ca-cert bundle update.

Note also that any end-user on a set-top box or streaming stick can currently manually update to 9.3.0v4170. Roku TVs will fast-follow with a patch.

[tifroz]

Sorry if I am being dense, but I think you are suggesting that the httpAgent of a VideoNode can be configured to work around the expired certificate? If so, can you provide an example of the API call you are referring to?

My current understanding is that the EnablePeerVerification() API is only available to roTransferUrl objects, which do not affect VideoNode requests to streaming servers. Correct me if I am wrong here?

[brianstegman]

@RokuTomC  I submitted an update yesterday at 5pm and notified partner success but still have not heard back from them nor has the update gone out.  I have customers complaining.  Do you know when I can expect to hear back from someone?  In the message above it states they are working over the weekend.

Thanks