Wildcard security via Symlinks

This topic is part of research I am doing to help determine the best solution for my client’s needs.

Scenario:

Client’s flagship Joomla 3.9.12 site on a Plesk server: OURDOMAIN.ORG

Client’s Joomla 3.9.12 Multisite on a cPanel/WHM server: OURDOMAIN.NET

Goal: To rebrand all of of the OURDOMAIN.NET slave sites with the subdomain URL SLAVE1.OURDOMAIN.ORG, SLAVE2.OURDOMAIN.ORG, etc. There are about 26 slave sites.

Question: If we migrate the OURDOMAIN.NET multisite platform over to the same Plesk server as OURDOMAIN.ORG, I’m told that there is a way to configure the Joomla Multisites system to resolve to the SLAVE1.OURDOMAIN.ORG urls. I’m wondering whether a wildcard SSL for *.OURDOMAIN.ORG would secure the slave URLs which are technically under another Plesk subscription — assuming of course, that they resolve? Would it trigger the browser lock icon?

We could of course, extract all of the slave sites out of the multisite platform and make them true subdomains, but that is looking like it would be quite expensive.

Hi @Azurelink,

Are you talking about an application-layer HTTP 301 redirect, or a DNS CNAME record, or some other method?

If you use the HTTP 301 method, the browser will make a new, separate connection to the indicated address. The new connection’s certificate will be checked against the name of the target domain, not the original domain. The target domain will be shown in the address bar.

A certificate for *.ourdomain.org is valid for slave1.ourdomain.org, so if the server for slave1.ourdomain.org is properly configured to present that wildcard certificate, browsers will accept it for slave1.ourdomain.org.

You still need the certificates for the ourdomain.net server in order for it to be allowed to send the 301 redirects. If a visitor types in an ourdomain.net URL, the browser will connect to that server and validate its certificate first, and only then, on receiving the 301 redirect, will the browser begin to connect to the ourdomain.org URL and validate its certificate. For users who start with the old name or old links, the process will only be completed properly if both certificates are valid and are properly installed and served on their respective servers.

Hey Schoen, thanks for your reply. I’m not precisely sure how the Multisites component is accomplishing the redirect. But it may ultimately be generating a 301. FYI, each slave has a configuration settings page and you can type in a series of URLs related to the slave and it does the rest, e.g., http://www.oursite.org, https://www.oursite.org, http://slave1.oursite.org etc, and we plan to add slave1.ourdomain.org to the list as the first item used.
Good point about the certificate for the ourdomain.net server.

You could check this kind of detail with the command-line program curl, or with your web browser’s web developer tools (usually available by pressing F12). This provides a huge set of resources for better understanding what’s happening between a web server and a web browser when you load a particular page.