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?

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

Reply via email to