I have a VPS running Ubuntu 16.04 & Apache, with a multi-site install of WordPress, which uses domain mapping to serve several different websites. I’ve successfully set up the certbot to generate and update the certificate for the primary domain (https://zaneselvans.org/) but have been unable to figure out how to configure Apache to use additional certificates (or the same certificate with additional domains added to it – which is the preferred way to do it?). Because WordPress is redirecting requests internally, there aren’t really separate Apache configuration files into which I can insert a <VirtualHost *:443> directive… at least not that I’ve been able to find.
Right now I’ve got a certificate with the full list of domains on it, and it apparently works, since when I go to one of the other domains that have been mapped (e.g. https://amateurearthling.org/) I get a valid SSL indication from the browser, but a 403: Permission Denied. My guess is that this means the problem is with the permissions/access to the DocumentRoot that’s associated with the secure VirtualHost. But since it’s not clear to me what .htaccess or configuration file is controlling those permissions, I don’t know where to try and give it access. The insecure versions of the mapped domains work just fine – but really I want to force HTTPS on all of them.
I realize this is more of an Apache/WordPress configuration issue… but I’m hoping someone here has come across it already and there’s an easy fix that I’m just doing a bad job of searching for. Thanks for all your work on making encryption of the web ubiquitous!
Have a look into the Apache error logfiles. You may look into the main configuration file to get the correct location, but in most cases it will be /var/log/apache/error.log or /var/log/httpd-error.log.
Looking at the logs, I see that permission was denied because of the configuration of permissions on the directory which is the DocumentRoot of the main site (the top level WordPress install directory), but because there aren’t any directives (that I know where to find) specifically configuring the treatment of that directory when it’s being accessed via a request to another domain which is also being managed by WordPress, I don’t know where to go to set the appropriate directory permissions.
If this DocumentRoot gets already delivered via another VirtualHost, filesystem permissions are most likely not the problem, since then every access to that directory from other virtual hosts would fail, too.
Look in the virtual host which serves right and try to find a block where the statement Require all granted or Allow from all is mentioned.
E.g.:
<Directory /path/to/documenroot/>
Allow from all
</Directory>
This must then be either copied to the other virtual hosts or defined globally outside of the scope of any VirtualHost statement.
If I knew where the VirutualHost directives controlling the Apache SSL servers that are hosted as WordPress multi-sites were, I could make these changes. But because WordPress deals with the site-based redirects internally, rather than Apache dealing with them (at least, so far as I can tell), it’s not clear to me where these kinds of permissions are being specified. Setting lax access permissions globally seems like a bad idea.
Did you use certbot --apache to automatically configure HTTPS with Apache for you or did you do something else?
If you look in /etc/apache2/sites-enabled, do you see two files for each domain (SSL and non-SSL), or do you see one non-SSL entry and a bunch of a SSL entries, or perhaps some other configuration?
I’m not 100% sure, but I believe I did use certbot --apache to do the configuration. When I look in the sites-enabled directory I see only two configuration files. One SSL and one non-SSL for the main domain associated with my multi-site WP install. And for that domain alone, SSL works fine. I tried creating .conf files for the other domains, and then creating individual SSL certificates for those domains rather than putting several on the same certificate, and was able to generate configuration files for SSL sites in the sites-available and then sites-enabled directories, but none of those configuration files seem to be what the server is using to determine the behavior of those domains. I can delete them all with no effect – some other internal WordPress redirect and domain mapping configuration appears to take precedence, and I don’t know how to affect it.
For whatever magical reason, upon updating to WordPress 4.9, the SSL versions of all these additional domain-based WP sites now appear to be working, so I’ve gone ahead and set WP up to force SSL connections for both admin and the public facing sites, and used some plugins to clean-up mixed content errors. So, whatever the difficulty was, it appears to have been addressed, and all the sites are now secured, and seem to pass external SSL validation tests with flying colors.
I am still curious whether the preferred usage is to put all of the domains being hosted on the server inside a single certificate, or whether it would be preferable for each domain to have its own separate certificate with only that domain (and any aliases like www.*) listed on it. But given that this is a homebrew server, without any clear “ownership” of the sites really being asserted this seems like a secondary concern.
Thanks to everyone who responded! I wish I understood what had changed, but am happy not to have to think about this any more at the moment.
The insecure versions of the mapped domains work just fine – but really I want to force HTTPS on all of them.