[BUG] No remote movie can be played on Immich Mobile using a Self Signed CA and a proxy in front of IMMICH server/microservices

[amitrea]

The bug

Please NOTICE This is NOT an issue of transcoding. Please read well the thread. This is SSL issue related to flutter videoplayer that IMMICH mobile app is using to play remote videos on Android mobile. Trusted Self signed certificates (registered in Android) should be valid also for playing videos as it is for images or other API calls to IMMICH server.

I cleanly install Immich mobile on two Android phones (Samsung & Huawei - no relevance as long as it worked on previous versions of Immich Mobile 1.89.0). On one phone I had it already installed, version 1.89.0. I cleanup cache and data for Immich Mobile App and then re-authenticated. On the second phone I installed for the first time. Movies don't play on both mobile devices in Android Immich App.

All images and movies previews looks OK. Seeing a full picture works. Playing an existing movie doesn't work. It is stuck on loading the stream. I tried random movies and have the same issue.

Previous to version 1.89.0 I could play movies. I remember that I didn't tried to play a movie with version 1.89.0, but for sure with the previous versions.

In Immich Mobile logs I could not find any INFO, WARNING or ERROR. On the server side (server or microservices) no INFO, WARNING or ERROR.

On Immich Web (mobile or desktop browser) playing movies works fine.

The OS that Immich Server is running on

Fedora 38

Version of Immich Server

v1.90.1

Version of Immich Mobile App

v1.90.0

Platform with the issue

• [ ] Server
• [ ] Web
• [X] Mobile

Your docker-compose.yml content

N/A (Everything works fine on Web)

Your .env content

N/A (Everything works fine on Web)

Reproduction steps

Please see in the description.

Additional information

Please note I am using my own PKI. I have installed the private root CA into Android (User Certificates), so it's in trust store of Android. I checked this in every browser I have on my mobile to see if my ROOT CA certificate is considers, and indeed no more SSL warnings/errors.

In Immich App I enabled Self-Signed cert. All functionality except videoplayer flutter plugin is working fine. It seems that the videoplayer plugin uses its own SSLSocket.

I saw the error message in Caddy: Unknown certificate but only when I try to play a movie. For the rest of Immich API calls I do not get SSL error.

For more info please check a bit the code for videoplayer flutter plugin here.

In my opinion Immich should trust as well the certificates user adds in Android trust store and probably no need to specify "Allow Self Signed Certificates". This option is a security issue - to trust every Self Signed Certificate. This could be an option only in a DEV environment.

[alextran1502]

Did you change anything relating in the transcoding video settings?

[amitrea]

Hi @alextran1502

Yes, target resolution is 4k. It was the same before, when I was able to play them from Immich Android app.

However, I highlight it again, from browser it's fine.

[alextran1502]

Did you change the codec? Can you post the screenshot of transcoding settings?

[amitrea]

Sure.

[alextran1502]

Can you try revert the transcoding settings to default, then record and upload a new videos and see if it works on your phone?

[amitrea]

I suppose you want to identify where is the issue.

I will record a video, upload and then play. Can you remind me what was the default resolution? 1440p or 1024p?

[alextran1502]

The default is 720p.There is also a button to reset to default at the bottom left corner

[amitrea]

Test 1: By mistake, I was a bit focus on making the movie and forgot to reset the resolution, still 4k.

I opened immich Android app and uploaded. Playing is fine. I deleted locally from my phone Gallery and tried again. It doesn't work.

Test 2: I changed the resolution to 720p. The same as above, playing OK until you delete from local Gallery.

Test 3: Change resolution to original. The same as above.

My conclusion, maybe yours is different: As long the the movie is on my local Gallery it works, if I delete the streaming from server doesn't work.

Can you please try on your side as well?

[amitrea]

I also reset all values from Transcoding section to default. Did the same as in previous tests and the same behaviour. It doesn't work if I delete it from local Gallery.

[alextran1502]

What are the movie settings on your phone's camera?

[amitrea]

4k

[alextran1502]

Do you see any logs in the server container when you are trying to stream the video on the mobile app?

[amitrea]

As said in the description no logs on server side (server or microservices) and on mobile app logs.

By the way, I mentioned that the issue is on two distinct Android phones: Huawei Mate Pro and a Samsung A somthing (do not remember).

If I login to immich from browsers on both phones it plays the videos OK.

[tomikonieczny]

Mobile app (android S23 Ultra) v. 1.90.2 build.2114

Transcoding OFF

It looks like there is an issue with playing HEVC media, H.264 is fine.

[amitrea]

I understand that the application (web or mobile) streams the transcoded video file and play it on the device. So, in this case does not matter if the video was recorded in H.265 because the transcoded video, as one can see in the transcoding settings I attached above, is H.264.

In your case maybe would be a different issue! When you say "H.264 is fine", it plays the video from mobile disk or only from remote (Immich)? It is working to me as well when I have the mp4 locally but when I delete it from my Phone Gallery (not through Immich App)it doesn't play the remote one.

My videos are encoded in HEVC (camera calls it Efficient Video Format) and the video player that Immich Android App is using, does't have any issue to play it as long as it is on local disk. I checked the format of my video with `ffmpeg -i video_1.mp4'.

Something is wired - at least an INFO, better an exception !

[tomikonieczny]

It is working to me as well when I have the mp4 locally but when I delete it from my Phone Gallery (not through Immich App)it doesn't play the remote one.

Yes, I've just recreated exact same case. When HEVC file is locally available player works otherwise doesn't.

Logs from immich_server: [Nest] 7 - 12/08/2023, 10:05:41 PM ERROR [ErrorInterceptor] Failed to serve file [Nest] 7 - 12/08/2023, 10:05:41 PM ERROR [ErrorInterceptor] Error: Request aborted

I've been logged in by external IP (port 2283 and 5432 are forwarded to local IP). I've decided to log in by local IP and then HEVC files started been playing.. Relogin helped? Missing forwarded ports to local IP?

[amitrea]

OK, I tested also connecting with Immich mobile app using directly the FQDN behind the proxy (http://immich-server.svc.local:3001/api) and started being playing the videos. I use latest Caddy v2 proxy behind all my services, with SSL stop on proxy. The URL is https://immich.svc.local). The authentication is done through an OpenID implementation.

As mentioned already everything is working fine through the proxy when accessing the application through browser, using the last URL provided above.

So, the bug is in Immich Mobile App or in a dependency library (flutter videoplayer plugin).

...

Later on after a bit of investigation:

Please note I am using my own PKI. I have installed the private root CA into Android (User Certificates), so it's in trust store of Android. I checked this in every browser I have on my mobile to see if my ROOT CA certificate is considers, and indeed no more SSL warnings/errors.

In Immich App I enabled Self-Signed cert. All functionality except videoplayer flutter plugin is working fine. It seems that the videoplayer plugin uses its own SSLSocket.

I saw the error message in Caddy: Unknown certificate but only when I try to play a movie. For the rest of Immich API calls I do not get SSL error.

For more info please check a bit the code for videoplayer flutter plugin here.

In my opinion Immich should trust as well the certificates user adds in Android trust store and probably no need to specify "Allow Self Signed Certificates". This option is a security issue - to trust every Self Signed Certificate. This could be an option only in a DEV environment.

I will amend the description with my findings.

[Liujun3712]

I found the same issue when I changed the transcode setting to HEVC and re-transcode all the videos today. All the video just cannot playback. Now, I am trying to use VP9 codec and re-transcode all.

Version of Immich Server v1.90.2

Version of Immich Mobile App v1.90.0 in iOS

[amitrea]

This is NOT an issue of transcoding. Please read well the thread. Please open another issue for your issue.

This is SSL issue related to flutter videoplayer that IMMICH mobile app is using to play videos on Android mobile. Trusted Self signed certificates (registered in Android) should be valid also for playing videos as it is for images or other calls to IMMICH server.

[br4yd]

I can confirm this bug. I run my server on a Synology NAS behind their proxy server using Tailscale to connect from the outside because no public IPv4 (provider only serves DS_Lite). I had everything running via HTTP but eventually switched to HTTPS using a self-signed cert (can only be self-signed because as mentioned it's running inside a Tailscale network and is therefore not reachable from the outside). Since switching to that self-signed certificate I can't playback videos or live photos on mobile. I can however play them back on web.

[mmanjos]

I'm seeing the same thing on my environment:

• Immich v1.92.0 on docker
• nginx on the same node that runs the docker container
• SSL certificate used by nginx (server.crt and server.key below) is a valid certificate from my own self-hosted CA. The CA root is imported onto the android phone and other services respect the certificates that are signed by it without errors.

nginx is configured like this:

server {
  listen      443 ssl;
  server_name photos.my.domain.invalid;
  root /var/www/html;
  index index.html index.htm;
  client_max_body_size 5000M;

  ssl_certificate       /etc/ssl/private/server.crt; # this is a cert signed by my home root CA that validates server_name above
  ssl_certificate_key   /etc/ssl/private/server.key;

  location / {
    client_max_body_size 5000M;
    proxy_pass http://localhost:2283; # this is immich running on docker 0.0.0.0:2283->3001/tcp
    proxy_set_header Host              $http_host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_http_version 1.1;
    proxy_set_header   Upgrade    $http_upgrade;
    proxy_set_header   Connection "upgrade";
    proxy_redirect off;
  }
}

I've tried a handful of different reverse proxy configs, but based on the nginx logs and the behavior of the app, it feels like it's failing at the TLS session whenever a video is requested for playback on the phone (i.e. no actual HTTP request makes it into the nginx logs - it just fails silently)

[jrasm91]

AFAIK the image and video players in flutter don't use the http interceptor that has been added to solve the issue with self-signed certificates elsewhere.

[robertoho]

I also have a selfsigned certificate, the problem happens in the immich app and Chromium based browsers, in Firefox it works well.

[zamansoum]

Here to confirm i have the same issue with the updated version of the app on android with a valid cert and CA added to the android local store

[TheStealthReporter]

Also confirming this issue. Video clips in Immich show this behavior:

• works: Immich App + http:// endpoint
• works: Chrome Mobile + https:// with a self-signed CA (added to the user CA store)
• doesn't work: Immich App + https:// with exactly the same certificate as above

Also this user provides some code to check whether a certificate is really a trusted user certificate (instead of allowing all certificates, as far as I understand the Immich HTTP interceptor).

[rovo89]

Probably related: I use a reverse proxy with a Let's Encrypt certificate, which works without adding it to the CA store. However, due to the lack of mTLS support, I have configured Basic Authentication, i.e. my endpoint is https://user:password@mydomain.tld.

The error reported in the app logs is Exception: PlatformException(VideoError, Video player had error y2.r: Source error, null, null) and in the nginx logs I see that the requests coming from ExoPlayer got a 401. I assume that the username/password simply isn't included in the URL passed to the player, or that it doesn't know how to handle it. Can someone confirm?

[notthedan]

Confirming this issue for iPhone 14 Pro as well.

Using HAProxy loaded with a self-signed certificate to reverse proxy immich.

[MadKillerChicken]

Can also confirm. Strangely enough it works with Librewolf (Firefox), but doesn't with Vanadium (Chrome) or the Android app. Using latest client/server running on docker and using traefik (forced SSL). Own custom CA installed and recognized on all devices.

I'd love to know why it works on Firefox.

[pedropombeiro]

FWIW, I'm seeing the same on iOS (using mTLS support in Traefik with the new support in mobile app v1.111.0). Here's the output in Traefik's logs:

We can see that the TLSClientSubject header is present in successful requests:

[cfelicio]

Same issue here, I'm using an Iphone 11 app, tried with NPM and Caddy as Reverse proxies, also with cloudflare enabled and disabled...

here is what shows up on the Caddy log if it helps:

ERR | ts=1723696824.1158197 logger=http.handlers.reverse_proxy msg=aborting with incomplete response upstream=127.0.0.1:2283 duration=0.011252365 request={"remote_ip":"...","remote_port":"57094","client_ip":"...","proto":"HTTP/2.0","method":"GET","host":"...","uri":"/api/assets/ae6e9199-a7ac-47e1-b808-b0fbdc61ff02/video/playback","headers":{"Range":["bytes=0-362376870"],"User-Agent":["AppleCoreMedia/1.0.0.21G93 (iPhone; U; CPU OS 17_6_1 like Mac OS X; en_ca)"],"Cf-Ipcountry":["CA"],"X-Forwarded-Proto":["https"],"Accept-Language":["en-CA,en-US;q=0.9,en;q=0.8"],"X-Forwarded-For":["..."],"Accept-Encoding":["gzip, br"],"X-Playback-Session-Id":["9579D20C-5C14-4440-AD61-95682562C7F8"],"X-Forwarded-Host":["..."],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Cf-Ray":["8b36819c98cdc493-SEA"],"Accept":["/"],"X-Immich-User-Token":["..."],"Cf-Connecting-Ip":["..."],"Cdn-Loop":["cloudflare"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"..."}} error=writing: http2: stream closed

[M4tT3d]

I have the same problem with the new version as well. I use traefik as reverse proxy and the immich server can be accessed only from the local network. I also use a self-signed certificate for https with a permanent redirect from the http to https. I don't use clients certificates. The strange behavior is that if I access the server without the proxy, it work fine otherwise I have this error Instance of 'FlutterErrorDetails' Exception: PlatformException(VideoError, Video player had error f1.l: Source error, null, null) Library: widgets library Context: Instance of 'ErrorDescription'.

From the traefik logs I found out this kind of message when I want to get a video http: TLS handshake error from x.x.x.x:y: remote error: tls: bad certificate

[C-Otto]

I had the issue with a "let's encrypt" certificate and http basic auth. It works if I exclude the video endpoint from the auth requirements (which might be unsafe?). For Apache:

SetEnvIf Request_URI "/api/assets/[0-9a-f-]*/video/playback" accessgranted=1

<Location />
    Order deny,allow
    Satisfy any
    Deny from all
    Allow from env=accessgranted
    Authtype Basic
    Authname "Password Required"
    AuthBasicProvider file
    AuthUserFile "/foo/some.passwd"
    Require valid-user
</Location>

[neothematrix]

same issue with Android Immich app and mTLS client certificate on Cloudflare, video playback doesn't work, all requests are reaching cloudflare with "Exoplayer" user agent but without client ssl certificate, so they are dropped by Cloudflare. It seems ssl client certificate isn't passed to Exoplayer.

[neothematrix]

testing iOS too, same issue with Client mTLS authentication as Android, except the user agent is not "Exoplayer" but "AppleCoreMedia", GET request reach the immich endpoint without presenting the configured mTLS.

reading the other reports it seems there are two issues with video playback and SSL that are strictly related and perhaps the root cause could be the same: SSL parameters (like allow self-signed certificates and use ssl client certificates) are not passed over to external applications (like Exoplayer or AppleCoreMedia) that are used to playback videos.

[JPBRM]

Because @yjiang-c had a look at this issue while looking at a different Client SSL issue, I'm just adding this here for completeness: https://github.com/immich-app/immich/issues/11870#issuecomment-2323272620

@neothematrix #5553 is not easy to be resolved. The video player used in immich mobile is a flutter plugin, which does not support customised HTTPS options. In immich side, we can only fix it by totally replacing the video player and rewrite a new video player from scratch.

[neothematrix]

shall we open a bug/feat request to flutter? We surely aren't the only ones using these scenarios

[MadKillerChicken]

I really hope this can be solved. Immich is definitely the best self hosted solution of this kind by a long shot. Unfortunately this will prevent me from using it.

Sadly it appears that flutter has exactly this issue on their radar since 2019, but don't seem to be interested in implementing a fix.

https://github.com/flutter/flutter/issues/36925

[JPBRM]

I also found this issue: https://github.com/flutter/flutter/issues/56607 there is a reply from another dev who create a (android specific) plugin to get mTLS to work: https://github.com/flutter/flutter/issues/56607#issuecomment-2164062582

[alextran1502]

We are testing the native video player with might potentially can solve this issue

[TheOneValen]

As a "workaround": you can use letsencrypt for a domain which is only reachable via VPN if you use the DNS challenge. Then you have an "officially trusted" certificate. This is how I solved this for now.

[rovo89]

As a "workaround": you can use letsencrypt for a domain which is only reachable via VPN if you use the DNS challenge. Then you have an "officially trusted" certificate. This is how I solved this for now.

Won't help for mTLS though as the client certificate is simply not sent. And we can't disable mTLS requirement for videos because the requested URL isn't sent yet during the handshake.

[neothematrix]

currently a workaround is to use web browser instead of the app

[kaztechSolutions]

Are there any news about this issue? I am currently investigating if I can move from Google Photos to Immich. But this issue takes away all the joy I had.

I am just worried that mtls support could not be supported anymore. Would love the hear the opposite.

Having the issue using the iPhone app with an nginx proxy with mtls turned on.

[yjiang-c]

The Pull Request #12104 is in progress to resolve this issue. It is a big feature and needs some time.

[canton7]

For those, like me, searching open issues for this nginx error message:

SSL_do_handshake() failed (SSL: error:0A000416:SSL routines::ssl/tls alert certificate unknown:SSL alert number 46) while SSL handshaking, client: ::, server: [::]:443

[crisoagf]

Hey, I have a similar issue.

This change to the AndroidManifest fixes it if you have your server's certificate (or a root certificate you have used) in the User Certificate Store in Android:

diff --git a/mobile/android/app/src/main/AndroidManifest.xml b/mobile/android/app/src/main/AndroidManifest.xml
index 17c2830b4..9d7db316b 100644
--- a/mobile/android/app/src/main/AndroidManifest.xml
+++ b/mobile/android/app/src/main/AndroidManifest.xml
@@ -24,7 +24,9 @@

   <application android:label="Immich" android:name=".ImmichApp" android:usesCleartextTraffic="true"
     android:icon="@mipmap/ic_launcher" android:requestLegacyExternalStorage="true"
-    android:largeHeap="true" android:enableOnBackInvokedCallback="false">
+    android:largeHeap="true" android:enableOnBackInvokedCallback="false"
+    android:networkSecurityConfig="@xml/network_security_config"
+    >

     <service
       android:name="androidx.work.impl.foreground.SystemForegroundService"
@@ -81,6 +83,10 @@
       android:name="androidx.startup.InitializationProvider"
       android:authorities="${applicationId}.androidx-startup"
       tools:node="remove" />
+
+    <meta-data
+      android:name="io.flutter.network-policy"
+      android:resource="@xml/network_security_config" />
   </application>

diff --git a/mobile/android/app/src/main/res/xml/network_security_config.xml b/mobile/android/app/src/main/res/xml/network_security_config.xml
new file mode 100644
index 000000000..d20fb8331
--- /dev/null
+++ b/mobile/android/app/src/main/res/xml/network_security_config.xml
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="utf-8"?>
+<network-security-config>
+    <base-config>
+        <trust-anchors>
+            <certificates src="system" />
+            <certificates src="user" />
+        </trust-anchors>
+    </base-config>
+</network-security-config>

but I think it may trigger a Play Store warning.