Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Rob Crittenden]

Fraser Tweedale wrote:

On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote:

You are right in that the fullchain.pem doesn't have the root certificate.
I ran "openssl x509 -in chain.pem -noout -text", and saw that it
had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and Subject:
C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
certificate for DST Root CA X3 from
https://www.identrust.com/certificates/trustid/root-download-x3.html, which
is self signed from what I can tell. The issuer and the subject are the
same. I added that to the fullchain, and the command seemed to work.
However, it messed something up, and httpd didn't start after that. httpd
error log had "Unable to verify certificate 'Signing-Cert'. Add
"NSSEnforceValidCerts off" to nss.conf so the server can start until the
problem can be resolved ". I added that to nss.conf, and ipactl started
successfully after that. However, the webui hadn't configured the
certificates properly. At this point, I just restored my backups
of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
where things were earlier. I think it would be better to do these
experiments on a test bed first.


I am at a loss, and must have missed something.  The purpose of this
command is to be able to install 3rd party certificates, yet the
code is expecting the certs to be signed by the IPA CA?

Can someone explain what is going on here?


That isn't the problem. It doesn't require the IPA CA at all. It just 
checks that the root CA which issued the server cert is available (looks 
for subject == issuer). It would appear that something wasn't imported 
into the Apache NSS db.


You'd need to re-run the import and then look at the Apache NSS database 
to ensure that the entire cert chain was imported with the proper trust 
which apparently it wasn't.


# certutil -L -d /etc/httpd/alias

The entire chain should be there, probably with trust like CT,, or C,,.

To fix trust:

# certutil -M -n "" -t CT,, -d /etc/httpd/alias

To add missing certs:

# certutil -A -n " -t CT,, -d /etc/httpd/alias -i -i /path/to/pem

Validate the web server cert. Use whatever nickname is appropriate for you:

# certutil -V -u V -n Server-Cert -d /etc/httpd/alias

The more details you have on what you did to fix this the better as that 
can be used to generate a new bug to fix this upstream.


rob

--
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

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Wed, Nov 11, 2015 at 02:50:20PM -0800, Prasun Gera wrote:
> I'll try this on an aws instance and report. Some googling also suggests
> that the additional step of "pk12util -i ipa.example.com.p12 -d
> /etc/httpd/alias" is needed, which is similar to what you suggested. A few
> more questions:
> 1) How would renewals work ? the pem files can be renewed on expiration
> from LE's client. Would I need to run the exact same steps every time ?
>
Ideally, Certmonger will learn how to renew the certs with Let's
Encrypt CA, by satisfying "Proof of Possession" challenges.

> 2) Do expired ones need to be removed from the db in some way before
> renewed ones can be added ?
>
IIRC you can just add the new cert.

> 3) If httpd's certs expire, it won't affect any other functionality apart
> from the webui right ? Are there any other side effects ? I won't be using
> this for ldap certs.
>
RPC API is also served over HTTP; the `ipa' CLI program uses this
API so it will be affected.

> 4) How would I revert to IPA signed certs with automatic renewal if I want
> to ? i.e. Reverting to stock configuration
> 
Issue and track certs with Certmonger, and update HTTP configuration
to use the new cert.  If you want to try this please write it up and
contribute to wiki!

Thanks,
Fraser

> 
> On Wed, Nov 11, 2015 at 8:33 AM, Rob Crittenden  wrote:
> 
> > Fraser Tweedale wrote:
> >
> >> On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote:
> >>
> >>> You are right in that the fullchain.pem doesn't have the root
> >>> certificate.
> >>> I ran "openssl x509 -in chain.pem -noout -text", and saw that it
> >>> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and
> >>> Subject:
> >>> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
> >>> certificate for DST Root CA X3 from
> >>> https://www.identrust.com/certificates/trustid/root-download-x3.html,
> >>> which
> >>> is self signed from what I can tell. The issuer and the subject are the
> >>> same. I added that to the fullchain, and the command seemed to work.
> >>> However, it messed something up, and httpd didn't start after that. httpd
> >>> error log had "Unable to verify certificate 'Signing-Cert'. Add
> >>> "NSSEnforceValidCerts off" to nss.conf so the server can start until the
> >>> problem can be resolved ". I added that to nss.conf, and ipactl started
> >>> successfully after that. However, the webui hadn't configured the
> >>> certificates properly. At this point, I just restored my backups
> >>> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
> >>> where things were earlier. I think it would be better to do these
> >>> experiments on a test bed first.
> >>>
> >>> I am at a loss, and must have missed something.  The purpose of this
> >> command is to be able to install 3rd party certificates, yet the
> >> code is expecting the certs to be signed by the IPA CA?
> >>
> >> Can someone explain what is going on here?
> >>
> >
> > That isn't the problem. It doesn't require the IPA CA at all. It just
> > checks that the root CA which issued the server cert is available (looks
> > for subject == issuer). It would appear that something wasn't imported into
> > the Apache NSS db.
> >
> > You'd need to re-run the import and then look at the Apache NSS database
> > to ensure that the entire cert chain was imported with the proper trust
> > which apparently it wasn't.
> >
> > # certutil -L -d /etc/httpd/alias
> >
> > The entire chain should be there, probably with trust like CT,, or C,,.
> >
> > To fix trust:
> >
> > # certutil -M -n "" -t CT,, -d /etc/httpd/alias
> >
> > To add missing certs:
> >
> > # certutil -A -n " -t CT,, -d /etc/httpd/alias -i -i
> > /path/to/pem
> >
> > Validate the web server cert. Use whatever nickname is appropriate for you:
> >
> > # certutil -V -u V -n Server-Cert -d /etc/httpd/alias
> >
> > The more details you have on what you did to fix this the better as that
> > can be used to generate a new bug to fix this upstream.
> >
> > rob
> >

-- 
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

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

I'll try this on an aws instance and report. Some googling also suggests
that the additional step of "pk12util -i ipa.example.com.p12 -d
/etc/httpd/alias" is needed, which is similar to what you suggested. A few
more questions:
1) How would renewals work ? the pem files can be renewed on expiration
from LE's client. Would I need to run the exact same steps every time ?
2) Do expired ones need to be removed from the db in some way before
renewed ones can be added ?
3) If httpd's certs expire, it won't affect any other functionality apart
from the webui right ? Are there any other side effects ? I won't be using
this for ldap certs.
4) How would I revert to IPA signed certs with automatic renewal if I want
to ? i.e. Reverting to stock configuration


On Wed, Nov 11, 2015 at 8:33 AM, Rob Crittenden  wrote:

> Fraser Tweedale wrote:
>
>> On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote:
>>
>>> You are right in that the fullchain.pem doesn't have the root
>>> certificate.
>>> I ran "openssl x509 -in chain.pem -noout -text", and saw that it
>>> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and
>>> Subject:
>>> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
>>> certificate for DST Root CA X3 from
>>> https://www.identrust.com/certificates/trustid/root-download-x3.html,
>>> which
>>> is self signed from what I can tell. The issuer and the subject are the
>>> same. I added that to the fullchain, and the command seemed to work.
>>> However, it messed something up, and httpd didn't start after that. httpd
>>> error log had "Unable to verify certificate 'Signing-Cert'. Add
>>> "NSSEnforceValidCerts off" to nss.conf so the server can start until the
>>> problem can be resolved ". I added that to nss.conf, and ipactl started
>>> successfully after that. However, the webui hadn't configured the
>>> certificates properly. At this point, I just restored my backups
>>> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
>>> where things were earlier. I think it would be better to do these
>>> experiments on a test bed first.
>>>
>>> I am at a loss, and must have missed something.  The purpose of this
>> command is to be able to install 3rd party certificates, yet the
>> code is expecting the certs to be signed by the IPA CA?
>>
>> Can someone explain what is going on here?
>>
>
> That isn't the problem. It doesn't require the IPA CA at all. It just
> checks that the root CA which issued the server cert is available (looks
> for subject == issuer). It would appear that something wasn't imported into
> the Apache NSS db.
>
> You'd need to re-run the import and then look at the Apache NSS database
> to ensure that the entire cert chain was imported with the proper trust
> which apparently it wasn't.
>
> # certutil -L -d /etc/httpd/alias
>
> The entire chain should be there, probably with trust like CT,, or C,,.
>
> To fix trust:
>
> # certutil -M -n "" -t CT,, -d /etc/httpd/alias
>
> To add missing certs:
>
> # certutil -A -n " -t CT,, -d /etc/httpd/alias -i -i
> /path/to/pem
>
> Validate the web server cert. Use whatever nickname is appropriate for you:
>
> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias
>
> The more details you have on what you did to fix this the better as that
> can be used to generate a new bug to fix this upstream.
>
> rob
>
-- 
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

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

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  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 
> > 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  >> > > > 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 
> >> > > > >>
> >> 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
> >> > > 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

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 
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 
> 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 
> > > 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
> > >> > > > 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 
> > >> > > > >>
> > >> 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 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

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 ?

On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera  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 
> 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 > > > > 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 
>> > > > >>
>> 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
>> > > > 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

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 
> 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 
> > 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 
> > > > 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
> > > >> > > > 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 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale 
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 
> > 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 
> > > 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 <
> > > 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote:
> You are right in that the fullchain.pem doesn't have the root certificate.
> I ran "openssl x509 -in chain.pem -noout -text", and saw that it
> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and Subject:
> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
> certificate for DST Root CA X3 from
> https://www.identrust.com/certificates/trustid/root-download-x3.html, which
> is self signed from what I can tell. The issuer and the subject are the
> same. I added that to the fullchain, and the command seemed to work.
> However, it messed something up, and httpd didn't start after that. httpd
> error log had "Unable to verify certificate 'Signing-Cert'. Add
> "NSSEnforceValidCerts off" to nss.conf so the server can start until the
> problem can be resolved ". I added that to nss.conf, and ipactl started
> successfully after that. However, the webui hadn't configured the
> certificates properly. At this point, I just restored my backups
> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
> where things were earlier. I think it would be better to do these
> experiments on a test bed first.
> 
I am at a loss, and must have missed something.  The purpose of this
command is to be able to install 3rd party certificates, yet the
code is expecting the certs to be signed by the IPA CA?

Can someone explain what is going on here?

Fraser

> 
> On Tue, Nov 10, 2015 at 5:19 PM, Prasun Gera  wrote:
> 
> >
> >
> > On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale 
> > 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 
> >> > 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 
> >> > > 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
> >> 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

You are right in that the fullchain.pem doesn't have the root certificate.
I ran "openssl x509 -in chain.pem -noout -text", and saw that it
had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and Subject:
C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
certificate for DST Root CA X3 from
https://www.identrust.com/certificates/trustid/root-download-x3.html, which
is self signed from what I can tell. The issuer and the subject are the
same. I added that to the fullchain, and the command seemed to work.
However, it messed something up, and httpd didn't start after that. httpd
error log had "Unable to verify certificate 'Signing-Cert'. Add
"NSSEnforceValidCerts off" to nss.conf so the server can start until the
problem can be resolved ". I added that to nss.conf, and ipactl started
successfully after that. However, the webui hadn't configured the
certificates properly. At this point, I just restored my backups
of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
where things were earlier. I think it would be better to do these
experiments on a test bed first.


On Tue, Nov 10, 2015 at 5:19 PM, Prasun Gera  wrote:

>
>
> On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale 
> 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 
>> > 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 
>> > > 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:
>> > > > >> > >
>> 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

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  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  > > > 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 
> > > > >>
> 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
> > > > 
> > > >> 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
> > >

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

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.

On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale  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 
> 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

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

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

)Session resumption (caching)*No (IDs assigned but not accepted)*
Are these relevant/serious ? Can they be mitigated ?


On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden  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  > > 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
> > > 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
> > > > > 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Rob Crittenden]

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
> )

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.

rob

> 
> Are these relevant/serious ? Can they be mitigated ?
> 
> 
> On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden  > 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  
> > >> 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
> > 
> >> 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,
>   

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

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
> > )
> 
> 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  > > 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  > 
> > > >> 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
> > > 
> > >> 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 

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Rob Crittenden]

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  > 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
> > 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

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Fraser Tweedale]

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

[Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

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.

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

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Rob Crittenden]

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.

TLSv1.2 support in mod_nss will be available in RHEL 7.2. The version of
mod_nss in 7.1 only supports up to v1.1.

> This server accepts the RC4 cipher, which is weak. Grade capped to B.

You'll need to manually set your own cipher list excluding RC4 ciphers.
It depends on how compatible you want to be with older clients, but
perhaps something like this:

NSSCipherSuite
+rsa_3des_sha,+rsa_aes_128_sha,+rsa_aes_256_sha,+ecdhe_rsa_aes_256_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_3des_sha

> The server does not support Forward Secrecy with the reference browsers.

This will go away when you enable the ECDHE ciphers.

Changes to this file should survive upgrades.

rob

> 
> 
> On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale  > 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