[Freeipa-devel] FreeIPA and modern requirements on certificates

Fraser Tweedale ftweedal at redhat.com
Fri Jan 8 12:56:19 UTC 2016


On Fri, Jan 08, 2016 at 01:26:57PM +0100, Martin Kosek wrote:
> Hi Fraser and other X.509 SMEs,
> 
> I wanted to check with you on what we have or plan to have with respect to
> certificate/cipher strength in FreeIPA.
> 
> When I visit the FreeIPA public demo for example, I usually see following
> errors with recent browsers:
> 
> * Your connection to ipa.demo1.freeipa.org is encrypted using obsolete cypher
> suite.
>  - The connection uses TLS 1.2
>  - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1 for message
> authentication and RSA as the key exchange mechanism
> 
This is a cipher suite / ordering issue, not related to certificate.

> I usually do not see the common
> * Certificate chain contains a certificate signed with SHA-1
> error, but I am not sure if we are covered for this one.
> 
We are using sha256 for IPA CA and default profiles.  Customers
could still modify the profile or add profiles to sign using an
obsolete hash, if they wanted to, but our default is good.

> 
> When I tested the FreeIPA demo with
> https://www.ssllabs.com/ssltest/analyze.html?d=ipa.demo1.freeipa.org
> (and ignore the trust issues), we get the mark B with following warnings:
> 
> * This server accepts RC4 cipher, but only with older protocol versions. Grade
> capped to B.
> 
> * The server does not support Forward Secrecy with the reference browsers.
> 
Again a cipher suite tweak will address this.

> 
> What do we miss to turn out Grade A, which is obviously something expected from
> security solution like FreeIPA? Is it just about ECC support
> (https://fedorahosted.org/freeipa/ticket/3951) or also maybe some change to our
> default certificate profiles?
> 
Based on what you've written, it is just the cipher suite that needs
changing, and maybe a setting about favouring server cipher order
over client order.  ECC certificate support is not needed (yet) and
the default profile is fine, w.r.t. hash used for signing.

One important modern certificate requirement is to always include a
SAN dnsName for the subject, as required by RFC 2818; this is ticket
#4970 and it is on my radar.

Cheers,
Fraser

> Thanks!
> 
> -- 
> Martin Kosek <mkosek at redhat.com>
> Manager, Software Engineering - Identity Management Team
> Red Hat, Inc.




More information about the Freeipa-devel mailing list