Outdated SSL/TLS Features

Will you be enabling support for complete certificate chains? I believe this requires httpd 2.4.8 which may have to wait for an upgrade to RHEL 7. Systems probably shouldn’t be using incomplete chains because user agents will think the certificate authority is invalid if they don’t have the intermediate certificates cached.

In the interim do you have the ability to remove support for ciphers which have been considered weak for a while?

A list of the affected TLS 1.2 ciphers follows:


All TLS 1.1 ciphers are affected.

The cipher changes will affect the following user agents:

  • Android 4.3 (last update 2012, EOL)
  • Chrome 29 (last update 2013, EOL)
  • Firefox 26 (last update 2013, EOL)
  • Internet Explorer 10 (last update 2016, EOL January 2020)
  • Java 6u45, 7u25 (last updates 2013 and 2015 respectively, both EOL)
  • OpenSSL 0.9.8y (last update 2015, EOL)
  • Safari 6.0 (last update 2013, EOL)

I’m not sure about the CA chain support. To my knowledge, there are no plans to add support for this on free hosting.

I’m not also not sure why you say we need a certain version of Apache for that. We use NGINX for the SSL termination, which already supports combined certificates/CA chains. And Apache could work too if we added a separate field to add the CA chain.

That said, most modern browsers accept certificates without CA chains without any problems. So there isn’t an urgent need to add support for this.

That said, removing the weak ciphers is probably a good idea. I’m going to double check the list and then pass it on to update on the hosting servers.


It is also a requirement for HSTS.

I’m sorry, but do you have any documents to confirm this?

To my knowledge, HSTS and the SSL connection itself have very little in common. HSTS just makes sure that encrypted connections are enforced. It doesn’t actually say anything about the nature of the SSL certificates.


Kind of. HSTS attempts to enforce secure connections for clients that attempt to request a resource over an insecure connection.

This doesn’t work if the client has never visited the site before and an attacker intercepts the connection to remove the header. It also doesn’t work if the client has visited the site before but the HSTS header expires before a subsequent visit.

HSTS preloading prevents this attack and the only service provider that will load small websites into its preload requires fullchain. What I said before was an over-simplification because preloading isn’t mandatory to implement HSTS but from a practical perspective preloading is pretty important. Without preloading I believe a permanent redirect to HTTPS is basically as secure as HSTS since it serves a similar functionality with the same vulnerability.

See HSTS and Let's Encrypt - Web Performance Consulting | TimKadlec.com for a more expanded description of the attack and how HSTS preloading prevents it.

I see what you mean now. If all the available HSTS preloading lists require a full CA chain, then that would be a limitation.

While I do believe the ability to add free hosting sites to HSTS preloading lists would be a good feature to have, I would say it’s quite a niche feature. I’m not sure how many people know about HSTS preloading (I didn’t either until this thread), and care enough to want this on their free website. So this isn’t a high priority feature. Free SSL for subdomains and fully automatic SSL are more important to us right now than HSTS preloading support.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.