Value of ca-bundle.crt?

One way is from the console:

?readasciifile("common:/certs/ca-bundle.crt")

-JT

Got it! Now, what is the name of the field in the roUrlTransfer header -- is it just `certificate`?

"VikR0001" wrote:
For purposes of debugging the back-end, I need to make calls to it from Postman. 

How can I get the value of the `ca-bundle.crt` file for inclusion in the call made by Postman?

You don't.

Assuming you are trying to do what you say: use Postman as a client to make requests to your API server, and not use Postman as a proxy to intercept calls from the Roku device to the API, then you shouldn't have to do anything with the Roku certificates file.

The Roku certificates bundle file contains the certificates for well-known Certificate Authorities (CAs) used to sign server certificates. It allows the Roku device to check that it is communicating with the correct server and not some man-in-the-middle hacker. Presumably your server certificate is signed by one of these CAs otherwise your Roku roUrlTransfer calls would fail.

I would imagine that Postman would have its own certificate bundle file, as do most https clients (Rokus, browsers, curl, etc), so it should have no trouble communicating with your server using https. If for some reason Postman does not recognize your server's certificate, then it does have a setting where you can turn off SSL certificate validation.

"belltown" wrote:
You don't.
[...] you shouldn't have to do anything with the Roku certificates file.

since Roku's cert file might be limited in authorities listed, i imagine using it instead of a bigger bundle makes server API QA a bit closer to reality.

Sidebar: if someone suspects there is some "secret sauce" in the common:/ bundle that say allows access to Roku Inc. private services... nope, there ain't no such thing.

belltown wrote:

you shouldn't have to do anything with the Roku certificates file. 

I see the Roku docs recommend using the following to authenticate the roUrlTransfer call:

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

Since the certificates file isn't required for security, that seems to leave just the developer id as a way of protecting against unauthorized callers contacting my back-end REST endpoint.

Is that really enough? Couldn't someone hack a Roku, get the developer id for my app, and use it to send unauthorized calls to my REST endpoint?

Or am I missing something?

The call to InitClientCertificates() instructs the Roku to use Client Authentication, in addition to the Server Authentication you get with SetCertificatesFile(). With client authentication, communications with the server are encrypted using the Roku Company private key securely embedded in the Roku firmware. I'm not aware of any way to "hack" the Roku Company private key. Your server would use the Roku Company public key, which you'd have to configure the server to use, to decrypt its communications with the Roku. You can be confident that if you've configured your server correctly, any data received would be from a legitimate Roku device. Adding the developer ID header will further ensure that the data is coming from an application signed with your developer key.

Note that if you're testing your Roku channel from a side-loaded channel, then the developer ID used in the header will not be the same as one used if your channel has been loaded from the channel store. Your server software would need to take that into account.

Thanks very much for this info.  

My shared server uses a free SSL (Let's encrypt) and it's only valid for 3 months. After 2 months, the hosting provider renew the certificate (I guess they install a new one then remove the old one after some days). During the transition time does it cause any problem such as Roku device doesn't recognized the new certificate?