The "dsconf some-instance-name security" and dsctl commands can be used to manipulated the certs and keys used by the LDAP service: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11... 9.3.3. Importing a Private Key and Server Certificate 9.3.4. Installing a Server Certificate and https://access.redhat.com/documentation/en-us/red_hat_directory_server/11... 9.3. Managing the NSS Database Used by Directory Server Plus run the system's "trust anchor" command so a PKI chain of trust is known by the local system. Or, if the LDAP service is stopped, a new PEM cert can replace the existing SSL server cert in the NSS db using a certutil -A command, or a PKCS #12 file can be exported or imported into the NSS db ( pk12util -h ) For ACME, as a reference from the PKI server side of things, there is an example of an ACME responder from the upstream PKI project dogtag ( used for the Red Hat Certificate System / general purpose PKI solution ), and the suggested ACME clients are certbot and openshit-acme, in case it may provide with some ideas: https://github.com/dogtagpki/pki/blob/master/docs/user/acme/Using_PKI_ACM... https://github.com/dogtagpki/pki/wiki/Using-PKI-ACME-Responder-with-opens... But of course any ACME compliant client should work just fine, it would be interesting to know more if anybody is using ACME for the LDAP SSL server certs, and what kind of validity dates are used. Thanks, Marc S.

On Wed, Apr 5, 2023 at 9:20 AM John Thurston <john.thurston(a)alaska.gov <mailto:john.thurston@alaska.gov>> wrote: We currently use publicly-signed, and manually renewed, certificates on our internal directory servers. On other internal and external systems, we use public and private certificates handled by ACME-compliant agents. I took a quick look, and was reminded that 389-Directory keeps its certs in an NSS database. Before I go hack together my own wrapper on certutil, I thought I'd ask: Does anyone have a working ACME/Let's Encrypt agent they want to share? -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston(a)alaska.gov <mailto:John.Thurston@alaska.gov> Department of Administration State of Alaska _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> 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@lists.fedoraproje... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org 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@lists.fedoraproje... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Yep. That was the question. I've been hacking on /dehydrated /hook-scripts, and am pretty close to where I want to be. I'm using DNS-01 challenge (so needed to write the handlers for that) I find NSS databases to be a PITA, so in the deploy_cert handler, I'm + building a new NSS + importing the Let's Encrypt intermediates + importing the new cert and key under the expected name Then I'll just replace the old NSS with the new

-- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston(a)alaska.gov Department of Administration State of Alaska On 4/5/2023 10:32 AM, Rob Crittenden wrote: > I think he was asking if a script exists that will work with ACME and > NSS databases. It is quite a broad question because it does depend on > the client used. > > I think I would use certbot and leave the private key and certificates > in the flat filesystem and use a post-hook to stop 389, load the updated > cert using certutil, restart 389. > > I'm lazy so after the first request I'd manually create a PKCS#12 out of > it and load that into the 389 NSS db. All subsequent calls with the > post-hook should work fine as long as the private key is retained. > > But I haven't tried it. _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org 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@lists.fedoraproje... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Hi , Anyone please suggest I have recentlly migrated edirectory to 389 directory server everything is working fine. But while creating new user from customer side the user creation is working only by giving a value in attribute pan if not giving value in attribute pan it will not create. So please suggest how to make the pan attribute non mandatory