docker-openldap: cannot make a secure connection: TLS: can't accept: The TLS connection was non-properly terminated..

So I wanted to drop a line here to follow-up on this persistent issue. The problem with client authentication with self-signed TLS certs seems to be a common problem mentioned on a number of open tickets. Assuming a docker installation LDAP_TLS_VERIFY_CLIENT=demand is default value when this environmental variable isn’t included. Changing on the LDAP server the value of LDAP_TLS_VERIFY_CLIENT=demand to LDAP_TLS_VERIFY_CLIENT=try bypasses client authentication with a malformed client TLS certificate. These variable names might be slightly different with a K8 installation, however the general concept still applies.

I posted my solution for the creation of client/server/CA self-signed certs that allows for TLS authentication with server and client authentication. I’ve posted the solution here: https://ubuntuforums.org/showthread.php?t=2451653&p=13992175#post13992175. After generating the certificates, LDAP_TLS_VERIFY_CLIENT=demand should work.

Here is a snippet of my docker-compose.yml file for openldap and phpldapadmin:

  openldap:
    image: osixia/openldap:latest
    container_name: openldap
    restart: always
    domainname: openldap.domain.com
    networks:
      - net
    ports:
      - "389:389"
      - "636:636"
    secrets:
      - authentication_backend-ldap_secret
    environment:
      - LDAP_LOG_LEVEL=256
      - LDAP_ORGANISATION=gohilton
      - LDAP_DOMAIN=ldap.gohilton.com
      - LDAP_BASE_DN=dc=ldap,dc=gohilton,dc=com
      - LDAP_ADMIN_PASSWORD_FILE=/run/secrets/authentication_backend-ldap_secret
      - LDAP_TLS=true
      - LDAP_TLS_CRT_FILENAME=cert.pem
      - LDAP_TLS_KEY_FILENAME=key.pem
      - LDAP_TLS_CA_CRT_FILENAME=ca.pem
      - LDAP_TLS_ENFORCE=false
      #- LDAP_TLS_VERIFY_CLIENT=try
      - LDAP_TLS_VERIFY_CLIENT=demand
      - LDAP_REPLICATION=false
      - KEEP_EXISTING_CONFIG=false
      - LDAP_REMOVE_CONFIG_AFTER_SETUP=false
      - LDAP_SSL_HELPER_PREFIX=ldap
    tty: true
    command: --loglevel debug
    stdin_open: true
    volumes:
      - /var/data/ldap/db:/var/lib/ldap
      - /etc/ldap/config:/etc/ldap/slapd.d
      - /etc/docker/compose/authelia/certs/openldap3/server:/container/service/slapd/assets/certs

  phpldapadmin:
    image: osixia/phpldapadmin:latest
    container_name: phpldapadmin
    restart: unless-stopped
    hostname: phpldapadmin.domain.org
    networks:
      - net
    ports:
      - 6443:80
    depends_on:
      - openldap
    environment:
      PHPLDAPADMIN_LDAP_HOSTS: "openldap"
      PHPLDAPADMIN_HTTPS: "false"
      PHPLDAPADMIN_LDAP_CLIENT_TLS: "true"
      PHPLDAPADMIN_LDAP_CLIENT_TLS_REQCERT: "demand"
      PHPLDAPADMIN_LDAP_CLIENT_TLS_CA_CRT_FILENAME: "ca.pem"
      PHPLDAPADMIN_LDAP_CLIENT_TLS_CRT_FILENAME: "cert.pem"
      PHPLDAPADMIN_LDAP_CLIENT_TLS_KEY_FILENAME: "key.pem"
    command: --loglevel debug
    volumes:
      - /etc/docker/compose/authelia/certs/openldap3/client:/container/service/ldap-client/assets/certs

I am also facing this issue. Here is another report on serverfault.

ldapsearch from within the container works:

ldapsearch -x -H ldaps://DOMAIN [...]

but fails from outside.

I’ve tried setting LDAP_TLS_VERIFY_CLIENT to one of “never”, “try” or “allow” but nothing worked.

TLS: can't accept: The TLS connection was non-properly terminated..
5feda1a0 conn=1008 fd=13 closed (TLS negotiation failure)

Glad you were able to find a resolution. I would have never guessed the solution too your problem. Glad you were able to figure it out

On Sat, Sep 16, 2023 at 12:04 AM Zexin Yuan @.***> wrote:

@yzx9 https://github.com/yzx9

I remember all too well dealing with this TLS problem. Just very picky and things tend to break. Just need some more information. Can you post the section of your docker-compose file dealing with the openldap section? Are your SSL certificates self signed? You need not only a certificate, but a key and at CA certificate as well.

@kevdogg https://github.com/kevdogg Thank you so much for your help. your solutions in 2020 are very inspiring to me and I finally discovered the problem.

It was not a problem related to this image, but was caused by my domain name not being registered (yes, all domain names in China need to be registered, otherwise the server provider will block your TLS client hello. I originally thought it would only block the https protocol)

If anyone encounters the same problem, please first try running the following command on the server (or even within the image):

openssl s_client -connect your_domain:636 -showcerts -state

If you have deployed successfully, you should see the tls connection established successfully, otherwise you should check your tls certs first. Then, you can try to connect your server by IP (not domain) from your client:

openssl s_client -connect your_server_ip:636 -showcerts -state

If the firewall is not blocking it, the connection should also be established successfully. Finally, you can try to connect by domain from your client, and if your message is blocked, you will see that client hello fails to be sent, as shown below:

CONNECTED(00000003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write:errno=104

no peer certificate available

No client certificate CA names sent

SSL handshake has read 0 bytes and written 310 bytes Verification: OK

New, (NONE), Cipher is (NONE) This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)

— Reply to this email directly, view it on GitHub https://github.com/osixia/docker-openldap/issues/330#issuecomment-1722136664, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABH75V7W26ZHY4I3GLLFUZTX2UXO5ANCNFSM4H32HTFQ . You are receiving this because you were mentioned.Message ID: @.***>

I can’t remember anymore but atm I don’t see the message anymore. Maybe also bc the bitnami image is now in use.

FWIW we have set this in our config (totally unclear if that is related to this though)

env:
  LDAP_TLS_CA_FILE: "/opt/bitnami/openldap/certs/tls.crt"