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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx>
Sent: Thursday, March 17, 2022 7:02 PM
To: Lutz Berger <lutz.berger@xxxxxxxxxxxx>
Cc: 389-users@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxx> 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@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
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@xxxxxxxxxxxxx - (855) 212-1810 , and destroy the original message and any such files.
_______________________________________________
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




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux