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


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