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