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