Issue Redirect from example2.com:8443 to FQDN hostname server.example.com:8443 fails

[LightDot]

Hi everybody!

I'm configuring a new Plesk 17.8 server on CentOS 7 and need some assistance.

Let's say there is one hosted domain on the server, example2.com. The server has a FQDN hostname server.example.com and is secured with a Let's Encrypt certificate, set to be used for the Plesk interface. I can access Plesk without issues.

According to this article: How-to-redirect-from-the-domain-to-the-server-hostname-on-port-8443 adding this into /etc/sw-cp-server/conf.d/plesk.conf (within the server directive):

set $test "0";
if ( $host = '$hostname' ) {
set $test "1";
}
if ( $test = "0" ) {
rewrite ^/(.*)$ https://$hostname:8443/$1 permanent;
}

and than restarting the services:

systemctl restart sw-cp-server.service
systemctl restart sw-engine.service

should do the trick.

But it doesn't work for me! If I visit Plesk using https://example2.com:8443, there is no redirect, as if nothing has changed. I get a certificate warning, as expected, the certificate shown correctly belongs to server.example.com.

If I visit Plesk using https://server.example.com:8443, I get a redirect to https://server:8443 and a also certificate warning!

"hostname -f" returns "server.example.com", "hostname -a" returns "server". But shouldn't the $hostname variable in nginx contain the full hostname??

Can't really make out what's going on.

BTW, I also tried simply:

if ( $host != $hostname ) {
rewrite ^/(.*)$ https://$hostname:8443/$1 permanent;
}

with the same result.

Any ideas?? Perhaps it's something trivial and I'm just not seeing it?

 

[learning_curve]

@LightDot The code addition and steps that you've posted (taken from the Plesk article) definately do work, as you've read pretty recently in another forum post and we can also confirm that they work for us FWIW So it's more than likely... to be just a typo / slight misconfiguration elsewhere within Plesk. Two quick initial checks:

Is the entry that's currently in here: Plesk Panel / ~ / Tools & Settings / Server Setttings / Full hostname * server.example.com ? << Exactly this, we mean? (You can check this pretty quickly on here anyway: Plesk Panel / ~ admin/home?context=home page as the hostname is shown) If not, what is it?

Is this ^^ server.example.com (your FQDN) i.e. the one you're using as the hostname within Plesk, the exact same name of your physical hosting Shared Space / VPS / Cloud / Dedicated Server too (we're not sure which setup you have yet ?

You already understand the certificate warnings, but that's not the issue you're concerned about now, really & they will be non-visible once the typo / misconfiguration is solved anyway

 

[LightDot]

Thanks for helping!

Well, everything looks right to me (redacted of course, just to mention so that someone won't think otherwise, hah):

# hostname -f
server.example.com

# hostname -d
example.com

# hostname -a
server

# grep hosts /etc/nsswitch.conf
hosts:      files dns

# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost localhost4.localdomain4 localhost4
# Auto-generated hostname. Please do not remove this comment.
xxx.xxx.xxx.xxx server.example.com  server
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

The full hostname in Plesk under the Tools & Settings / General Settings / Server Settings / Full hostname is exactly the same, server.example.com. I have double double checked...

If it's of any help, this is an OpenVZ 6 VM on our colocated server, the full hostname of the VM instance and the full hostname as configured in Plesk haven't been altered since Plesk was installed. Both the OS (CentOS 7) and Plesk are fully updated (17.8.11 Update #51).

 

[learning_curve]

Well, everything looks right to me (redacted of course, just to mention so that someone won't think otherwise, hah)

The full hostname in Plesk under the Tools & Settings / General Settings / Server Settings / Full hostname is exactly the same, server.example.com. I have double double checked...

Shame, as that would have been the simplest (and quite common) error to quickly rectify The code data you've posted looks okay. Your # cat /etc/hosts results are obviously quite different than ours (because your complete server setup is...) and our only question, is about the no IPv6 reference data being shown there... Maybe you're not using IPv6 currently?

If it's of any help, this is an OpenVZ 6 VM on our colocated server, the full hostname of the VM instance and the full hostname as configured in Plesk haven't been altered since Plesk was installed. Both the OS (CentOS 7) and Plesk are fully updated (17.8.11 Update #51)

From this, it appears that the hostname of your OpenVZ based server is server.example.com as well then? (Out of interest for e-mail etc is the hostname reverse DNS / PTR record correct too?) Assuming that IS all correct, then the next possibility is a typo (unlikley) in your /etc/sw-cp-server/conf.d/plesk.conf file (you could post the complete file content on here FWIW)

If it's not that, and... assuming that you have no contradictory .htaccess files anywhere else then it's possibly time to examine in detail, your DNS setup, as that might be an important factor for all those failing re-directs

 

[Ales]

@LightDot, do you have any other Plesk admin server customizations, anything relevant in the /usr/local/psa/admin/conf/panel.ini ?

 

[LightDot]

No IPv6 on this server, correct.

The hostname of the physical host is different than the hostname of the Plesk VM, but that's to be expected. It would make no sense to have same hostnames on what are basically two different servers (albeit one of them is virtualized).

PTRs are set, A records normally resolvable, plesk.conf is completely stock, apart from the redirection attempt (which has now been removed again).

I don't think .htaccess files would have any effect even if there would be any (and there are none) added to it, as Plesk admin server is nginx.

@Ales, thanks for helping.

I have customized the TLS/SSL settings for the admin server and there are some modifications to the panel.ini.

Two of the settings from the panel.ini struck me as possible culprits but I have already tried with them commented out, without any change.

Modified /etc/sw-cp-server/conf.d/ssl.conf:

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_dhparam /etc/sw-cp-server/cert_dhparam_4096.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/sw-cp-server/cert_lets-encrypt-x3-cross-signed.pem;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Modified /usr/local/psa/admin/conf/panel.ini (I have tried without the sameOriginOnly and without the trustedRedirectHosts):

[promos]

; Disable other products promotions
enabled = off

[facebook]

; Hide Like link
showLikeLink = off

[rating]

; Hide feedback dialog with question to rate product
enabled = off

[security]

; Protect from overlay attacks, blocks opening Plesk interface in 3rd party iframes
sameOriginOnly = on
; Mitigate URL redirection vulnerability
trustedRedirectHosts = server.example.com

[ext-catalog]

; Hide extension promotions
contextAds = off

[ext-letsencrypt]

rsa-key-size = 4096
; Log Let's Encrypt requests into /var/log/plesk/panel.log
log-requests = on

BTW, do any of you have the sameOriginOnly and trustedRedirectHosts set?

 

[learning_curve]

@LightDot FWIW

...It would make no sense to have same hostnames on what are basically two different servers (albeit one of them is virtualized)

In your case / setup choice, then possibly yes.
In our case / setup choice, then no, as it makes perfect sense and is very easy to both administer and achieve

I don't think .htaccess files would have any effect even if there would be any (and there are none) added to it, as Plesk admin server is nginx.

Errrrrr Yes and No Yes, you're absolutely correct. Plesk Admin is where the problem currently appears to be and Plesk Admin is presented using Nginx ONLY, but it's a different Nginx than the host domain itself runs on. So... did you mean that the host domain is also Nginx ONLY (i.e. Apache is NOT in use at all) or, is the host domain using Nginx in Proxy mode, in which case, if... some random .htaccess files had existed, it's unlikely, but they could still possibly have had an effect (depending on the specific setup that was in use). As it happens, you don't have any .htaccess files in use anywhere, anyway, it appears, so it doesn't matter in this case.

~ I have customized the TLS/SSL settings for the admin server ~ Modified /etc/sw-cp-server/conf.d/ssl.conf

For comparative use, an example etc/sw-cp-server/conf.d/ssl.conf that we are currently using, is shown below. Some different options as you can see, but it's pretty similar to your own. However, as you know, we do have sucessful :8443 re-directs, using the exact same code that you tried to use before. So... we'd guess that this etc/sw-cp-server/conf.d/ssl.conf file doesn't appear to be related to the re-direct problem that you're experiencing.

# SSL Sessions
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

#SSL ECDH Curve
ssl_ecdh_curve X25519:secp521r1:secp384r1:prime256v1;
              
# SSL Protocol
ssl_protocols TLSv1.2;

#SSL DHParam
ssl_dhparam /etc/ssl/certs/dhparam.pem;

# SSL Ciphers
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
ssl_prefer_server_ciphers on;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /opt/psa/var/certificates/*redacted*;
resolver 1.1.1.1 1.0.0.1;

@Ales will no doubt answer your panel.ini questions, we're sure, but again just for comparative reasons, ours is very simple as we use CLI a lot instead, but it's located here: /opt/psa/admin/conf/panel.ini and it comprises of only these changes:

[debug] enabled = false

[ext-letsencrypt]
acme-directory-url = "https://acme-v02.api.letsencrypt.org/directory"
acme-protocol-version = "acme-v02"

[ext-catalog]
quickAccessContextAds = false

[api]
enabled = off

Finally, are you going to post your /etc/sw-cp-server/conf.d/plesk.conf file just to rule out any (unlikley) typos in that before moving on?

 

[LightDot]

plesk.conf-orig:

server_names_hash_bucket_size  64;

server {
                listen 8443 ssl;
                listen 8880;
                listen 127.0.0.1:8880 default_server;
                include conf.d/*ipv6_ports.inc;


                ssl_certificate /usr/local/psa/admin/conf/httpsd.pem;
                ssl_certificate_key /usr/local/psa/admin/conf/httpsd.pem;

                include conf.d/*plesk.inc;
                include conf.d/*wpb.inc;
}

plesk.conf-new:

server_names_hash_bucket_size  64;

server {
                listen 8443 ssl;
                listen 8880;
                listen 127.0.0.1:8880 default_server;
                include conf.d/*ipv6_ports.inc;


                ssl_certificate /usr/local/psa/admin/conf/httpsd.pem;
                ssl_certificate_key /usr/local/psa/admin/conf/httpsd.pem;

                include conf.d/*plesk.inc;
                include conf.d/*wpb.inc;

                set $test "0";
                if ( $host = '$hostname' ) {
                set $test "1";
                }
                if ( $test = "0" ) {
                rewrite ^/(.*)$ https://$hostname:8443/$1 permanent;
                }
}

plesk.conf-new2:

server_names_hash_bucket_size  64;

server {
                listen 8443 ssl;
                listen 8880;
                listen 127.0.0.1:8880 default_server;
                include conf.d/*ipv6_ports.inc;


                ssl_certificate /usr/local/psa/admin/conf/httpsd.pem;
                ssl_certificate_key /usr/local/psa/admin/conf/httpsd.pem;

                include conf.d/*plesk.inc;
                include conf.d/*wpb.inc;

                if ( $host != $hostname ) {
                rewrite ^/(.*)$ https://$hostname:8443/$1 permanent;
                }

}

 

[learning_curve]

@LightDot Yep, we did say "(unlikely) typos" but always better to double check Your plesk.conf-new ^^ should work perfectly, so we're back to the 'glitch' being located elsewhere Previously, the next thing we'd suggested was "...to examine in detail, your DNS setup " but before you do, do you have a Plesk subscription? If you don't, it's very quick, easy (and VFM) to take one on. They are quick at solving issues like this, especially when it's related to Plesk Admin itself. That would save you a lot of time and effort, plus we're all curious now as to exactly what is causing the issue!

 

[TomBoB]

I'm configuring a new Plesk 17.8

but the procedure you're following as per article How to redirect from the domain or IP address to the server hostname on port 8443? is for Plesk 12.5 and below.

Next, the article is somewhat confusing. It actually only discribes the redirect of http [non-secure] connections to example2.com:8443 to the servers https fqdn at https://server.example.com:8443

To the best of my knowledge, - having the server secured with lets encrypt - it is not possible to have a https connection to example2.com:8443 redirected to the servers fqdn https://server.example.com:8443 simply for the fact that the security check of the cert to example2.com (or any client domain for that matter) always happens befiore any redirect can possibly take place.
You would have to secure your server with a SAN certificate that includes the clients example2.com to make that work.

But as no-one is perfect, I gladly stand to be corrected! Faced the same issue as well.

 

[learning_curve]

but the procedure you're following as per article How to redirect from the domain or IP address to the server hostname on port 8443? is for Plesk 12.5 and below. Next, the article is somewhat confusing. It actually only discribes the redirect of http [non-secure] connections to example2.com:8443 to the servers https fqdn at https://server.example.com:8443 To the best of my knowledge, - having the server secured with lets encrypt - it is not possible to have a https connection to example2.com:8443 redirected to the servers fqdn https://server.example.com:8443 simply for the fact that the security check of the cert to example2.com (or any client domain for that matter) always happens befiore any redirect can possibly take place.
You would have to secure your server with a SAN certificate that includes the clients example2.com to make that work. But as no-one is perfect, I gladly stand to be corrected! Faced the same issue as well.

Good Point. Well made! That's with respect to all of those ^^ notes @TomBoB and that's the missing answer

I had forgotten that we had discussed this before, in this old thread HERE specifically, in posts #6 and #7

As was the case back then (and as is still the case now) all the security checks are passed (and thus all :8443 re-directs are successful...) in our case, due to... the Multi-Domain *Wildcard Let's Encrypt Certificate that we use. IN this case, this is effectively the "SAN" that you have mentioned in your post, but, it's a Let's Encrypt Certificate, so it's free An equivalent success criteria can NOT be achieved, unless an equivalent certificate is used, for the very reasons you've mentioned.

In that old thread, neither of us actually mentioned the fine details of the security reason, that you've now helpfully provided above, even though, it was still just as 100% valid back then. In our case, simply because it didn't / doesn't apply and... we hadn't actually tried, without a "SAN" certificte already being in place. In your case, you already knew the specifics of the security failure reasons, but, at that point in time, we don't think you had actually tried the the Multi-Domain *Wildcard Let's Encrypt Certificate option that we were/are using, due to, our different server setups etc. Regardless, your post is still THE answer to this specific problem, we're pretty sure.

Re: the Plesk 12.5 and below reference. We didn't use Plesk prior to Onyx, so have no input on what works or worked on any earlier Plesk releases. However, it does work on later Plesk releases (as we know) but only IF the correct specification certificate is already in place. So you're right again, but that's ^^ the point that's effectively missing from that Plesk article.

Finally and just FWIW, IF you wanted to re-direct your server IP:8443 to https://hostname.tld:8443 (say for access security etc) you can also do this. We asked Plesk this question and they gave us a conplete answer (shown below) As no certificate can cover an IP Address (we think...) using this still gives an initial browser certificate security warning but, if you accept that and continue, the re-direct is always completed. It works perfectly, every time for us and in this case, no "SAN" is required

You can redirect all connections ip:8443 to a specific address
e.g: https://hostname.tld:8443 by following the process below:

- Connect to the server over SSH.
- Create file /etc/sw-cp-server/conf.d/z-plesk.inc
- Add the following rewrite rule in the created file:

if ($host ~ '123.12.3.123'){
rewrite ^/(.*)$ https://hostname.tld:8443/$1 permanent;
}

Restart sw-cp-server service:

# service sw-cp-server restart

Where the example 123.12.3.123 is replaced by the real IP Addess

 

[TomBoB]

I had forgotten that we had discussed this before, in this old thread HERE specifically, in posts #6 and #7

@
learning_curve good memory! had forgotten about that too

 

[LightDot]

but the procedure you're following as per article How to redirect from the domain or IP address to the server hostname on port 8443? is for Plesk 12.5 and below.

Where does it say that? I understand the article as if it was consisting of three parts: the first "For Plesk 17.0 and higher", the second "For Plesk 12.5 and below" and the third, common to both Plesk 17.0 and up and Plesk 12.5 and below (beginning with "To redirect HTTP and HTTPS requests...").

But the above might be just a moot point, because:

Next, the article is somewhat confusing. It actually only discribes the redirect of http [non-secure] connections to example2.com:8443 to the servers https fqdn at https://server.example.com:8443

To the best of my knowledge, - having the server secured with lets encrypt - it is not possible to have a https connection to example2.com:8443 redirected to the servers fqdn https://server.example.com:8443 simply for the fact that the security check of the cert to example2.com (or any client domain for that matter) always happens befiore any redirect can possibly take place.
You would have to secure your server with a SAN certificate that includes the clients example2.com to make that work.

But as no-one is perfect, I gladly stand to be corrected! Faced the same issue as well.

You might just be right! Thanks for pointing this out! I was looking for errors and configuration issues, instead, I should have been considering the logic behind the approach I was trying.

It seems that I'll have to rethink this completely.

 

[learning_curve]

@LightDot and @TomBoB Update!

We raised a query with Plesk about this and as a result of that query..... they have now updated the article referred to earlier: How to configure a redirect from the domain name/IP address to the server hostname on port 8443? The update also includes a slightly different method / code for re-directing https://example.com:8443 => https://hostname.com:8443 This is similar (but not the same) as one of the options that you had previously tried @LightDot so it may be a solution for you, if, you're willing to accept the certificate warnings and you're not wanting to run a "SAN" certificate (which is still, the only method of seemlessly achieving this at present). The article is somewhat clearer now & self-explanatory.

Finally, an intended future enhancement is covered here: How to secure multiple Plesk login URLs (port 8443) with single SSL certificate on single Plesk server?