Trust Self Signed Certificates with Immich - OAuth Setup

[seifer44]

I was setting up Authentik to function as an OAuth2/OpenID provider for Immich, but ran into a problem where I'd get the following, somewhat vague error.

[Nest] 17  - 05/25/2025, 11:32:53 AM   ERROR [Api:OAuthRepository~sgxduz9o] Error in OAuth discovery: TypeError: fetch failed
[Nest] 17  - 05/25/2025, 11:32:53 AM   ERROR [Api:OAuthRepository~sgxduz9o] TypeError: fetch failed
    at node:internal/deps/undici/undici:13502:13
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async performDiscovery (file:///usr/src/app/node_modules/openid-client/build/index.js:266:16)
    at async discovery (file:///usr/src/app/node_modules/openid-client/build/index.js:243:16)
    at async OAuthRepository.getClient (/usr/src/app/dist/repositories/oauth.repository.js:85:20)
    at async OAuthRepository.authorize (/usr/src/app/dist/repositories/oauth.repository.js:25:24)
    at async AuthService.authorize (/usr/src/app/dist/services/auth.service.js:165:16)
    at async OAuthController.startOAuth (/usr/src/app/dist/controllers/oauth.controller.js:36:46)

This is despite the fact that I could curl my Authentik server just fine at the ISSUER_URL endpoint I have saved in Immich. However, if I pointed at the HTTP endpoint for Authentik instead, OAuth worked just fine.

Turns out that Immich was having issues with the self-signed CA I used to issue the HTTPS cert for Authentik, which is using a reverse proxy I set up with NGINX. It would work at the HTTP endpoint, because I'd point directly to port 9000, which is what the Authentik container exposes by default.

Fortunately, this is a relatively easy fix for Immich!

1. On your system running Immich in Docker, place your self-signed CA into a folder that has read permissions for your Immich container. In my case, the CA file is located in the directory /etc/pki/ca-trust/source/anchors/
   a. man page for update-ca-trust.
2. Edit your docker-compose.yml file, and for the immich-server service, and add a mount to the /certs directory. In my case, I point directly to where my custom CA files are at on my Enterprise Linux distribution (my case Rocky Linux). Don't add the Z flag if you don't have SELinux on your system.

volumes:
  /etc/pki/ca-trust/source/anchors/:/certs:roZ

4. Add an environment block and point to the specific CA file that issued your OAuth server's HTTPS cert.

    environment:
      NODE_EXTRA_CA_CERTS: /certs/CAFILENAME.pem

5. Run docker compose down && docker compose up -d, and try logging in via OAuth again. Fixed!

Here's the full reference for the immich-server service:

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
      - /etc/pki/ca-trust/source/anchors/:/certs:roZ
    env_file:
      - .env
    environment:
      NODE_EXTRA_CA_CERTS: /certs/CAFILENAME.pem
    ports:
      - '2283:2283'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

...

[zamu-flowerpot]

To get this to work correctly, I had to also configure a DNS for the immich_server service so that the oauth2 endpoint both the certificate and the immich service itself knew where to go to talk to the OAuth service.
This is only needed if your OAuth service is not publicly available and if your default DNS server for the docker host does not resolve your OAuth service (which can happen if you have multi-horizon DNS configurations).

services:
    immich-server:
        ...
        dns:
            - ${DNS_SERVER}
        ...

[seifer44]

Hey good catch! This hadn't crossed my mind, as I have internal, private DNS running in my network.

[PetitPrinc3]

Hi,

Thank you a lot for this, but despite doing precisely what you said, I'm still having the same error :

[Nest] 18  - 09/11/2025, 4:04:37 PM   ERROR [Api:OAuthRepository~z9a2dqei] Error in OAuth discovery: TypeError: fetch failed
[Nest] 18  - 09/11/2025, 4:04:37 PM   ERROR [Api:OAuthRepository~z9a2dqei] TypeError: fetch failed
    at node:internal/deps/undici/undici:13510:13
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async performDiscovery (file:///usr/src/app/server/node_modules/.pnpm/openid-client@6.6.4/node_modules/openid-client/build/index.js:266:16)
    at async discovery (file:///usr/src/app/server/node_modules/.pnpm/openid-client@6.6.4/node_modules/openid-client/build/index.js:243:16)
    at async OAuthRepository.getClient (/usr/src/app/server/dist/repositories/oauth.repository.js:85:20)
    at async OAuthRepository.authorize (/usr/src/app/server/dist/repositories/oauth.repository.js:25:24)
    at async AuthService.authorize (/usr/src/app/server/dist/services/auth.service.js:169:16)
    at async OAuthController.startOAuth (/usr/src/app/server/dist/controllers/oauth.controller.js:36:46)

To provide you with some context, everything is running on a proxmox host with two interfaces (vmbr0 : 192.168.1.20/24 & vmbr1 : 10.10.10.254/24)

I have one domain controller VM (samba) at 10.10.10.1 and I have configured authelia (at 10.10.10.4:9091) to authenticate against the ldap. It works fine. I have enabled TLS using a trusted chain with the domain's CA certificate and authelia'CA certificate and key.

I have an NGINX Reverse Proxy Manager at 192.168.1.X and 10.10.10.253. I have forwarded the authelia and immich hosts and I can access the both of them. However, I can't get immich to work with authelia.

• I have set SSL up for authelia in NPM using the same certificates as before.
• I can reach authelia from the immich-server container :

root@photos:/immich-app# docker exec -i immich_server sh
node -e "require('https').get('https://auth.home.lan:9091', res => console.log(res.statusCode))"
200

I believe that the issue occurs because while my DC (which I set as the DNS in the docker-compose.yaml) resolves auth.home.lan at 10.10.10.4, NPM redirects auth.home.lan at 10.10.10.4:9091 directly.

However, I do not know how to fix this.

I can share both my Authelia and Immich configs if need be.

I don't know what to try next... Any chance you could help ?

Thanks !

[PetitPrinc3]

Alright, I found a way to fix it.

Instead of having a DNS_SERVER set inside the docker-compose.yml file, it needed a simple extra_host instead.

For anyone having the same issue, simply add the following config to your yaml :

services:
  immich-server:
    ...
    extra_hosts:
        - "<authelia_hostname>:<NGINX Proxy Manager listening IP>"
    ...

[seifer44]

Do you have internal DNS available to your 192.168.1.0/24(?) network and your 10.10.10.0/24? I'd also check that DHCP is distributing DNS as expected, and that your networks can access your private DNS server(s) on port 53.

Patching through extra_hosts is a lot easier of a fix though 😛

[gerryflux]

services:
  immich-server:
    ...
    extra_hosts:
        - "<authelia_hostname>:<NGINX Proxy Manager listening IP>"
    ...

This worked for me beautifully, thank you.
Does anyone know why exactly this is happening?
All my containers can reach DNS and reverse proxy servers just fine, only Immich acting up

[seifer44]

Do you have Immich logs saying it can't find some FQDN, or is it when you're trying to access your Immich server in a browser? Try looking at the DNS resolution for each device, and that may help.

If you're running a DNS server at home, then maybe the device above needs a different config.

[joachimtingvold]

I would argue that the proper fix here is to use the publicly exposed endpoint of Authentik as the OAuth URL in Immich. In OPs case, that would be the Authentik-URL exposed via nginx. This of course assumes that this endpoint is using a public cert (via nginx). It's quicker, and also more secure (as you don't have to trust any self-signed certs that you also have to renew).

[cmj01]

Getting the same problem with Authentik and NPMPlus.

I can curl the authentik https address fine from the server, but from within the immich container I get:

mike@ubuntu-5:/opt/immich$ sudo docker exec -it immich_server curl https://authentik-5sr.mydomain.net
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

I have tried to use various certificates:

• a sectigo wildcard
• letsencrpt

but still get the same result.

immich_server            | [Nest] 25  - 06/10/2026, 7:48:06 AM   ERROR [Api:OAuthRepository~nf6lfn44] TypeError: fetch failed
immich_server            | [Nest] 25  - 06/10/2026, 7:48:06 AM   DEBUG [Api:LoggingInterceptor~nf6lfn44] POST /api/oauth/authorize 201 19.97ms 10.1.20.6
immich_server            | [Nest] 25  - 06/10/2026, 7:48:06 AM   DEBUG [Api:GlobalExceptionFilter~nf6lfn44] HttpException(500): {"message":"Error in OAuth discovery: TypeError: fetch failed","statusCode":500}

Can anyone advise exactly which certificate I need? For Sectigo I have tried the full certificate bundle .crt and the wildcard crt.

For letsencrypt I have fullchain1.pem - but it expires and gets renewed every week so this doesn't seem like a good solution...

Why can't we have an option built into the gui to help with this, like the mobile app.

Any way to work out which certificate is missing?

Many thanks

M

[seifer44]

For LetsEncrypt, it sounds like you may be looking in etc/archive/domain.net/ for the most recent file. If you point to etc/live/domain.net/fullchain.pem, that's a symbolic link that LetsEncrypt updates for you.

Just add in a && systemctl reload nginx.service or && docker restart any-container-service at the end of your LetsEncrypt cron job, and you should be good to go

[dineiar]

I tried following the instructions, but I am still getting Error in OAuth discovery: TypeError: fetch failed (Immich Server Error) on Immich v2.7.5 v3.0.2 (edit: updated to v3, still same error):

[Nest] 29  - 07/13/2026, 7:11:09 PM   ERROR [Api:OAuthRepository~eq33wytr] Error in OAuth discovery: TypeError: fetch failed
[Nest] 29  - 07/13/2026, 7:11:09 PM   ERROR [Api:OAuthRepository~eq33wytr] TypeError: fetch failed
[Nest] 29  - 07/13/2026, 7:11:09 PM   DEBUG [Api:LoggingInterceptor~eq33wytr] POST /api/oauth/authorize 201 51.50ms 100.92.244.105
[Nest] 29  - 07/13/2026, 7:11:09 PM   DEBUG [Api:GlobalExceptionFilter~eq33wytr] HttpException(500): {"message":"Error in OAuth discovery: TypeError: fetch failed","statusCode":500}

The communication works if I switch the OAuth URL to HTTP (non-HTTPS). However, I want it to run over HTTPS (I am fine with the container-to-container communication to run via HTTP, but if I set the HTTP URL in the OAuth setting issuer_url in in Immich it also uses it to redirect the user when logging in, and I want the user->authentik connection to go over HTTPS).

I am using Authentik with a self-signed certificate: In the Authentik admin interface, I generated a new certificate pair (System > Certificates) with common name and alt name authentik.abc-def.ts.net, and configured it to be used as Web Certificate in System > Brands > Other global settings. I downloaded this certificate and stored it in /certs/authentik.abc-def.ts.net_certificate.pem in the Immich container.

Both Authentik and Immich are deployed as containers in the same host. Authentik is running on ports 9000 (HTTP) and 9443 (HTTPS), and binding the same ports in the host machine, and it is exposed via Tailscale at authentik.abc-def.ts.net (also both ports). Since the Immich container does not have the Tailscale client, I added an extra host to Immich container mapping the authentik Tailscale domain to the host machine (extra_hosts: - "authentik.abc-def.ts.net:host-gateway"). As mentioned, I also configured the NODE_EXTRA_CA_CERTS env variable as in docker compose:

services:
  immich-server:
    ...
    environment:
      NODE_EXTRA_CA_CERTS: /certs/authentik.abc-def.ts.net_certificate.pem
    extra_hosts:
      - "authentik.abc-def.ts.net:host-gateway"

Extra sanity checks

Inside the Immich container, I checked that the certificate in /certs is the same exposed by Authentik and seen by Immich:

# Install OpenSSL in Immich container
$ apt update && apt install -y openssl
# Download SSL certificate exposed by Authentik and saves in tmp folder
$ echo | openssl s_client -showcerts -connect authentik.abc-def.ts.net:9443 2>/dev/null | openssl x509 > /tmp/cert.pem
# Compares certificates
$ md5sum /tmp/cert.pem /certs/authentik.abc-def.ts.net_certificate.pem
c313ea8a6856c9f0987f42b9590ae579  /tmp/cert.pem
c313ea8a6856c9f0987f42b9590ae579  /certs/authentik.abc-def.ts.net_certificate.pem

Another sanity check that the certificate is working:

# Curl fails because it doesn't trust certificate
$ curl https://authentik.abc-def.ts.net:9443
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

# Adds the certificate from /certs to curl's trust store
$ cat /certs/authentik.abc-def.ts.net_certificate.pem >> /etc/ssl/certs/ca-certificates.crt
# Test curl again, now it succeeds
$ curl -v https://authentik.abc-def.ts.net:9443
* Host authentik.abc-def.ts.net:9443 was resolved.
...
*  subjectAltName: host "authentik.abc-def.ts.net" matched cert's "authentik.abc-def.ts.net"
*  issuer: CN=authentik 2026.5.3
*  SSL certificate verify ok.
...
< HTTP/1.1 302 Found
...

I did these tests to confirm the container is able to reach Authentik via the host mapping and received the correct certificate. However, I am still seeing the HTTP 500 error on Immich logs.

[dineiar]

Claude figured it out. Turns out using "Generate Certificate-Key Pair" button in Authentik actually does not generate a self-signed certificate as I assumed. It generates a leaf certificate signed by Authentik's own certificate.

The test with Curl led me to believe it was correct, but curl behaves differently than Node when validating SSL certificates: Curl uses OpenSSL, which accepts an exact match for the presented cert in the trust store (i.e., partial-chain trust), while Node tries to verify the signature chain and fails due to not finding Authentik's own certificate in the chain.

I ended up generating my own CA+leaf certificate, trusting the CA in Immich and importing the leaf certificate in Authentik. That solved the issue.