Categories
Interesting Stuff Security Sys Admin Web Apps

Chrome 70 vs Symantec Certificates

Chrome 70 is about to dis-trust a whole lot of certificates

So you paid lots of money for a “proper” certificate for your HTTPS website after Google gave non-HTTPS sites a hard time? Well, hopefully you aren’t still using an older Symantec issued certificate as Google (and others) is about to stop trusting those certificates.

Chrome version 70 is due for release in September for beta users and will NOT trust certificates issued before December 1 2017 from Symantec, Thawte, GeoTrust and RapidSSL.

This is obviously a big deal and as the Chrome browser release happens before your 12 month (or longer) cert will expire, means there’s work to do. While you’re revisiting the process of procuring another certificate, perhaps also have a think about why you might not be using the free service from Let’s Encrypt. That’s good enough for most websites unless you’re after one of the more fancy looking icons to show up in the browser for things like shopping carts.

Why is this happening?

The Certificate Authorities (aka CAs like Symantec) that are used to issue certificates that secure our web browser traffic MUST be absolutely trusted. Without that trust, the process fails and we might as well just create our own certificates. The reason why we don’t do that is that the browser vendors effectively have a list of those highly trusted CAs and each site’s cert must have a mathematical relationship to one of those.

In 2017 a number of issues were raised about how Symantec had been running one of their CAs (they have a few). Inconsistencies and bad-practice were highlighted such that both Mozilla (who have a list of the issues) and Google decided to implement a change in trust of certs issued by that CA.

Categories
Blogging How-To Sys Admin

WordPress Permalink 404 with HTTPS

The time had come to switch this blog to HTTPS given the ease and cost ($0) of deploying certificates from LetsEncrypt. So that was easily done under Apache – create a new conf file for the SSL site in /etc/apache2/sites-available, and then update the old conf for the non-SSL site to redirect before requesting a new cert using certbot-auto -d mike.mcmurray.co.nz –apache. WP handled that just fine but only the admin pages and the main home page displayed as expected, other pages were just a 404.

So I made the .htaccess file writable by WP and updated the permalink rules from the WP admin console to have the file updated. Nope, still the same.

The rewrite rules are the issue, it’s just that they’re not being allowed to work. The new conf file for the SSL config needs to allow the web server to override the more secure defaults. So this needs to be in the SSL configuration file – note this is a sub-section, not the whole thing.

 <VirtualHost _default_:443>
     ServerAdmin admin@yoursite.com
     ServerName blog.yoursite.com
     ServerAlias blog.yoursite.com
     DocumentRoot /var/www/html/blog

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

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

     # SSL Engine Switch:
     # Enable/Disable SSL for this virtual host.
     SSLEngine on
     ...

</VirtualHost>