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

Hi William,

thanks for your help, please find my answers online!

Best regards,
  Lutz

 

On 15.03.22 00:36, William Brown wrote:

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!   

OK, agreed. It is harmless, but also not needed. Usually, I choose to use only one private key in my key3.db or key4.db.
My assumption was, that if I provide certificates in the tls subdirectory, the ssca directory is not even used at all,
since the key and cert that are effectively used are stored in the config directory and its databases.

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. 

Due to NDA I can't provide more details. But the problem is not related to self-signed-certs as indicated by
openssl's error messages, it's really that I didn't properly specify rootCA/ServerCA.

It works now with:

cat XXXXXXROOTCA2015.crt > ./chain.crt
cat XXXXXXServerCA2015.crt >> ./chain.crt
openssl s_client -connect ur1.sedevsso.XXXXXX.de:3636 -CAfile <path>/ca/chain.crt :

...
...
SSL handshake has read 4776 bytes and written 427 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 003BB677D15FC7C0490D3E795F193AB103D1E579D2F554086B63853DA9916525
    Session-ID-ctx:
    Master-Key: D050F13AD8343F825E4602F57BFFDB7BFBF38438E9ED497C9626F973C7772EC0D52C92B68E4BE087AF49C1DE4C2FB06A
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1647338825
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

        --  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