Thursday, March 17, 2022

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

> On 17 Mar 2022, at 20:50, Lutz Berger <> 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 -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 -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 -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 :(


William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia
389-users mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam on the list, report it:

No comments:

Post a Comment