DNS

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.

Moving a GoDaddy O365 hosted domain to Exchange on-Prem utilizing EOP

@DeanColpittsLeave a comment

Recently, I had a client acquire an organization that used GoDaddy’s O365 offerings.  My client utilizes Exchange on-prem, and is protected with Exchange Online Protection (EOP), which is part of Microsoft’s O365 offerings (and included with Exchange Enterprise Edition User CALs purchased through Open Value Licensing Software Assurance).  My client wanted to add the acquired organization’s domain name to their Exchange server so the new employees would still be sending emails from the old domain name.  Well that should be no big deal – it was not a huge organization that was acquired, (less than a handful of people), and they didn’t have massive amounts of email in their mailboxes (less than 1GB total amongst all of them), so I figured it would pretty simple.  Log into each O365 mailbox, export to a PST for backup, remove the domain from the acquired organization’s tenant in O365, add it to my customer’s tenant, add it to Exchange on-prem, and set the address policy for these users.

And these steps worked, but not as I had originally planned.  GoDaddy rebrands their O365 offerings in the GoDaddy way of doing things, and completely blocks the users from reaching the real O365 Admin portal, which is where the domain setup for the tenant is.  This means it’s impossible to add or remove domain names from the tenant.  And because my client was using EOP – I had to no option but to remove the domain from the old tenant before I could add the new domain name to the client’s tenant (because it was already bound to the acquired organization’s tenant, and a domain name can only be bound to one tenant at a time in O365).  So off I went to do some research.

The secret to removing the acquired company’s domain name from the original tenant was to use GoDaddy’s rebranded and simplified admin portal to first delete all the mailboxes associated with the acquired company (make sure you export them to PST first!), then once that was done, from the GoDaddy account products portal, select options for O365 and then select “cancel account”.  This only cancels the O365 portion of the account – nothing else.  Once cancelled, go make a quick cup of coffee, and by the time you get back to your desk, the domain name will have been removed from O365, allowing you to then add it to a different tenant through the normal O365 Admin portal setup / domain wizard.

Finally, all that was left to do was add the new domain name to Exchange on-prem, change the default email address of the new employees, test inbound and outbound email as them, and import their PSTs.

And as always:

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