On 22 Mar 2022, at 08:54, Lutz Berger
thanks for the brilliant explanation!
I think the correct English phrase is:
The devil is in the details.
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:
It's a bit old and needs a rework, but it has a lot of helpful tips.
Anyway, happy to have helped out, and feel free to mail the list if you have other
Dipl.-Inform. Univ. Lutz Berger
Kettwiger Straße 43
45468 Mülheim an der Ruhr
On 21.03.22 01:02, William Brown wrote:
>> So "slapd_extract_cert" should not extract cert/key from
>> 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
> 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
> 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,
> William Brown
> Senior Software Engineer,
> Identity and Access Management
> SUSE Labs, Australia
> 389-users mailing list --
> To unsubscribe send an email to
> Fedora Code of Conduct:
> List Guidelines:
> List Archives:
> Do not reply to spam on the list, report it:
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia