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.
On Tue, Nov 10, 2015 at 5:19 PM, Prasun Gera <prasun.g...@gmail.com> wrote: > > > On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale <ftwee...@redhat.com> > wrote: > >> On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote: >> > No it didn't quite work. >> > >> > I ran ipa-server-certinstall -w /etc/letsencrypt/live/ >> > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem >> > >> > which gives The full certificate chain is not present in >> > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/ >> > example.com/fullchain.pem >> > >> It looks like this error is triggered when there is no self-signed >> certificate in the trust chain (fullchain.pem). Could you confirm >> that this is the case, and if so, could you try appending the root >> certificate to fullchain.pem and trying again? >> >> > > I'm sorry, I didn't quite follow. Can you elaborate what I need to append > to what ? > > From let's encrypt's documentation: > > cert.pem > Server certificate only. > > This is what Apache needs for SSLCertificateFile. > > chain.pem > All certificates that need to be served by the browser excluding server > certificate, i.e. root and intermediate certificates only. > > This is what Apache needs for SSLCertificateChainFile. > > fullchain.pem > All certificates, including server certificate. This is concatenation of > chain.pem and cert.pem. > > This is what nginx needs for ssl_certificate. > > > So fullchain.pem should have all the relevant bits right ? Do you mean I > should append ipa's root cert from /etc/ipa/ca.crt ? > > > > > >> It may be that ipa-server-certinstall assumes that your server certs >> are signed by the same CA as your IPA CA certificate, which need not >> be the case. >> >> > >> > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale <ftwee...@redhat.com> >> > wrote: >> > >> > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote: >> > > > I tried using let's encrypt's certs manually, but I think I'm >> missing >> > > > something. Let's encrypt creates the following files : cert.pem >> > > chain.pem >> > > > fullchain.pem privkey.pem. I was trying to follow >> > > > >> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >> > > but i >> > > > wasn't able to get it to work. That page says, "The certificate in >> > > > mysite.crt must be signed by the CA used when installing FreeIPA." >> Since >> > > my >> > > > ipa installation uses the default internal CA, how do I get lets >> > > encrypt's >> > > > certs signed by the ipa CA ? Is that the missing step ? >> > > > >> > > I do not think that text is correct, in the case of a >> > > publicy-trusted certificate (i.e. the server cert is chained to a >> > > trusted issuer). >> > > >> > > Just ignore that text and follow the steps. Does it work? >> > > >> > > Cheers, >> > > Fraser >> > > >> > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera <prasun.g...@gmail.com> >> > > wrote: >> > > > >> > > > > Thanks for the discussion. If someone can update the >> documentation with >> > > > > mozilla style old, intermediate and modern cipher lists for >> mod_nss, >> > > that >> > > > > would be great. Better still would be to add that option to the >> > > installer >> > > > > scripts so that you can choose it during installation. Integrating >> > > that in >> > > > > the package would also have the added benefit of settings >> remaining up >> > > to >> > > > > date without manual intervention as standards evolve. >> > > > > >> > > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale < >> ftwee...@redhat.com> >> > > > > wrote: >> > > > > >> > > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote: >> > > > >> > Prasun Gera wrote: >> > > > >> > > Thanks. After the changes, most things seem to be in order. >> I see >> > > two >> > > > >> > > orange flags though: >> > > > >> > > >> > > > >> > > Secure Client-Initiated Renegotiation *Supported* >> *DoS >> > > > >> DANGER* (more >> > > > >> > > info >> > > > >> > > < >> > > > >> >> > > >> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks >> > > > >> >) >> > > > >> > >> > > > >> > Renegotiation is required for the CA so you need to leave this >> > > enabled. >> > > > >> > >> > > > >> > > Session resumption (caching) *No (IDs assigned but not >> > > > >> accepted)* >> > > > >> > >> > > > >> > I'll need to look at this in more detail. At worst it would >> slow new >> > > > >> > connection performance slightly as it means every connection >> > > requires a >> > > > >> > full SSL/TLS handshake. I don't think it's a show-stopper. >> > > > >> > >> > > > >> Definitely not a show-stopper. The main reason this is an >> "orange" >> > > > >> alert in SSLLabs is because the server is assigning Session IDs >> but >> > > > >> then ignoring them; although confusing it is a fairly common >> default >> > > > >> behaviour and doesn't cause any issues with compliant client >> > > > >> implementation >> > > > >> >> > > > >> > rob >> > > > >> > >> > > > >> > > >> > > > >> > > Are these relevant/serious ? Can they be mitigated ? >> > > > >> > > >> > > > >> > > >> > > > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden < >> > > rcrit...@redhat.com >> > > > >> > > <mailto:rcrit...@redhat.com>> wrote: >> > > > >> > > >> > > > >> > > Prasun Gera wrote: >> > > > >> > > > Yes, that's what I was planning to do. i.e. Convert >> cipher >> > > > >> names from >> > > > >> > > > SSL to NSS. I wasn't sure about the other settings >> though. >> > > Is >> > > > >> there an >> > > > >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? >> > > Similarly, >> > > > >> are there >> > > > >> > > > equivalent configs for HSTS on the mozilla page? Does >> NSS >> > > allow >> > > > >> using >> > > > >> > > > generated DH parameters instead of standard ones ? For >> SSL, >> > > the >> > > > >> > > > suggested modification to the config is >> 'SSLOpenSSLConfCmd >> > > > >> DHParameters >> > > > >> > > > "{path to dhparams.pem}"' after generating the params. >> > > > >> > > >> > > > >> > > NSS does not let the user specify cipher order. It uses >> its >> > > own >> > > > >> internal >> > > > >> > > sorting from strongest to weakest. >> > > > >> > > >> > > > >> > > HSTS is a header and not dependent upon SSL provider. >> > > > >> > > >> > > > >> > > mod_nss doesn't support DH ciphers. >> > > > >> > > >> > > > >> > > rob >> > > > >> > > >> > > > >> > > > >> > > > >> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale < >> > > > >> ftwee...@redhat.com <mailto:ftwee...@redhat.com> >> > > > >> > > > <mailto:ftwee...@redhat.com <mailto: >> ftwee...@redhat.com>>> >> > > > >> wrote: >> > > > >> > > > >> > > > >> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun >> Gera >> > > wrote: >> > > > >> > > > > Thanks for the ticket information. I would still >> be >> > > > >> interested in >> > > > >> > > > > configuring mod_nss properly (irrespective of >> whether >> > > the >> > > > >> certs are ipa >> > > > >> > > > > generated or 3rd party). These are the worrying >> notes >> > > > >> from ssllabs test: >> > > > >> > > > > >> > > > >> > > > > The server supports only older protocols, but >> not the >> > > > >> current best TLS 1.2. >> > > > >> > > > > Grade capped to C. >> > > > >> > > > > This server accepts the RC4 cipher, which is >> weak. >> > > Grade >> > > > >> capped to B. >> > > > >> > > > > The server does not support Forward Secrecy with >> the >> > > > >> reference browsers. >> > > > >> > > > > >> > > > >> > > > Use the "Modern" cipher suite[1] recommended by >> Mozilla >> > > as a >> > > > >> > > > starting point. See also the "Cipher names >> > > correspondence >> > > > >> table" on >> > > > >> > > > the same page for translating it to cipher names >> > > understood >> > > > >> by NSS >> > > > >> > > > to construct a valid setting for the >> `NSSCipherSuite' >> > > > >> directive. >> > > > >> > > > >> > > > >> > > > [1] >> > > > >> > > > >> > > > >> >> > > >> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility >> > > > >> > > > >> > > > >> > > > Cheers, >> > > > >> > > > Fraser >> > > > >> > > > >> > > > >> > > > > >> > > > >> > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale >> > > > >> > > > <ftwee...@redhat.com <mailto:ftwee...@redhat.com> >> > > > >> > > <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com >> >>> >> > > wrote: >> > > > >> > > > > >> > > > >> > > > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, >> Prasun >> > > Gera >> > > > >> wrote: >> > > > >> > > > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the >> webui >> > > > >> > > accessible >> > > > >> > > > publicly. >> > > > >> > > > > > I'm >> > > > >> > > > > > > using a stock configuration which uses the >> certs >> > > > >> signed by >> > > > >> > > > ipa's CA for >> > > > >> > > > > > the >> > > > >> > > > > > > webui. This is mostly for convenience since >> it >> > > manages >> > > > >> > > renewals >> > > > >> > > > > > seamlessly. >> > > > >> > > > > > > This, however, requires users to add the CA >> as >> > > trusted >> > > > >> > > to their >> > > > >> > > > > > browsers. A >> > > > >> > > > > > > promising alternative to this is >> > > > >> https://letsencrypt.org/, >> > > > >> > > > which issues >> > > > >> > > > > > > browser trusted certs, and will manage auto >> > > renewals >> > > > >> too (in >> > > > >> > > > the future). >> > > > >> > > > > > > As a feature request, it would be nice to >> have >> > > closer >> > > > >> > > > integration between >> > > > >> > > > > > > ipa and the letsencrypt client which would >> make >> > > > >> managing >> > > > >> > > certs >> > > > >> > > > simple. >> > > > >> > > > > > I'm >> > > > >> > > > > > > about to set this up manually right now >> using the >> > > > >> > > external ssl >> > > > >> > > > certs >> > > > >> > > > > > guide. >> > > > >> > > > > > > >> > > > >> > > > > > Let's Encrypt is on our radar. I like the >> idea of >> > > being >> > > > >> > > able to >> > > > >> > > > > > install FreeIPA with publicly-trusted certs for >> > > HTTP and >> > > > >> > > LDAP from >> > > > >> > > > > > the beginning. This would require some work in >> > > > >> > > ipa-server-install >> > > > >> > > > > > in addition to certmonger support and a good, >> stable >> > > > >> Let's >> > > > >> > > Encrypt / >> > > > >> > > > > > ACME client implementation for Apache on >> Fedora. >> > > > >> > > > > > >> > > > >> > > > > > Installing publicly-trusted HTTP / LDAP certs >> is a >> > > > >> common >> > > > >> > > activity >> > > > >> > > > > > so I filed a ticket: >> > > > >> > > https://fedorahosted.org/freeipa/ticket/5431 >> > > > >> > > > > > >> > > > >> > > > > > Cheers, >> > > > >> > > > > > Fraser >> > > > >> > > > > > >> > > > >> > > > > > > Secondly, since the webui uses mod_nss, how >> would >> > > one >> > > > >> set it >> > > > >> > > > up to prefer >> > > > >> > > > > > > security over compatibility with older >> clients ? >> > > The >> > > > >> vast >> > > > >> > > > majority of >> > > > >> > > > > > > documentation online (for eg. >> > > > >> > > > > > > >> > > > >> > > > >> > > > >> > > >> > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) >> > > > >> is >> > > > >> > > > > > about >> > > > >> > > > > > > mod_ssl and I think the configuration doesn't >> > > transfer >> > > > >> > > directly to >> > > > >> > > > > > mod_nss. >> > > > >> > > > > > > Since this is the only web facing component, >> I >> > > would >> > > > >> like to >> > > > >> > > > set it up to >> > > > >> > > > > > > use stringent requirements. Right now, a >> test on >> > > > >> > > > > > > https://www.ssllabs.com/ssltest/ and >> > > > >> > > > https://weakdh.org/sysadmin.html >> > > > >> > > > > > > identifies >> > > > >> > > > > > > several issues. Since these things are not >> really >> > > my >> > > > >> area of >> > > > >> > > > expertise, I >> > > > >> > > > > > > would like some documentation regarding this. >> > > Also, >> > > > >> > > would manually >> > > > >> > > > > > > modifying any of the config files be >> overwritten >> > > by a >> > > > >> > > yum update ? >> > > > >> > > > > > >> > > > >> > > > > > > -- >> > > > >> > > > > > > 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 >> > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > >> > > > >> > >> > > > >> >> > > > > >> > > > > >> > > >> > >
-- 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
