[Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Wed, Nov 11, 2015 at 02:50:20PM -0800, Prasun Gera wrote:
> I'll try this on an aws instance and report. Some googling also suggests
> that the additional step of "pk12util -i ipa.example.com.p12 -d
> /etc/httpd/alias" is needed, which is similar to what you suggested. A few
> more questions:
> 1) How would renewals work ? the pem files can be renewed on expiration
> from LE's client. Would I need to run the exact same steps every time ?
>
Ideally, Certmonger will learn how to renew the certs with Let's
Encrypt CA, by satisfying "Proof of Possession" challenges.

> 2) Do expired ones need to be removed from the db in some way before
> renewed ones can be added ?
>
IIRC you can just add the new cert.

> 3) If httpd's certs expire, it won't affect any other functionality apart
> from the webui right ? Are there any other side effects ? I won't be using
> this for ldap certs.
>
RPC API is also served over HTTP; the `ipa' CLI program uses this
API so it will be affected.

> 4) How would I revert to IPA signed certs with automatic renewal if I want
> to ? i.e. Reverting to stock configuration
> 
Issue and track certs with Certmonger, and update HTTP configuration
to use the new cert.  If you want to try this please write it up and
contribute to wiki!

Thanks,
Fraser

> 
> On Wed, Nov 11, 2015 at 8:33 AM, Rob Crittenden <rcritten at redhat.com> wrote:
> 
> > Fraser Tweedale wrote:
> >
> >> On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote:
> >>
> >>> You are right in that the fullchain.pem doesn't have the root
> >>> certificate.
> >>> I ran "openssl x509 -in chain.pem -noout -text", and saw that it
> >>> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and
> >>> Subject:
> >>> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
> >>> certificate for DST Root CA X3 from
> >>> https://www.identrust.com/certificates/trustid/root-download-x3.html,
> >>> which
> >>> is self signed from what I can tell. The issuer and the subject are the
> >>> same. I added that to the fullchain, and the command seemed to work.
> >>> However, it messed something up, and httpd didn't start after that. httpd
> >>> error log had "Unable to verify certificate 'Signing-Cert'. Add
> >>> "NSSEnforceValidCerts off" to nss.conf so the server can start until the
> >>> problem can be resolved ". I added that to nss.conf, and ipactl started
> >>> successfully after that. However, the webui hadn't configured the
> >>> certificates properly. At this point, I just restored my backups
> >>> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
> >>> where things were earlier. I think it would be better to do these
> >>> experiments on a test bed first.
> >>>
> >>> I am at a loss, and must have missed something.  The purpose of this
> >> command is to be able to install 3rd party certificates, yet the
> >> code is expecting the certs to be signed by the IPA CA?
> >>
> >> Can someone explain what is going on here?
> >>
> >
> > That isn't the problem. It doesn't require the IPA CA at all. It just
> > checks that the root CA which issued the server cert is available (looks
> > for subject == issuer). It would appear that something wasn't imported into
> > the Apache NSS db.
> >
> > You'd need to re-run the import and then look at the Apache NSS database
> > to ensure that the entire cert chain was imported with the proper trust
> > which apparently it wasn't.
> >
> > # certutil -L -d /etc/httpd/alias
> >
> > The entire chain should be there, probably with trust like CT,, or C,,.
> >
> > To fix trust:
> >
> > # certutil -M -n "<nickname>" -t CT,, -d /etc/httpd/alias
> >
> > To add missing certs:
> >
> > # certutil -A -n "<nickname"> -t CT,, -d /etc/httpd/alias -i -i
> > /path/to/pem
> >
> > Validate the web server cert. Use whatever nickname is appropriate for you:
> >
> > # certutil -V -u V -n Server-Cert -d /etc/httpd/alias
> >
> > The more details you have on what you did to fix this the better as that
> > can be used to generate a new bug to fix this upstream.
> >
> > rob
> >