Assume you have a HTTPS server set up with a self-signed certificate or with a certificate signed by a private CA. Moreover assume that the common name in the server's certificate doesn't match the server name used in accessing the server via HTTP/HTTPS (this might be due to DNS problems).

If you try to set "Force HTTPS" in the global configuration to either "Administrator Only" or "Entire Site" you'll get first a message that the configuration was saved successfully, but you also get a warning that the server cannot be reached via HTTPS. The result of this is that "Force HTTPS" is reset to "None".

If the common name in the server's certificate matches the server name used in accessing the server via HTTP you can change the "Force HTTPS" setting at will even if the certificate is self-signed or is signed by a private CA. This is due to the flag CURLOPT_SSL_VERIFYPEER being set to false prior to checking whether a HTTPS connection to the server is possible.

If this is expected behaviour then you should also set the flag CURLOPT_SSL_VERIFYHOST to false such that the certificate's common name is no longer checked against the host name used in accessing the server via HTTPS. This is what this PR does.

The check whether the HTTPS certificate presented by the server is valid is completely delegated to the visitor of the site or the backend. This was already partly the case with the setting of the CURLOPT_SSL_VERIFYPEER flag.

An alternate, more secure approach to this topic would be to add another configuration option which disables the checks of the HTTPS certificate. This configuration option should be shown only when the "Force SSL" option is set to "Administrator Only" or "Entire Site", and it's default value should be "Check Certificate".

Another problem in checking whether HTTPS is available might arise if you have a proxy set in your global configuration (see also PR #11193). In this case that proxy will be contacted in order to access the local server by means of HTTPS which will probably not work.

By setting the flags CURLOPT_PROXY and CURLOPT_PROXYUSERPWD to NULL contacting the proxy server will be disabled.

Test instructions

Please prepare your test environment as follows:

• you need a Joomla installation that can be reached via HTTP and HTTPS (both with default ports)
• the HTTPS certificate can be self-signed, it must contain a common name valid for your server
• your server must be reachable also via any other name (short name without domain, IP address)
• the "Force HTTPS" must be set to "None"
• "Enable Proxy" must be set to "No"
• you do not need a proxy server but if you have one you can use it for your tests
• I assume that no proxy server is running at your server at port 3128, if you have one use a different port below in the proxy server related test cases

Test cases without PR applied:

Test case (1): enable "Force SSL" for the backend via common name

• login to the backend via HTTP using the common name from the HTTPS certificate
• go to "Global Configuration"
• change "Force HTTPS" to "Administrator Only" and save settings
• you should get a message saying that saving the configuration was successful
• check that "Force HTTPS" is set to "Administrator Only"
• check that you have been switched to HTTPS automatically
• change "Force HTTPS" to "None" and save settings
• logout from the backend

Test case (2): enable "Force SSL" for the backend via any alternate name

• login to the backend via HTTP using any other name or the server's IP address
• go to "Global Configuration"
• change "Force HTTPS" to "Administrator Only" and save settings
• you should get a message saying that saving the configuration was successful
• you should also get a message saying that activating HTTPS is not possible since your server doesn't support HTTPS
• check that "Force HTTPS" is set to "None"
• logout from the backend

Test case (3): enable "Force SSL" for the backend with a proxy being set

• login to the backend via HTTP using the common name from the HTTPS certificate
• go to "Global Configuration"
• set "Enable Proxy" to "yes", set "Proxy Host" to "127.0.0.1" and set "Proxy Port" to "3128"
• save settings, check afterwards that the proxy is enabled in the global configuration
• change "Force HTTPS" to "Administrator Only" and save settings
• you should get a message saying that saving the configuration was successful
• you should also get a message saying that activating HTTPS is not possible since your server doesn't support HTTPS
• check that "Force HTTPS" is set to "None"
• set "Enable Proxy" to "no" and save settings
• logout from the backend

Apply the patch, then repeat the above test cases:

Test case (1): enable "Force SSL" for the backend via common name

• this test case should work as described above

Test case (2): enable "Force SSL" for the backend via any alternate name

• this test case should now work as well, there should be no difference to the first test case
• please change "Force HTTPS" to "None" and save settings afterwards, then logout for the next test case

Test case (3): enable "Force SSL" for the backend with a proxy being set

• login to the backend via HTTP using the common name from the HTTPS certificate
• go to "Global Configuration"
• set "Enable Proxy" to "yes", set "Proxy Host" to "127.0.0.1" and set "Proxy Port" to "3128"
• save settings, check afterwards that the proxy is enabled in the global configuration
• change "Force HTTPS" to "Administrator Only" and save settings
• you should get a message saying that saving the configuration was successful
• check that "Force HTTPS" is set to "Administrator Only"
• check that you have been switched to HTTPS automatically
• change "Force HTTPS" to "None" and save settings
• set "Enable Proxy" to "no" and save settings
• logout from the backend