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

Reply via email to