SSL

Fixing WordPress.com’s SSL validation when DNS is not hosted with WP

@DeanColpittsLeave a comment

When I originally started using WordPress.com for hosting this blog many years ago, SSL was a secondary thought for most people (and for some developers I know, it still is today). That said, at some point WordPress.com configured redirection for my blog from http to https, but never notified me. I recently discovered that I was getting certificate mismatch errors when accessing my blog (normally I sign in via WordPress.com, so I wasn’t seeing the certificate errors that my visitors were). So I set out to fix the SSL error, and here’s what I found and how I ultimately fixed the issue. I’m posting this because even after a bunch of research I couldn’t find the answer online anywhere.

And as always before I begin:

Use any tips, tricks, or scripts I post at your own risk.

In my case, my domain name is registered with GoDaddy and the DNS is also hosted with GoDaddy. I’m not keen on transferring my domain or DNS hosting to WordPress.com to take advantage of their automated tools either. When I originally setup my blog, the instructions from WordPress.com was to create a CNAME and point it at them. And this is a screenshot of that DNS record.

My blog has happily functioned off this record for years, but obviously without a valid SSL certificate for it.

So when I discovered that WordPress.com was now redirecting my site to https, I started to investigate why a proper SSL certificate was not being used. After poking around in my domain on the WordPress.com management portal, I found this.

Clicking “Provision Certificate” simply gave me an error that said “Sorry, we weren’t able to provision the certificate. Please verify your DNS configuration and try again”.

Checking my DNS entries for a CAA record clearly shows that letsencrypt.org is authorized to issue certificates for my domain.

And checking the record with a DNS CAA tester indicated the blog.jbgeek.net was good.

After thinking about it for a while however, I decided maybe the issue was I needed a CAA record specifically blog.jbgeek.net, so I attempted to create one, which as you can see below, failed with a cryptic “DNS rules violation for blog record”.

I was able to recreate CAA records for other names (i.e. myblog and www) though. Upon further research, it turns out that as per IETF standard RFC 8659, which governs CAA records, it’s not possible to have a CNAME and CAA record of the same name. So I had a choice, I could have CNAME pointing my blog to WordPress.com, or I could have a CAA record for blog, but that would be useless since there was no CNAME.

Eventually I managed to force my way through WordPress.com’s AI “help” bots and got ahold of what I believe is a real person (however in this day and age, one never knows). After providing all the details and screenshots from above, the individual told me they would do some research and get back to me later via email once they had an answer. To be honest, I didn’t hold much hope of ever hearing from them again.

My to my surprise though, several hours later I received an email from them asking me to delete the CNAME and create two A records for blog.jbgeek.net pointing at 192.0.78.24 and 192.0.78.25. I did so, and then immediately hit the Provision Certificate button only to get the same error. I decided to be patient and wait for a bit for DNS replication to occur and caching to time out (my TTL was only 10 minutes, so it wouldn’t take long). When I came back to my desk to check it 30 minutes later, I found a new certificate had automatically been issued and applied to my site!

Hopefully this will help some one else who is stuck in the same situation.

HOWTO: Configure FileZilla Server to use SSL/TLS with a wilcard SSL certificate

@DeanColpittsLeave a comment

Every so often, we have the need to securely transfer large files between very remote systems, and the simplest way to do this is via FTP with the FileZilla client.  Of course the FTP protocol by itself isn’t secure, but if you enable FTPES, it generally is.  FTPES however requires a SSL certificate, and while you could allow the FileZilla server to generate it’s own self signed certificate, we like to use our existing wildcard SSL certificate which requires a few extra steps, as detailed below.

  1. Download the current version of FileZilla Server.
  2. Perform a Standard install accepting all defaults.
  3. Copy the domain’s wildcard certificate in PEM format (i.e. wildcard.jbgeek.net.pem) and the wildcard’s key file (i.e. wildcard.jbgeek.net.key) to “C:\Program Files (x86)\FileZilla Server”.      (see HOWTO: Generate and self-sign Wildcard SSL certs in Ubuntu if you need to convert your existing PFX wildcard certificate to PEM format).
  4. Open Settings in the FileZilla Server management interface and navigate to SSL/TLS settings.
  5. Select “Enable FTP of SSL/TLS support”.
  6. Browse and select the key file you copied above for the Private Key file.
  7. Browse and select the PEM file you copied above for the Certificate file.
  8. Select “Force PROT P to encrypt file transfers in SSL/TLS mode”.
  9. Adjust any other options as required (i.e. password protecting the management interface until “Admin Interface Settings” or enabling MODE Z support under File Transfer compression).
  10. Select Users from the Edit drop down menu and create your users and access rights as required.
  11. Stop and restart the FileZilla Server service.
  12. Open the FileZilla FTP Client, and connect to via FTPES to the FQDN of the FileZilla Server  (i.e. ftpes://myftpesserver.jbgeek.net, along with the username and password combination you just created).
  13. If you configured SSL/TLS correctly using the above steps, the FileZilla FTP Client should prompt you if you wish to trust this certificate – select “Always trust certificate for future sessions” and click ok.

Keep in mind you may need to adjust the ports on your firewalls to allow connectivity, which is outside the scope of this post.

As always – Use any tips, tricks, or scripts I post at your own risk.

HOWTO: Generate and self-sign Wildcard SSL certs in Ubuntu

@DeanColpitts1 Comment

Generate a CSR:

openssl req -new -newkey rsa:2048 -nodes -sha256 -out wildcard.domain.fqdn.csr -keyout wildcard.domain.fqdn.key -subj "/C=your_country/ST=your_state/L=your_city/O=your_organization/CN=*.domain.fqdn"

View the CSR:

openssl req -text -in wildcard.domain.fqdn.csr

Sign the certificate:

openssl ca -in wildcard.domain.fqdn.csr -out wildcard.domain.fqdn.cer -config /path/to/openssl.cnf

Convert the certificate to PFX:

openssl pkcs12 -export -out wildcard.domain.fqdn.pfx -inkey wildcard.domain.fqdn.key -in wildcard.domain.fqdn.cer

Covert the certificate to PEM:

openssl pkcs12 -in wildcard.domain.fqdn.pfx -out wildcard.domain.fqdn.pem -nodes