> 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
