• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Quick Preview failing due to HTTP/2 (HSTS)

websavers

Regular Pleskian
After enabling HTTP/2 on a server, quick previews fail to function. This is because HTTP/2 requires a TLS channel, thus enforcing HSTS. However the Quick Preview URL does not present a matching certificate, so the TLS connection fails in most modern browsers that try to negotiate over https.

We're using quick preview on a domain. It's set up as an external domain, but it actually matches the server hostname.

There are two possible solutions to this that I can think of:

1. Plesk could include the following to disable HSTS:

add_header Strict-Transport-Security "max-age=0";

It would probably be best to wrap that in a conditional that checks to see if the request hostname contains the quick preview URL.

2. Plesk could fix this by using the right certificate

It would be great if the Website Preview feature could opt to work on the server hostname, then automatically apply the SSL certificate used to secure the panel to all preview URLs.

There's one other issue with this, and that is that the preview URL contains too many '.' chars, meaning most wildcard SSL certificates will not apply to it. I suggest a slight change in the preview URL format from this:

domain.tld.149-*-*-*.[preview_domain]

To this:

domain-tld-149-*-*-*-[preview_domain]

This way it becomes a subdomain of the hostname's primary domain, thusly applying to any wildcard certs used to secure the panel.
 
I cannot confirm that. What exactly do you mean by "previews fail to function", what is happening when you open the preview URL? Do you see an error message, which one? What is logged in /var/log/httpd/error_log?
 
Hey Peter,

Make sure HTTP/2 is enabled on the server where this is being tested. Configure the Website Preview to work on the server's hostname, configure the site to work over HTTPS, then visit the preview URL for the domain in Firefox 50.1.0 (current release ver) or Safari 10.0.3 Tech Preview (which finally has HSTS enforcement).

When I visit the preview URL with those browsers, I get a security warning indicating that the site is not secured:

"This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely. As a result, it is not possible to add an exception for this certificate."

Obviously we could disable HTTPS, but then you've got plaintext WordPress logins happening during development, which is definitely not preferred.

Thoughts?
 
I still cannot reproduce it:
- HTTP/2 active
- Website preview on server's hostname (like https://mytest.tld.123-156-178-101.myhost.tld/)
- Open it on Firefox latest release

Security warning: Yes. That must be there, because the browser cannot recognize a correct certificate. That's a must and it is correct that this warning appears.

But HSTS: No. Not required.

According to https://plesk.uservoice.com/forums/...port-for-http-strickt-transport-security-hsts HSTS has not been implemented yet anyway. Could it be possible that in your specific environment you did implement it yourself, e.g. by extra Nginx or Apache directives?
 
Peter,

My apologies, you're absolutely right. The HSTS header we were using on our primary domain had the IncludeSubdomains directive snuck in there (it was borrowed from other code). I hadn't thought to look there as I was under the impression that HSTS had to be specified on a per subdomain basis; apparently it can be controlled from just the parent domain.

So if anyone else runs into this issue, it's because you've got an HSTS header configured on your second level domain (such as myhost.tld) which is affecting all subdomains because of that IncludeSubdomains portion of the header. Remove IncludeSubdomains from it and you should be all set. (Might need a browser cache clearing afterward).

-Jordan
 
Back
Top