HLS via HTTPS fails on Android

I have set up a new application on WSE 4.5, and everything works well, except that playback of HLS streams on Android devices fail when the manifest is access via HTTPS (it works via HTTP). The same behavior happens with live or vod streams.

I compared the generated manifest to a manifest from a test stream I set up on Wowza Cloud, and the main difference I noted was that the path to the chunklists are relative in the Streaming Engine manifest, and absolute in the Wowza Cloud manifest…see below:

Streaming Engine 4.5:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=2292000,CODECS="avc1.100.31,mp4a.40.2",RESOLUTION=1280x720
chunklist_w1857459623_b2292000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1392000,CODECS="avc1.100.30,mp4a.40.2",RESOLUTION=848x480
chunklist_w1857459623_b1392000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=704000,CODECS="avc1.77.31,mp4a.40.2",RESOLUTION=640x360
chunklist_w1857459623_b704000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=576000,CODECS="avc1.66.12,mp4a.40.2",RESOLUTION=424x240
chunklist_w1857459623_b576000.m3u8

Wowza Cloud (some info obfuscated for security):

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=8000348,CODECS="avc1.77.40,mp4a.40.2",RESOLUTION=1920x1080
https://foo.akamaihd.net/hls/live/xxx/bar_1_4128/chunklist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3649866,CODECS="avc1.100.41,mp4a.40.2",RESOLUTION=1280x720
https://foo.akamaihd.net/hls/live/xxx/bar_1_2728/chunklist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2402944,CODECS="avc1.77.40,mp4a.40.2",RESOLUTION=854x480
https://foo.akamaihd.net/hls/live/xxx/bar_1_1728/chunklist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1522330,CODECS="avc1.77.32,mp4a.40.2",RESOLUTION=640x360
https://foo.akamaihd.net/hls/live/xxx/bar_1_1152/chunklist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=916373,CODECS="avc1.66.30,mp4a.40.2",RESOLUTION=512x288
https://foo.akamaihd.net/hls/live/xxx/bar_1_640/chunklist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=611516,CODECS="avc1.66.30,mp4a.40.2",RESOLUTION=320x180
https://foo.akamaihd.net/hls/live/xxx/bar_1_448/chunklist.m3u8

I’m using JW Player 7, but the result appears to be unrelated to players, as entering the manifest URL’s directly into Chrome on Android exhibits the described behavior (HTTP works, HTTPS fails).

The manifest samples above are adaptive, but single-rendition manifests behave identically.

Both HTTP and HTTPS will work as expected on desktop and IOS. Perhaps this is an Android bug or quirk, but if the chunklist URL’s are the key, is there any way to force WSE to use absolute URLs in the manifest?

I can provide working test URL’s via PM or email if you’d like.

Checking back in on this to see if anyone else has a similar experience or suggested fix…

I have set up a new application on WSE 4.5, and everything works well, except that playback of HLS streams on Android devices fail when the manifest is access via HTTPS (it works via HTTP). The same behavior happens with live or vod streams.

Came up with this thread on a Google search, having the same problem. Maybe my solution will help the OP or anyone else.

Turned out this was nothing to do with the streams, chunk URLs or playlists. The problem was the fact that the Java keystore (JKS file) used on the Wowza side to stream SSL HLS, did not include any CA cert info in the chain. This seems to be a problem for Android Chrome (although nothing is reported, it just doesn’t play), but not a problem for any other browser or device. This is also the reason why the free Streamlock certificates from Wowza will not work (on Android only).

My symptoms were similar:

  • HTTPS playlist URL failed on Chrome Android, HTTP playlist URL worked (trying with JWPlayer)

  • HTTPS playlist URL failed and HTTP playlist URL worked (typed directly in the address bar of Chrome on Android)

  • A “curl #HTTPS_PLAYLIST_URL” failed with “unable to get local issuer certificate”

    I used an existing Thawte-signed wildcard certificate for my domains, and here are the correct commands to create a working Java keystore on the Wowza server command line:

    openssl pkcs12 -export -in #CERTIFICATE_FILE -certfile #CA_CERT_FILE -inkey #SSL_KEY -out test.p12
    keytool -importkeystore -srckeystore test.p12 -srcstoretype PKCS12 -destkeystore test.jks -deststoretype JKS
    cp test.jks /usr/local/WowzaStreamingEngine/conf/
    

    Configure Wowza to use the test.jks keystore for SSL streaming, and you’re done.

Hi Jermaine –

Thanks for the pointer. When the properties in the referenced article are set, the manifest and chunklist are indeed returned with absolute URL’s – but the are all HTTP, and never return HTTPS, regardless of what protocol the request was initiated from. Is there another property or fix for that? The configuration reference doesn’t mention anything.

Thanks ~

-JDW

Hello!

Thanks for contacting Wowza Forums!

Here is an article that can help you HERE

Regards,

Jermaine

Hello,

Here are some properties you can also set. This should resolve your issue:

This should be possible to resolve using a couple additional HTTPStreamer properties to your Application.xml file:

mpegdashHttpRedirectEnabled

true

Boolean

mpegdashPlaylistHostProtocol

https://

String

mpegdashChunkHostProtocol

https://

string

Add the following to the last container in the Application.xml file:

mpegdashAddMPDSegmentBaseURL

true

Boolean

Let us know if this resolves your issue.

Regards,

Jermaine

I can confirm that this solved the SSL HLS playback issue on Android for me. thx apochr!

Hi,

I’m facing exactly the same issue. On my android phone, the HLS stream over HTTPS does not work, while it does work on iPad and Desktop.

The properties “cupertinoRelativePlaylistPlaylists” and “cupertinoRelativePlaylistItems” does enable absolute HTTP urls in the playlist.m3u8 and chunklist.m3u8 files, but Android seems to need HTTPS urls.

I tried the set the several properties above, but it has no effect, the generated m3u8 files contains HTTP urls, and not HTTPS urls.

Can you advise me ?

regards,

Ben

Ok i managed to make it work, by setting the properties :

cupertinoHttpRedirectEnabled = true,

cupertinoPlaylistHostProtocol = https,

cupertinoChunkHostProtocol = https

Benjamin

Having the same problem… over http runs ok in android, but over https don’t (works correctly on the rest of devices, PC, iPad…).
I add next custom properties to my app, in path /Root/Application/HTTPStreamer

cupertinoHttpRedirectEnabled = true
cupertinoPlaylistHostProtocol = https
cupertinoChunkHostProtocol = https

And enable cupertinoRelativePlaylistPlaylists, and set it to false.

Playlist generated with absolute URL in https protocol, but steel not work on android :frowning:

Have the same problem, but can’t resolve it. Any other detail how you solve the issue?

Android 6 using Chrome seems to happily accept HTTP streams even in an HTTPS page, so we just did a quick JS hack to check the user-agent and then change the stream URL to HTTP instead.

Of course, only possible for streaming servers available over HTTP and HTTPS, but luckily ours is.

Would have done a more through fix, but our customer base is not likely to have many Android 6.0 devices for much longer.

Hello,

As mentioned earlier in the post Android devices are more sensitive to issues with the SSL certificate chain than some browsers. Typically this issue is caused by a missing or incorrect intermediate certificate. We suggest testing your server with a website that checks the certificate chains such as SSL Labs.

Instructions on how to import the missing chain certificate can be found here.

Best regards,
Andrew

Thanks Andrew, this was my issue. Rebuilding the certificate, solution my problem. Wowza rebuild the certificate for me, and solve it. I don’t understand very much what was exactly the problem.