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

No comments:

Post a Comment