I recently set up a web server that—among others—serves ownCloud to some of my users. I got a Let’s Encrypt SSL Certificate because I didn’t want to use a self-signed certificate like the one ownCloud uses out of the box. I configured Apache to rewrite all HTTP traffic to HTTPS correctly.

Now ownCloud shows me a message constantly, asking me to enforce HSTS (HTTP Strict Transport Security). Given that Let’s Encrypt Certificates are only valid for 90 Days and that my HTTP redirection already works, should I really enforce HSTS?

  • 11
    What's your concern with Let's Encrypt certificates as opposed to other CAs?
    – Arminius
    Dec 9, 2016 at 7:15
  • 1
    Test carefully before you do! developers.google.com/web/fundamentals/security/… "Note: max-age is measured in seconds. You can start with low values and gradually increase the max-age as you become more comfortable operating an HTTPS-only site." Dec 9, 2016 at 16:15
  • @Arminius Apparently the short expiration period.
    – user253751
    Dec 10, 2016 at 3:38

3 Answers 3


Yes, you should activate HSTS.

HTTPS without HSTS is significantly weaker since it makes your users vulnerable to downgrade attacks. Sending a HSTS header guarantees that users will directly connect to your website over SSL after their very first visit (trust-on-first-use) and until the specified timeout is reached.

The choice whether to activate HSTS or not doesn't really depend on which CA you're using rather than if you are sure you will continue to support HTTPS in the future. That is, as soon as you disable HTTPS again, any user whose HSTS timeout hasn't expired yet will be unable to connect to your site. If you are unsure about how long you will keep SSL support, you might want to start with short HSTS expiry times to avoid locking out your visitors for too long.

Don't confuse HSTS with HPKP: A HTTP Public Key Pinning header tells the browser to associate a specific public key with your site. Here, pinning for the wrong or expired certificates can make your site unavailable to previous users. But for HSTS, the particular certificate chain doesn't matter and you can change it as needed.

  • 11
    Like you suggested I confused HPKP with HSTS or better said I was misinformed and thought HSTS requiered the same Certificate all the time
    – architekt
    Dec 9, 2016 at 8:03
  • 1
    Just make sure you never mess up renewal after that. Browsers won’t be forgiving in any way if you have HSTS enabled. The only way out is to wait for the HSTS statement to expire in the Browsers cache. You will also be doomed if browsers suddenly decide to not trust your CA anymore; they won’t allow users to add exceptions. Dec 9, 2016 at 17:44
  • 5
    Even key pinning doesn't require you to keep using the same certificate. You can get a new certificate (even from a totally different CA) with an existing key. Dec 9, 2016 at 18:00
  • 1
    Though if you were an idiot and only included keys outside your control in your pin headers then yes you do have a problem. Dec 9, 2016 at 18:01
  • 7
    @JonasWielicki If you mess up certificate renewal for a HSTS site, all you need to do to fix that is to renew properly and install the correct certificate. The point of HSTS is to make the browser unforgiving, not to make the browser hold a grudge.
    – user
    Dec 9, 2016 at 23:37

You can use HSTS as long as you're going to keep using HTTPS on your site. The specific certificate can change, but that is acceptable for HSTS.

If you use HTTP key pinning, you can require that the SSL key comes from a specific CA - in this case, Let's Encrypt - which might cause issues if you changed CA, but the certificate itself can change.

If you implemented a custom pinning method, which looked at specific certificate being used, then you'd have issues. That's not how the standard headers work though.

In short, should be fine with the certificate changing regularly - that's expected behaviour.

  • 5
    Adding to the second paragraph, HPKP referencing the CA is why it's generally recommended to have a backup CA pinned alongside the primary, in case something happens to the primary CA.
    – user
    Dec 9, 2016 at 10:25

Two items - Ensure that you are communicating over HTTPS vs HTTP prior to any authentication. The note on downgrade attacks cannot be must be taken seriously. - Depending on your technology stack, you may need to review more than the code; os networking crypto protocols may need to be checked as well.

There's a great write-up by the folks over at Qualsys

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .