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