Marc Sauton wrote:
> 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/html/administration_guide/managing_the_nss_database_used_by_directory_server#importing-a-private-key-and-server-certifiate
> 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/html/administration_guide/managing_the_nss_database_used_by_directory_server#installing_a_ca_certificate
> 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_ACME_Responder_with_Certbot.md
> https://github.com/dogtagpki/pki/wiki/Using-PKI-ACME-Responder-with-openshift-acme
> 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.

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.

rob

> 
> 
> 
> 
> On Wed, Apr 5, 2023 at 9:20 AM John Thurston <[email protected]
> <mailto:[email protected]>> 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
>     [email protected] <mailto:[email protected]>
>     Department of Administration
>     State of Alaska
> 
>     _______________________________________________
>     389-users mailing list -- [email protected]
>     <mailto:[email protected]>
>     To unsubscribe send an email to
>     [email protected]
>     <mailto:[email protected]>
>     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/[email protected]
>     Do not reply to spam, report it:
>     https://pagure.io/fedora-infrastructure/new_issue
> 
> 
> _______________________________________________
> 389-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> 
_______________________________________________
389-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to