> On 15 Mar 2022, at 02:49, Lutz Berger <lutz.berger@xxxxxxxxxxxx> wrote: > > Hi there, > > I've a question regarding the docker image: > - vendorVersion: 389-Directory/2.1.0 B2022.015.0000 > > My scenario: > > - I want to install a customer's certificate chain and run the DS with LDAPS on port 3636 > > My steps to reproduce: > > - docker volume create 389ds > - cd /var/lib/docker/volumes/389ds/_data > - cp -r /root/389ds/tls . > - verify tls directory: > > [root@ur1 _data]# ls -lR tls > tls: > total 8 > drwxr-xr-x. 2 root root 64 Mar 14 16:56 ca > -rw-r--r--. 1 root root 1419 Mar 14 16:56 server.crt > -rw-r--r--. 1 root root 1675 Mar 14 16:56 server.key > > tls/ca: > total 8 > -rw-r--r--. 1 root root 2384 Mar 14 16:56 XXXXXXROOTCA2015.crt > -rw-r--r--. 1 root root 2032 Mar 14 16:56 XXXXXXServerCA2015.crt > [root@ur1 _data]# > > > Starting the docker container with "docker-compose up -d" generates > a fresh DS, but installs a self-signed CA and cert. > > docker-compose.yml > ldap: > image: 389ds/dirsrv:2.0 > container_name: ur1 > volumes: > - 389ds:/data > environment: > - DS_DM_PASSWORD=XXXXX > ports: > - 3389:3389 > - 3636:3636 > restart: always > > > > From inside the docker container I've found: > > [root@ur1 _data]# docker exec -i -t ur1 /bin/bash > 6b70de8c74e9:/ # cd /data > 6b70de8c74e9:/data # cd config > 6b70de8c74e9:/data/config # certutil -L -d . > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > Self-Signed-CA CT,, > /data/tls/ca/XXXXXXROOTCA2015.crt C,, > /data/tls/ca/XXXXXXServerCA2015.crt C,, > Server-Cert u,u,u > 6b70de8c74e9:/data/config # certutil -K -d . -f pwdfile.txt > certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" > < 0> rsa f6112f5e250e3b84034fa1272e43354d6715a3e5 (orphan) > < 1> rsa 6cc26b19c14150f6cb27aa3dee09795ed48cd8db Server-Cert > 6b70de8c74e9:/data/config # > > > Looks like the ssca directory and some self-signed CA and cert > get always installed, even if a complete CA chain and a server cert > is provided. > > openssl s_client -connect ur1.XXXXXXX.de:3636 > CONNECTED(00000003) > depth=2 C = DE, ST = XXXXXXXX, O = XXXXXXX, CN = XXXXXXX ROOT CA 2015, emailAddress = security@xxxxxxxxxx > verify error:num=19:self signed certificate in certificate chain > > An orphan key doesn't look nice, but I am more worried about the unnecessary > stuff in the databases So the orphan key is the "original" server-cert key that was orphaned since you loaded your own key. It's honestly harmless. Everything else appears to have imported correctly which is excellent! > and the failing openssl certificate validation. We'll need to see the output of 'openssl -_client -connect url1.XXXXXX.de:3636 -showcerts' to see what is or isn't self signed in the chain. It could just simply be that your ROOTCA/ServerCA aren't trusted by your openssl install of the host. -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
