Persistent SSL Certificate Verification Issues with LDAP Outpost

[aingestigate]

Hello Authentik Team,

I am experiencing persistent SSL certificate verification issues when configuring LDAP outposts in my Docker environment. Despite following the recommended practices for secure connections and proper DNS naming conventions, I continue to encounter the error: "tls: failed to verify certificate: x509: certificate signed by unknown authority".

Steps to Reproduce:

1.  Set up Authentik with Docker Compose using standard service names with hyphens (e.g., authentik-server).
2.  Configure LDAP outposts with SSL using self-signed certificates.
3.  Attempt to connect to authentik_server via the outpost, leading to SSL verification failures.

Expected Behavior: The LDAP outpost should establish a secure connection without SSL errors.

Actual Behavior: The connection repeatedly fails with SSL verification errors, even after ensuring the full certificate chain is trusted and correctly set up in the environment.

Environment:

•   Authentik version: 2024.4.2
•   Deployment method: Docker Compose
•   My Docker Compose file:

networks:
  web:
    external: true

services:
  postgresql-authentik:
    image: postgres:12-alpine3.19
    container_name: postgresql-authentik
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 5s
    volumes:
      - database:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_DB=${POSTGRES_DB}
    networks:
      - default  

  redis-authentik:
    image: redis:alpine3.19
    container_name: redis-authentik
    command: --save 60 1 --loglevel warning
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 3s
    volumes:
      - redis:/data
    networks:
      - default

  authentik-server:
    image: ghcr.io/goauthentik/server:2024.4.2
    container_name: authentik-server
    restart: unless-stopped
    command: server
    environment:
      - AUTHENTIK_REDIS__HOST=redis-authentik
      - AUTHENTIK_POSTGRESQL__HOST=postgresql-authentik
      - AUTHENTIK_POSTGRESQL__USER=${POSTGRES_USER}
      - AUTHENTIK_POSTGRESQL__NAME=${POSTGRES_DB}
      - AUTHENTIK_POSTGRESQL__PASSWORD=${POSTGRES_PASSWORD}
      - AUTHENTIK_ERROR_REPORTING__ENABLED=true
      - AUTHENTIK_SECRET_KEY=${AUTHENTIK_SECRET_KEY}
    volumes:
      - ./media:/media
      - ./custom-templates:/templates
      - ./certs:/certs
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.authentik.entrypoints=websecure"
      - "traefik.http.services.authentik.loadbalancer.server.scheme=http"
      - "traefik.http.routers.authentik.rule=Host(`sso.ingestigate.com`)"
      - "traefik.http.services.authentik.loadbalancer.server.port=9000"
      - "traefik.http.routers.authentik.service=authentik"
      - "traefik.http.routers.authentik.tls=true"
      - "traefik.http.routers.authentik.tls.certresolver=myresolver"
      - "traefik.docker.network=web"
    depends_on:
      - postgresql-authentik
      - redis-authentik
    ports: 
      - 9000:9000
      - 9443:9443
    networks:
      - web
      - default

  authentik-worker:
    image: ghcr.io/goauthentik/server:2024.4.2
    container_name: authentik-worker
    restart: unless-stopped
    command: worker
    environment:
      - AUTHENTIK_REDIS__HOST=redis-authentik
      - AUTHENTIK_POSTGRESQL__HOST=postgresql-authentik
      - AUTHENTIK_POSTGRESQL__USER=${POSTGRES_USER}
      - AUTHENTIK_POSTGRESQL__NAME=${POSTGRES_DB}
      - AUTHENTIK_POSTGRESQL__PASSWORD=${POSTGRES_PASSWORD}
      - AUTHENTIK_ERROR_REPORTING__ENABLED=true
      - AUTHENTIK_SECRET_KEY=${AUTHENTIK_SECRET_KEY}
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./media:/media
      - ./certs:/certs
      - ./custom-templates:/templates
    depends_on:
      - postgresql-authentik
      - redis-authentik
    networks:
      - default

  authentik-ldap:
    image: ghcr.io/goauthentik/ldap:2024.4.2
    container_name: authentik-ldap
    restart: unless-stopped
    environment:
      # - AUTHENTIK_HOST=http://authentik_server:9000
      - AUTHENTIK_HOST=https://authentik-server:9443
      - AUTHENTIK_INSECURE=false
      - AUTHENTIK_TOKEN=O0kmTPcTWWr3Nd4L7ugCYHhSR2NJNlJHZi7HTnfZ0o1jPNqovH27EY7QTsrn
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.authentik_ldap.entrypoints=websecure"
      - "traefik.http.services.authentik_ldap.loadbalancer.server.scheme=http"
      - "traefik.http.routers.authentik_ldap.rule=Host(`sso.ldap.ingestigate.com`)"
      - "traefik.http.services.authentik_ldap.loadbalancer.server.port=6636"
      - "traefik.http.routers.authentik_ldap.service=authentik_ldap"
      - "traefik.http.routers.authentik_ldap.tls=true"
      - "traefik.http.routers.authentik_ldap.tls.certresolver=myresolver"
    volumes:
    - ./certs:/certs
    depends_on:
      - postgresql-authentik
      - redis-authentik
      - authentik-server
      - authentik-worker
    ports: 
      - 389:3389
      - 636:6636
    networks:
      - default
      - web

volumes:
  database:
    driver: local
  redis:
    driver: local

Additional Context: I’ve tried various configurations, including changing service names to be DNS-compliant and explicitly trusting the self-signed certificate within the container’s trust store. A similar issue was discussed in Issue #7624, but no definitive resolution was documented. Additionally -- I have access to the UI of authentik, am able to create users, etc. I set up the various flows, stages, applications, providers, and outposts according to the documentation.

In the end, the authentik-ldap container is unable to connect, continually showing this error: {"error":"Get \"https://authentik-server:9443/api/v3/outposts/instances/\": tls: failed to verify certificate: x509: certificate signed by unknown authority","event":"Failed to fetch outpost configuration, retrying in 3 seconds","level":"error","logger":"authentik.outpost.ak-api-controller","timestamp":"2024-05-24T20:23:20Z"}

And tests within the authentik-worker container are failing, as follows:

root@7c360d3cc740:/# openssl s_client -connect authentik-server:9443 -CAfile /certs/authentik_server_certificate.pem
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 O = authentik, CN = authentik default certificate
verify error:num=18:self-signed certificate
verify return:1
depth=0 O = authentik, CN = authentik default certificate
verify return:1
---
Certificate chain
 0 s:O = authentik, CN = authentik default certificate
   i:O = authentik, CN = authentik default certificate
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May 24 20:10:23 2024 GMT; NotAfter: May 24 20:10:23 2025 GMT
---
Server certificate

I generated additional certificate key pairs within the UI of Authentik, and uploaded them to the bind-mounted /certs directory. I can see that they were "discovered" via the UI. Nonetheless, it appears that the server insists on using the "generic" self-signed cert that is auto-created, and even if I delete it and restart the stack, it generates a new one.

Could you please advise on potential steps to resolve this issue or confirm if this might be a bug in the current version?

Thank you for your assistance.

Feel free to customize this draft with more specific details about your configuration and any other observations you think are relevant. This should give the developers a clear understanding of the issue and the context needed to investigate further.

[aingestigate]

I would love to use your project, but when people indicate there is a bug or flaw in the software, it very often seems that no one responds, at all. Can I please get a response to the above?

[authentik-automation[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[StoffelCPR]

I'm now facing the same issue.. So I guess I'm pushing this.

To me it seems that outposts don't trust the Authentik instance if the authentik instance is using self-signed certs.. We'd need to know of a way to supply the certificate.

I'd also triage this as a Bug:

Authentik should deploy it's trusted certificates to outposts it deploys from the UI

[StoffelCPR]

@aingestigate I found this on the deployment info in the UI. There's an environment variable that allows setting it insecure

Nontheless I want the outpost to either recognize my self-signed root CA or at least disable not needed external ports