Monday, March 14, 2022

[389-users] Re: docker, 389ds/dirsrv:2.0, vendorVersion 2.1.0, ssca, certificate chain, orphan key, cert9.db, key4.db

> On 15 Mar 2022, at 02:49, Lutz Berger <lutz.berger@multigrid.de> 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@XXXXXXX.de
> 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@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

No comments:

Post a Comment