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
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)
You should only need ROOTCA for -CA, since the chain will be presented by 389-ds itself as you have the chain on the server. Otherwise yep, sounds like you just need to ensure clients have the ca cert setup correctly.
Happy to help!
-- 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....
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia
On 16.03.22 23:39, William Brown wrote:
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)
You should only need ROOTCA for -CA, since the chain will be presented by 389-ds itself as you have the chain on the server. Otherwise yep, sounds like you just need to ensure clients have the ca cert setup correctly.
Happy to help!
This is to confirm, that
openssl s_client -connect ur1.XXXXXX.XXXXXX.de:3636 -CAfile /root/389ds/tls/ca/XXXXXROOTCA2015.crt
works. So, yes, only the root cert of a chain (and not the whole chain) is needed for server-cert validation done by openssl.
SSL handshake has read 4836 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: 00105D8E1E655FA19A50EE017FF268699100CB1ED8B3B5CF4DF7A823D98ED724 Session-ID-ctx: Master-Key: C6FD29B95BCAC68C69D6FD995E01416857B5DAF5CBFED0E679C730CC4017BF75D0D66529E11383A9099932E89042BC06 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1647513405 Timeout : 300 (sec) Verify return code: 0 (ok) ---
You are the man, William! Thank you so much.
Still, I suggest to remove the ssca stuff, if a customer provides his own cert chain. Even if everything works properly, I think it's unnecessary to store the ssca cert and key in the databases. From a troubleshooting perspective it's a bit misleading in my opinion. Or is there a benefit of keeping it that I do not see?
Thanks and best regards, Lutz
-- 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....
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- 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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 17 Mar 2022, at 20:50, Lutz Berger lutz.berger@multigrid.de wrote:
On 16.03.22 23:39, William Brown wrote:
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)
You should only need ROOTCA for -CA, since the chain will be presented by 389-ds itself as you have the chain on the server. Otherwise yep, sounds like you just need to ensure clients have the ca cert setup correctly.
Happy to help!
This is to confirm, that
openssl s_client -connect ur1.XXXXXX.XXXXXX.de:3636 -CAfile /root/389ds/tls/ca/XXXXXROOTCA2015.crt
works. So, yes, only the root cert of a chain (and not the whole chain) is needed for server-cert validation done by openssl.
You are the man, William! Thank you so much.
You are most welcome :)
Still, I suggest to remove the ssca stuff, if a customer provides his own cert chain. Even if everything works properly, I think it's unnecessary to store the ssca cert and key in the databases. From a troubleshooting perspective it's a bit misleading in my opinion. Or is there a benefit of keeping it that I do not see?
It's not that there is a benefit as much as "NSS makes it a complete pain" to remove keys. That's why I never really bothered to actually do it in these cases when we are loading in the data from PEM's :(
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia
Hello Lutz and William,
I have used the certutil -J option to remove orphaned private keys from the NSS key database (in this case key3.db). I always make a tarball backup of the three NSS database files (cert8.db, key3.db, secmod.db) before performing the operation just in case something goes awry.
Example: #List private keys in NSS keystore certutil -K -d /etc/dirsrv/slapd-mydir/alias/ certutil: Checking token "NSS FIPS 140-2 Certificate DB" in slot "NSS FIPS 140-2 User Private Key Services" Enter Password or Pin for "NSS FIPS 140-2 Certificate DB": < 0> rsa ea4730830deb0dd40a7b2f6d4578a28132ae0251 NSS FIPS 140-2 Certificate DB:Server-Cert < 1> rsa 0c7130b409a03ae2752b0cba6a6dc834d7d5dfb0 (orphan)
#Remove the orphaned key using its keyid certutil -F -k 0c7130b409a03ae2752b0cba6a6dc834d7d5dfb0 -d /etc/dirsrv/slapd-mydir/alias/ Enter Password or Pin for "NSS FIPS 140-2 Certificate DB":
##List private keys again certutil -K -d /etc/dirsrv/slapd-mydir/alias/ certutil: Checking token "NSS FIPS 140-2 Certificate DB" in slot "NSS FIPS 140-2 User Private Key Services" Enter Password or Pin for "NSS FIPS 140-2 Certificate DB": < 0> rsa ea4730830deb0dd40a7b2f6d4578a28132ae0251 NSS FIPS 140-2 Certificate DB:Server-Cert
Thanks, Dave
David Ritenour Senior Directory Engineer MartinFederal Consulting, LLC 513 Madison Street SE Huntsville, AL 35801
-----Original Message----- From: William Brown william.brown@suse.com Sent: Thursday, March 17, 2022 7:02 PM To: Lutz Berger lutz.berger@multigrid.de Cc: 389-users@lists.fedoraproject.org Subject: [389-users] Re: docker, 389ds/dirsrv:2.0, vendorVersion 2.1.0, ssca, certificate chain, orphan key, cert9.db, key4.db
** WARNING: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On 17 Mar 2022, at 20:50, Lutz Berger lutz.berger@multigrid.de wrote:
On 16.03.22 23:39, William Brown wrote:
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)
You should only need ROOTCA for -CA, since the chain will be presented by 389-ds itself as you have the chain on the server. Otherwise yep, sounds like you just need to ensure clients have the ca cert setup correctly.
Happy to help!
This is to confirm, that
openssl s_client -connect ur1.XXXXXX.XXXXXX.de:3636 -CAfile /root/389ds/tls/ca/XXXXXROOTCA2015.crt
works. So, yes, only the root cert of a chain (and not the whole chain) is needed for server-cert validation done by openssl.
You are the man, William! Thank you so much.
You are most welcome :)
Still, I suggest to remove the ssca stuff, if a customer provides his own cert chain. Even if everything works properly, I think it's unnecessary to store the ssca cert and key in the databases. From a troubleshooting perspective it's a bit misleading in my opinion. Or is there a benefit of keeping it that I do not see?
It's not that there is a benefit as much as "NSS makes it a complete pain" to remove keys. That's why I never really bothered to actually do it in these cases when we are loading in the data from PEM's :(
-- 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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email and any such files in error and that any use, dissemination, forwarding, printing or copying of this email and/or any such files is strictly prohibited. If you have received this email in error please immediately notify hr@martinfed.com - (855) 212-1810 , and destroy the original message and any such files.
389-users@lists.fedoraproject.org
-
David Ritenour -
Lutz Berger -
William Brown