@jamesburns77

One of the most common issues when it comes to Apache + .htaccess files is an extra space, line or a simple misconfiguration. This can sometimes happen even when you don’t touch the file.

My first recommendation would be to simply delete your .htaccess file, login to ./wp-admin, browse over to the Permalinks section and simply click “Save.” This should generate a new file for you which should be valid. Sometimes that’s all it takes.

If that doesn’t work, then the best course of action would be to post your configuration so we can look at it in detail. You can enclose it in a code block by using three backticks, hitting enter, pasting in your configuration, then closing the code block with three more backticks.

@jamesburns77

Unless you’ve modified apache2.conf, then we shouldn’t need to venture there, however, posting the contents of both 000-default-ssl.conf and default-ssl.conf would be helpful so we can take a closer look at the full configuration.

As for your .htaccess file, I would keep it as basic as possible and stick to the plain-jane default that WordPress uses until we figure out what’s going on.

The most basic/default would be something such as:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

By default, if you set the WordPress URL’s to use https:// then you shouldn’t need to rewrite them, which is why I recommend using the stock .htaccess over anything else right now.

@jamesburns77

To help expedite this so we can get this resolved for you, I just deployed a one-click image for WP to pull the configuration directly.

So let’s get started :-).

I’m going to run through the steps again in this reply so we can better troubleshoot the issue as we go along. This allows provides a reference point for you to use in the future, should you need to.

…

To start, I’ve ran:

sudo apt-get update

sudo apt-get -y upgrade

sudo apt-get -y install python-letsencrypt-apache

Ubuntu is now updated, all packages that need to be are upgraded, and LetsEncrypt is installed. Now before I run LetsEcrypt, let’s take a look at my domain’s configuration file.

I’ve added ServerName and ServerAlias to match both versions of my domain. Those are the only changes I’ve made and they exist on the 4th and 5th lines of the following VirtualHost block.

The contents of 000-default.conf are:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ServerName mydomain.com
        ServerAlias www.mydomain.com

        <Directory /var/www/html/>
            Options FollowSymLinks
            AllowOverride All
            Require all granted
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

The reason I did this is because LetsEncrypt tries to search for the domain you’re trying to secure, so this makes it a little easier as it will automatically find that this configuration file is associated with my domain, so it’s the right one to use.

Now we’ll run LetsEncrypt to generate an SSL Certificate for my domain.

sudo letsencrypt --apache -d mydomain.com -d www.mydomain.com

After entering my e-mail and accepting the terms of service, I’ll be asked:

Please choose whether HTTPS access is required or optional

Since I want HTTPS to be global, I’ll choose:

Secure Make all requests redirect to secure HTTPS access

Once the above option is chosen, LetsEncrypt reports success, apache2 is automatically restarted and SSL now works without having to do anything further.

…

Now, here’s the contents of my configuration files for reference.

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ServerName mydomain.com
        ServerAlias www.mydomain.com

        <Directory /var/www/html/>
            Options FollowSymLinks
            AllowOverride All
            Require all granted
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        RewriteEngine on
        RewriteCond %{SERVER_NAME} =mydomain.com [OR]
        RewriteCond %{SERVER_NAME} =www.mydomain.com
        RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
</VirtualHost>

/var/www/html/.htaccess

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

…

If you compare yours the the above, we should be able to figure out what’s going on :-).

…just to mention this to exclude it from possible issues:

I see that the original poster tried chmod, but did not chown the .htacess. Sometimes a person will login as a user and create website files (like an .htaccess) and forget to change the owner (chown) back to www-data.

sudo chown -R www-data:www-data /var/www/html
sudo chmod 740 /var/www/html/.htaccess

probably not a good idea to make your .htaccess 666, since that is the mark of the devil

Nice, an incrementally built walkthrough, I get to learn how this beast actually works and the rest of the community get a reference point going forward!!:)

Learning started already, with ‘plain’ permalinks, my /var/www/.htaccess is essentially blank with only a # BEGIN WordPress and # END WordPress whereas when I flick 'post name’ on as my permalink structure, .htaccess is dynamically updated - cool!

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

So think we are good on .htaccess - a now much cleaner version than my original thankfully! Great to know most of that additional config is redundant - less is more!:)

Onto my /etc/apache2/sites-available/000-default.conf file. My full virtual host data looks pretty similar with the exception I extended the number of server aliases to deal with the additional domains I have re-directed to my primary domain. For context, my primary domain is wealth-hack.com but I have a series of secondary domains (wealth-hack.co, wealth-hacker.com etc) that re-direct to wealth-hack.com using cname aliases (configured within networking section of DigitalOceans domain config utility).

<VirtualHost *:80>
        ServerAdmin james@wealth-hack.com
        ServerName wealth-hack.com
        ServerAlias www.wealth-hack.com *. wealth-hack.co *.wealth-hack.us *.wealth-hacker.co *.wealth-hacker.com *.wealth-hacker.us
        DocumentRoot /var/www/html

        <Directory /var/www/html/>
            Options FollowSymLinks
            AllowOverride All
            Order allow,deny
            allow from all
            Require all granted
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =wealth-hack.com [OR]
RewriteCond %{SERVER_NAME} =www.wealth-hack.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
</VirtualHost>

The aliases are the only thing that looks different. In the spirit of education, I took a backup of 000-default.conf then edited the live version to remove all the additional aliases except for the standard www.wealth-hack.com to align the files. No change to the issue but as expected, if I type www.wealth-hacker.com it no longer gracefully changes the URL to https://wealth-hack.com.

Could it be my default-ssl.conf that is creating the issue??

@hansen @jtittle - ‘Really Simple SSL’ de-activated and nothing broke (another thing I didn’t need)!:) However, didn’t remove the issue.

For full disclosure, I also have SSL Insecure Content Fixer running at 'capture’ level as this was required to allow my site to consistently display 'secure’ green ticks etc when moving to https. Again, to learn if this impacts anything, I deactivated it (knowing this would cause the site to move to 'unsecure’) to see if the root cause disappeared, no joy. Subsequently, reactivated, I like my reassuring green tick.

Hi @sierracircle, thanks for the extra advice, I’ve followed your steps but same outcome.

Where next with our precision mallet all??;)

Can you change permalink structure to ‘post name’ and leave it on for a bit so we can see it behave?

Also, when in Settings>Permalink , after you make the changes, push the save button an extra time. (I think Wordpress fixed this, but there used to be an issue where you had to save twice to activate permalink changes)

@jamesburns77

A file called 000-default-le-ssl.conf should have been created when LE ran, which would physically be located in ./sites-available and symlinked to ./sites-enabled.

That file should look like:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ServerName domain.com
        ServerAlias www.domain.com

        <Directory /var/www/html/>
            Options FollowSymLinks
            AllowOverride All
            Require all granted
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

If you don’t have that file, or are using another file, the configuration should look identical to the one I posted above. That’s verbatim from my one-click.

Hi @hansen - consider it de-activated. The site will look a bit goofier now but good to keep this as simple as we can to get it working. For info, I did search and replace + better search and replace before turning to SSL Insecure Content Fixer, didn’t seem to work for me then. I’ll hold of re-running just now as the dry run indicates the premium theme I purchased and installed has 1000+ http:// to convert to https://, don’t want to change too much at the same time (unless we think this is related).

@hansen + @sierracircle, also done, the site has no SSL type plugins running and is set to ‘post name’ (with a double save just incase)!:)

@jtittle the plot thickens, another conf file to consider!

Ok, in my/.sites-available dir, I have two ssl type files, default-ssl.conf(which I knew about and mentioned in the first post above) and default-ssl.conf.save which I haven’t spotted before.

default-ssl.conf.save has very similar to what you stated above

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerAdmin james@wealth-hack.com
                ServerName wealth-hack.com
                ServerAlias www.wealth-hack.com
                DocumentRoot /var/www/html

<Directory /var/www/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
</Directory>

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined
                SSLCertificateFile      /etc/letsencrypt/live/wealth-hack.com/fullchain.pem
                SSLCertificateKeyFile /etc/letsencrypt/live/wealth-hack.com/privkey.pem

There is a lot more text but almost all of it is commented out. I don’t have the Include /etc/letsencrypt/options-ssl-apache.conf within the file however.

default-ssl.conf is the same (no Include /etc/letsencrypt/options-ssl-apache.conf) but it also doesn’t have the following:

<Directory /var/www/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
</Directory>

Breaking news, I think that was it! I added the config just referred to into default-ssl.conf and the post name permalinked URL’s are now functioning!!:) I’ll get back onto my find and replace to get secure back and I’ll be fully working once again:):):)

So many thanks to @jtittle @hansen and @sierracircle for guiding me through this. Hopefully, the documentation chain above was good enough for other newbies like me to help them in the future. Loving being part of the DO community, will keep working hard and one day, I might be able to help others:)