Error while reading file ca.crt

[evroon]

When I simply run:

docker run -it osixia/openldap:1.5.0 bash --loglevel debug

I get the following error almost at the end of the startup:

TLS: could not use CA certificate file `/container/service/slapd/assets/certs/ca.crt': Error while reading file. (-64)

This was using Ubuntu 20.04, but I also tested it on two other systems with the same OS, where it does work as expected. I get the same error when I try to use a custom ca.crt, but also that does work on the other two systems.

Is there a solution for this?

[obourdon]

@evroon may be this has nothing to do with your issue and it is potentially a typo you did doing copy paste to create this issue but I am definitely puzzled by the bash argument which (from my perspective) should not be there (5th in the docker command above)

Furthermore, I have a hard time understanding what you meant by other systems with same OS. Does this mean that you have 3 Ubuntu 20.04 systems where 1 is failing and the other 2 are working ?

If you're ca.crt doe not work may be you could see if https://github.com/osixia/docker-openldap/blob/master/test/test.bats#L140 does. HTH

[evroon]

Thanks for the reply.

@evroon may be this has nothing to do with your issue and it is potentially a typo you did doing copy paste to create this issue but I am definitely puzzled by the bash argument which (from my perspective) should not be there (5th in the docker command above)

The bash argument specifies the command I want to run inside the container (after the entrypoint has been executed). It is specfied here:

docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]

But running docker run osixia/openldap:1.5.0 gives the same output. (Actually, the bash command is never executed anyway, because the entrypoint (the startup of slapd) fails.)

Furthermore, I have a hard time understanding what you meant by other systems with same OS. Does this mean that you have 3 Ubuntu 20.04 systems where 1 is failing and the other 2 are working ?

Yes exactly, the only differences that are noteworthy AFAIK between the different setups, is that the failing system is a server that also runs its own LDAP server on the host (without using docker) and it also uses NFS, which gives some problems for users with a home dir mounted by NFS, but I use a local user for testing this docker container.

Also, I use Docker rootless, but I doubt that has an effect on this issue. I tested the permissions of ca.cert and I can perfectly read it as the openldap user inside the container. Btw, if I disable TLS, slapd does start, so the only problem I have is with ca.crt.

I will test the test.bats command later today.

[obourdon]

@evroon thanks for your explanations. I did not know about this and I find it a bit awkward to understand that args seem to go to the entrypoint and bash is indeed executed. As a 'long time UNIX aficionado" I always interpret arguments and commands in sequence ;-)

On my side, testing this showed that it first seems to not be called but hitting return then showed me the bash prompt. Very weird indeed.

I think I remember some weird behaviour like yours if I do not use the proper options for filesystems on MacOSX (:Z) but I do not think it happens here. I am pretty sure you also considered port conflicts and the like (sometimes the issued error message might be quite far from the original issue) as you mention that another native LDAP server is running on the same host.

[evroon]

@evroon thanks for your explanations. I did not know about this and I find it a bit awkward to understand that args seem to go to the entrypoint and bash is indeed executed. As a 'long time UNIX aficionado" I always interpret arguments and commands in sequence ;-)

Yes I can relate, I found it strange at first as well.

On my side, testing this showed that it first seems to not be called but hitting return then showed me the bash prompt. Very weird indeed.

Yup, the same thing happens for me.

Unfortunately, I get the same error if I try the test command you mentioned with the test certificate.

I found two related questions about the problem:

• https://serverfault.com/questions/805943/tls-error-while-reading-file
• https://gitlab.nic.cz/knot/knot-resolver/-/issues/505

But they don't help much. I don't think it is because of something like port conflicts, because the message is specifically raised when it can literally not read the file for some reason. The error is raised here and I looked into the source of TLS and there it is raised when a read_file function returns null.

But I guess this is not directly related to this repo, but an issue with OpenLDAP itself.

[jrebmann]

I have exactly the same problem.

I am using minikube to host a local Kubernetes cluster.

However, the problem seems to have nothing to do with Kubernetes. If I just run the container (docker run osixia/openldap:1.5.0 --loglevel debug) on my host, it works fine. But when I run the same command in minikube, the described error occurs:

$> docker run osixia/openldap:1.5.0 --loglevel debug
[...]
2022/09/15 08:31:55 [INFO] signed certificate with serial number 704119011836004649258614269362592380762534600926
***  DEBUG  | 2022-09-15 08:31:55 | move /tmp/cert.pem to /container/service/slapd/assets/certs/ldap.crt
***  DEBUG  | 2022-09-15 08:31:55 | move /tmp/cert-key.pem to /container/service/slapd/assets/certs/ldap.key
***  INFO   | 2022-09-15 08:31:55 | Link /container/service/:ssl-tools/assets/default-ca/default-ca.pem to /container/service/slapd/assets/certs/ca.crt
***  DEBUG  | 2022-09-15 08:31:55 | done :)
6322e2fb conn=1014 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi)
6322e2fb conn=1014 op=0 BIND dn="" method=163
6322e2fb conn=1014 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
6322e2fb conn=1014 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71
6322e2fb conn=1014 op=0 RESULT tag=97 err=0 text=
6322e2fb conn=1014 op=1 MOD dn="cn=config"
6322e2fb conn=1014 op=1 MOD attr=olcTLSCipherSuite olcTLSCACertificateFile olcTLSCertificateFile olcTLSCertificateKeyFile olcTLSDHParamFile olcTLSVerifyClient
TLS: could not use CA certificate file `/container/service/slapd/assets/certs/ca.crt': Error while reading file. (-64)
6322e2fb conn=1014 op=1 RESULT tag=103 err=80 text=
6322e2fb conn=1014 op=2 UNBIND
6322e2fb conn=1014 fd=12 closed
***  DEBUG  | 2022-09-15 08:31:55 | ldap_modify: Other (e.g., implementation specific) error (80)

Since we are talking about isolated containers here. What exactly could be the problem that within minikube the error occurs while it works on the host?

According to my research, the error most likely comes from a permission problem, but since I don't have any volumes mounted, the permission problem must occur in the container.

I would be very grateful for help!

[evroon]

@CuddlySheep I haven't looked at this anymore since years, but someone posted this a few weeks ago: https://github.com/osixia/docker-openldap/issues/349#issuecomment-1221158590. Maybe that helps

I agree though that it has to be a permission problem and that it should be solvable without workarounds etc

[jrebmann]

@evroon Thank you very much for your answer.

Unfortunately, @BoW2EviL's approach leads to exactly the same error.

Copy from internal path /certs/ldap.crt to /container/run/service/slapd/assets/certs/cert.pem
Copy from internal path /certs/ldap.key to /container/run/service/slapd/assets/certs/privkey.pem
Copy from internal path /certs/ca.crt to /container/run/service/slapd/assets/certs/fullchain.pem
Copy from internal path /certs/dhparam.pem to /container/run/service/slapd/assets/certs/dhparam.pem
***  INFO   | 2022-09-20 08:01:22 | Start OpenLDAP...
***  INFO   | 2022-09-20 08:01:22 | Waiting for OpenLDAP to start...
63297352 @(#) $OpenLDAP: slapd 2.4.57+dfsg-1~bpo10+1 (Jan 30 2021 06:59:51) $
        Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
63297352 slapd starting
***  INFO   | 2022-09-20 08:01:22 | Add TLS config...
***  DEBUG  | 2022-09-20 08:01:22 | Hi! I'm ssl-helper, what button should i press ?
***  DEBUG  | 2022-09-20 08:01:22 | cfssl-helper is launched, everybody on the floor!
***  DEBUG  | 2022-09-20 08:01:22 | Files /container/run/service/slapd/assets/certs/cert.pem and /container/run/service/slapd/assets/certs/privkey.pem exists, fix files permissions
63297352 conn=1000 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi)
63297352 conn=1000 op=0 BIND dn="" method=163
63297352 conn=1000 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
63297352 conn=1000 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71
63297352 conn=1000 op=0 RESULT tag=97 err=0 text=
63297352 conn=1000 op=1 MOD dn="cn=config"
63297352 conn=1000 op=1 MOD attr=olcTLSCipherSuite olcTLSCACertificateFile olcTLSCertificateFile olcTLSCertificateKeyFile olcTLSDHParamFile olcTLSVerifyClient
TLS: could not use CA certificate file `/container/run/service/slapd/assets/certs/fullchain.pem': Error while reading file. (-64)
63297352 conn=1000 op=1 RESULT tag=103 err=80 text=
63297352 conn=1000 op=2 UNBIND
63297352 conn=1000 fd=12 closed
***  DEBUG  | 2022-09-20 08:01:22 | ldap_modify: Other (e.g., implementation specific) error (80)
modifying entry "cn=config"
***  ERROR  | 2022-09-20 08:01:22 | /container/run/startup/slapd failed with status 80

According to the log messages at the beginning of the output, the file /container/run/service/slapd/assets/certs/fullchain.pem definitely exists.

Are there different ways to configure volume mounts on a machine? That's the only reason I can think of why it works on one machine and not another.

[BoW2EviL]

@CuddlySheep. I ended up just building the dockerfile with the certs in it. seems to work very well. stopped all the errors. just rebuild and deploy when certs expire. my eairly method seemed to work but when i updated the certs everything went to $*@&.