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

[Prasun Gera]

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 ?
2) Do expired ones need to be removed from the db in some way before
renewed ones can be added ?
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.
4) How would I revert to IPA signed certs with automatic renewal if I want
to ? i.e. Reverting to stock configuration


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20151111/267a450c/attachment.htm>