[Freeipa-devel] FreeIPA and modern requirements on certificates

[Martin Kosek]

On 01/08/2016 01:56 PM, Fraser Tweedale wrote:
> 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

Should I then file a ticket to fix the cipher suite? (I did not fully
understand the specifics though).