starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 08:15:52 +03:00

[GH-ISSUE #740] [FEATURE REQUEST] Accept .pem input for CERT_FILE and KEY_FILE #270

New issue

Closed

opened 2026-02-27 08:16:15 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 08:16:15 +03:00

Owner

Originally created by @crealte on GitHub (Nov 18, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/740

Motivation
Certbot and other tools generate .pem file types but LLDAP expects .crt and .key file types.

Describe the solution you'd like
Accept .pem format for CERT_FILE and KEY_FILE

Describe alternatives you've considered
A simple renaming of the file type works but it is an additional step, especially when it comes to renewal.
cp privkey.pem privkey.key
cp fullchain.pem fullchain.crt

Additional context

Environment Variables:
- LLDAP_LDAPS_OPTIONS__ENABLED=true
- LLDAP_LDAPS_OPTIONS__CERT_FILE=/certs/fullchain.pem
- LLDAP_LDAPS_OPTIONS__KEY_FILE=/certs/privkey.pem

Error Logs:
Loading configuration from /data/lldap_config.toml
2023-11-18T22:58:52.896096119+00:00 INFO set_up_server [ 4.10ms | 100.00% ]
2023-11-18T22:58:52.896128426+00:00 INFO ┝━ ｉ [info]: Starting LLDAP version 0.5.1-alpha
2023-11-18T22:58:52.929989375+00:00 INFO ┕━ ｉ [info]: Starting the LDAP server on port 3890
2023-11-18T22:58:52.930173015+00:00 ERROR 🚨 [error]: Could not bring up the servers: while binding the LDAP server: while setting up the SSL certificate: No such file or directory (os error 2)
2023-11-18T22:58:52.930450496+00:00 INFO ｉ [info]: End.

Originally created by @crealte on GitHub (Nov 18, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/740 **Motivation** Certbot and other tools generate .pem file types but LLDAP expects .crt and .key file types. **Describe the solution you'd like** Accept .pem format for CERT_FILE and KEY_FILE **Describe alternatives you've considered** A simple renaming of the file type works but it is an additional step, especially when it comes to renewal. cp privkey.pem privkey.key cp fullchain.pem fullchain.crt **Additional context** Environment Variables: - LLDAP_LDAPS_OPTIONS__ENABLED=true - LLDAP_LDAPS_OPTIONS__CERT_FILE=/certs/fullchain.pem - LLDAP_LDAPS_OPTIONS__KEY_FILE=/certs/privkey.pem Error Logs: Loading configuration from /data/lldap_config.toml 2023-11-18T22:58:52.896096119+00:00 INFO set_up_server [ 4.10ms | 100.00% ] 2023-11-18T22:58:52.896128426+00:00 INFO ┝━ ｉ [info]: Starting LLDAP version 0.5.1-alpha 2023-11-18T22:58:52.929989375+00:00 INFO ┕━ ｉ [info]: Starting the LDAP server on port 3890 2023-11-18T22:58:52.930173015+00:00 ERROR 🚨 [error]: Could not bring up the servers: while binding the LDAP server: while setting up the SSL certificate: No such file or directory (os error 2) 2023-11-18T22:58:52.930450496+00:00 INFO ｉ [info]: End.

kerem

2026-02-27 08:16:15 +03:00

closed this issue
added the
invalid

question
labels

kerem commented

2026-02-27 08:16:16 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 22, 2024):

Sorry, I'm just now having another look at the bug: there's nothing that cares about the file extension, it's not about .pem or .key or .crt. In both cases, I open the file myself and just pass the bytes to a function that extracts the key. I don't understand how copying can solve the issue.

Are you sure it's not a misconfiguration and you didn't mount the correct files into the container? In particular, I would expect a very different error message if it was an unsupported format.

@nitnelave commented on GitHub (Jan 22, 2024): Sorry, I'm just now having another look at the bug: there's nothing that cares about the file extension, it's not about .pem or .key or .crt. In both cases, I open the file myself and just pass the bytes to a function that extracts the key. I don't understand how copying can solve the issue. Are you sure it's not a misconfiguration and you didn't mount the correct files into the container? In particular, I would expect a very different error message if it was an unsupported format.

kerem commented

2026-02-27 08:16:16 +03:00

Author

Owner

@crealte commented on GitHub (Mar 20, 2024):

Apologies for the late reply but indeed what I posted in my original post is indeed what I am still observing. I tried it again and renamed the file to privkey.pem and fullchain.pem and the container fails with the same error. I rename to .key and .crt and it works again. Permissions are unchanged.

@crealte commented on GitHub (Mar 20, 2024): Apologies for the late reply but indeed what I posted in my original post is indeed what I am still observing. I tried it again and renamed the file to privkey.pem and fullchain.pem and the container fails with the same error. I rename to .key and .crt and it works again. Permissions are unchanged.

kerem commented

2026-02-27 08:16:16 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 20, 2024):

How do you configure it? How do you set the environment variables, or the values in the config file?

@nitnelave commented on GitHub (Mar 20, 2024): How do you configure it? How do you set the environment variables, or the values in the config file?

kerem commented

2026-02-27 08:16:16 +03:00

Author

Owner

@crealte commented on GitHub (Mar 22, 2024):

Full environment variables and volume mounts below. For testing permissions were set to 777.

---
version: '3.8'
services:
  lldap:
    image: nitnelave/lldap
    environment:
      - LLDAP_JWT_SECRET_FILE=redacted
      - LLDAP_LDAP_USER_PASS_FILE=redacted
      - LLDAP_LDAP_BASE_DN=redacted
      - LLDAP_DATABASE_URL_FILE=redacted
      - LLDAP_LDAPS_OPTIONS__ENABLED=true
      - LLDAP_LDAPS_OPTIONS__CERT_FILE=/certs/fullchain.pem
      - LLDAP_LDAPS_OPTIONS__KEY_FILE=/certs/privkey.pem
      - LLDAP_SMTP_OPTIONS__ENABLE_PASSWORD_RESET=true
      - LLDAP_SMTP_OPTIONS__SERVER=redacted
      - LLDAP_SMTP_OPTIONS__PORT=587
      - LLDAP_SMTP_OPTIONS__SMTP_ENCRYPTION=NONE
      - LLDAP_SMTP_OPTIONS__FROM=redacted
      - LLDAP_SMTP_OPTIONS__REPLY_TO=redacted
    volumes:
      - /lldap/data:/data
      - /lldap/certbot/data/live/redacted:/certs

@crealte commented on GitHub (Mar 22, 2024): Full environment variables and volume mounts below. For testing permissions were set to 777. ``` --- version: '3.8' services: lldap: image: nitnelave/lldap environment: - LLDAP_JWT_SECRET_FILE=redacted - LLDAP_LDAP_USER_PASS_FILE=redacted - LLDAP_LDAP_BASE_DN=redacted - LLDAP_DATABASE_URL_FILE=redacted - LLDAP_LDAPS_OPTIONS__ENABLED=true - LLDAP_LDAPS_OPTIONS__CERT_FILE=/certs/fullchain.pem - LLDAP_LDAPS_OPTIONS__KEY_FILE=/certs/privkey.pem - LLDAP_SMTP_OPTIONS__ENABLE_PASSWORD_RESET=true - LLDAP_SMTP_OPTIONS__SERVER=redacted - LLDAP_SMTP_OPTIONS__PORT=587 - LLDAP_SMTP_OPTIONS__SMTP_ENCRYPTION=NONE - LLDAP_SMTP_OPTIONS__FROM=redacted - LLDAP_SMTP_OPTIONS__REPLY_TO=redacted volumes: - /lldap/data:/data - /lldap/certbot/data/live/redacted:/certs ```

kerem commented

2026-02-27 08:16:16 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 3, 2024):

See the key reading code here: github.com/lldap/lldap@6f905b1ca9/server/src/infra/ldap_server.rs (L107-L149)

Most importantly, all the functions trying to read a key are called with &mut BufReader::new(File::open(&ldaps_options.cert_file)?) as an argument: they don't receive the file name, just the contents. As such, they cannot be filename-sensitive. I would encourage you to double-check your settings.

Regarding your initial error, the "No such file or directory" is from File::open, and it means that the file doesn't exist (or cannot be read, maybe?) Make sure the file exists, is mounted in the correct folder, go inside the container to check that the path that you give in the env variable exists. You can also check the verbose logs to see the config values that were actually read by LLDAP, and make sure that the path is the one you expect.

@nitnelave commented on GitHub (Apr 3, 2024): See the key reading code here: https://github.com/lldap/lldap/blob/6f905b1ca9cbf15a460510fe5ba5eba159cf9f90/server/src/infra/ldap_server.rs#L107-L149 Most importantly, all the functions trying to read a key are called with `&mut BufReader::new(File::open(&ldaps_options.cert_file)?)` as an argument: they don't receive the file name, just the contents. As such, they _cannot_ be filename-sensitive. I would encourage you to double-check your settings. Regarding your initial error, the "No such file or directory" is from `File::open`, and it means that the file doesn't exist (or cannot be read, maybe?) Make sure the file exists, is mounted in the correct folder, go inside the container to check that the path that you give in the env variable exists. You can also check the verbose logs to see the config values that were actually read by LLDAP, and make sure that the path is the one you expect.

kerem referenced this issue

2026-02-27 08:18:21 +03:00

[PR #278] [MERGED] Misc small fixes. #657