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 <rcrit...@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 >
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project