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-le...@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-le...@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-le...@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
