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

>>>
>>> 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.org
>>
>> 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.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure