On 22.03.22 00:08, William Brown wrote:
It does. It's more that I like to be explicit for the sake of readability of the commandsOn 22 Mar 2022, at 08:54, Lutz Berger <lutz.berger@xxxxxxxxxxxx> wrote: Hi William, thanks for the brilliant explanation! I think the correct English phrase is: The devil is in the details.Absolutely :)It makes a lot of sense to me to focus on the robustness of the installation, rather than optimizing minor things.For certain. I wanted the users of 389 to have a good experience and reliability is a huge part of that. So I'm glad that you appreciate it :)Anyway, it was a good exercise for me to look into "certutil" again. I definitely like "certutil ... -d sql:." ;-)I thought certutil defaulted to sql mode now but maybe I'm wrong ... I have a guide on some of the commands too:
I use.
Surprisingly, I've already found this guide on the web and thought:https://fy.blackhats.net.au/blog/html/pages/nss_and_openssl_command_reference.html It's a bit old and needs a rework, but it has a lot of helpful tips.
Wow, that's a very good reference ;-)
Will do.Anyway, happy to have helped out, and feel free to mail the list if you have other questions :)
Take care, Lutz Dipl.-Inform. Univ. Lutz Berger Kettwiger Straße 43 45468 Mülheim an der Ruhr E-Mail: lutz.berger@xxxxxxxxxxxx USt-IdNr.: DE280466318 On 21.03.22 01:02, William Brown wrote:So "slapd_extract_cert" should not extract cert/key from "ssca" if a valid cert/key is given in "tls".It's a bit more difficult than that - I'm the author of a big chunk of the lib389 python, dscreate/instance setup, ssca, and the cli tools in question. The main reason for this is how the bootstrapping process works - when we setup an instance, in order to configure it with TLS and other security properties we need a valid NSS database present. NSS is how we access all our internal key materials, and NSS can't use PEM files directly. So during the setup, we have to create the "self signed" keys, because without them existing, we can NOT install the other elements of the encryption and TLS setup. The TLS extract and setup phase is *seperate* to this setup, and has to be completed after, because the NSS DB path is the same directory as the dse.ldif config. As well, we need all those paths setup with the correct permissions defined by the uid/gid given to the dscreate calls (setup instance under the hood). Because of this, the tls extract runs *after*, so that we aren't re-inventing all those moving parts. The TLS extract automation is also specific to the container, it's not done as a normal part of dscreate. We could move it in there if people wanted to supply their own certs on dscreate, and that would let us move some of these steps around in the container too. But there is a risk - you could also imagine if the person passed us *invalid* keys. We'd be part way into the setup process, and we'd have to terminate because of some property of the certs being invalid. It's far cleaner to limit the surface area here to allow setup to proceed and succeed, and then have the TLS import as a seperate step subsequent that can fail with it's own error (but does NOT prevent the instance from being correctly installed). This ends up saving a lot of time and hassle. So right now, the reason for this is pretty much about ensuring a consistent and deterministic setup state. A lot of thought and care went into the instance creation code to make sure it was extremely robust. So while it may seem "messy" that there is a left-over and orphaned private key in the NSS db, it's really a minor problem in the scheme of things compared to creating a really robust installer and setup system.Hopefully my explanation is clear enough. As William pointed out: Everything works fine... it's more a side effect for the certificate connoisseur ;-) Feedback is welcome! Thanks and best regards, Lutz-- 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
