<div dir="ltr">No it didn't quite work. <div> </div><div>I ran ipa-server-certinstall -w /etc/letsencrypt/live/<a href="http://example.com/privkey.pem">example.com/privkey.pem</a> /etc/letsencrypt/live/<a href="http://example.com/fullchain.pem">example.com/fullchain.pem</a></div><div> </div><div>which gives The full certificate chain is not present in /etc/letsencrypt/live/<a href="http://example.com/privkey.pem">example.com/privkey.pem</a>, /etc/letsencrypt/live/<a href="http://example.com/fullchain.pem">example.com/fullchain.pem</a></div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale <<a href="mailto:ftweedal@redhat.com" target="_blank">ftweedal@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 > <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> 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 <div class="HOEnZb"><div class="h5"> > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera <<a href="mailto:prasun.gera@gmail.com">prasun.gera@gmail.com</a>> 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 <<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a>> > > 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 > >> > > < > >> <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> > >> >) > >> > > >> > 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 <<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a> > >> > > <mailto:<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a>>> 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 < > >> <a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a> <mailto:<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a>> > >> > > > <mailto:<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a> <mailto:<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a>>>> > >> 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] > >> > > > > >> <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> > >> > > > > >> > > > Cheers, > >> > > > Fraser > >> > > > > >> > > > > > >> > > > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale > >> > > > <<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a> <mailto:<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a>> > >> > > <mailto:<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a> <mailto:<a href="mailto:ftweedal@redhat.com">ftweedal@redhat.com</a>>>> 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 > >> <a href="https://letsencrypt.org/" rel="noreferrer" target="_blank">https://letsencrypt.org/</a>, > >> > > > 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: > >> > > <a href="https://fedorahosted.org/freeipa/ticket/5431" rel="noreferrer" target="_blank">https://fedorahosted.org/freeipa/ticket/5431</a> > >> > > > > > > >> > > > > > 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. > >> > > > > > > > >> > > > > >> > > <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>) > >> 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 > >> > > > > > > <a href="https://www.ssllabs.com/ssltest/" rel="noreferrer" target="_blank">https://www.ssllabs.com/ssltest/</a> and > >> > > > <a href="https://weakdh.org/sysadmin.html" rel="noreferrer" target="_blank">https://weakdh.org/sysadmin.html</a> > >> > > > > > > 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: > >> > > > > > > <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a> > >> > > > > > > Go to <a href="http://freeipa.org" rel="noreferrer" target="_blank">http://freeipa.org</a> for more info on the project > >> > > > > > > >> > > > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > > > </div></div></blockquote></div> </div>