The guidelines on Server Side TLS are pretty good, and it is pretty similar to my own cipher list that I use in production. It and the config generator are a great resource to give to people who are less informed about TLS config.

My only real gripe is that despite almost exclusively using explicit cipher suite names, there are three groups thrown in:

1. kEDH+AESGCM 2. AES 3. CAMELLIA

which then require trailing filters to disable unwanted possible side effects. It's a lot more confusing for the lay person to read, and may produce unintended results on untested versions of OpenSSL.

The first group will not output AES ordering in the preferred order (AES128 then AES256). The second one is redundant in my opinion. The third will likewise produce out-of-order results -- if you trust Camellia, wouldn't you prefer to use a forward secret cipher (DHE-RSA-CAMELLIA256-SHA) before a non-forward secret one (AES256-SHA)?

On the topic of Camellia, I don't understand why it makes the cut on the intermediate config. No browser ever supported Camellia that didn't also support AES, did it?

Anyway, I would view it as an improvement if all of the cipher suites were listed explicitly with no groups, so that there is no need for complicated filters at the end and the potential of activating something in a different version of OpenSSL that you didn't expect to be there.

I'm curious why you bother with (non-EC) DHE at all? Its an interoperability nightmare thanks to the lack of DH param size negotiation in the TLS handshake and all the clients that work with the larger (larger than 1024-bit) DH params also do ECDHE. And at the end of the day, there aren't really that many DHE capable clients that won't do ECDHE. For interoperability reasons I prefer to just keep DHE off and let those rare clients use non-PFS suites.

PS: you're my hero for making this page to begin with. I often direct people to it who ask about SSL settings. Even if I have my own tweaks to the list. Its useful for more than just webservers too.