SSL Issues etc. with Newly Migrated Site

This will be long, because it's going to take a lot of explanation, which is why I'm doing a ticket instead of chat for this.

I recently migrated my site,, to WPMU. It was previously hosted at GoDaddy, and the DNS was managed there, though the domain is hosted at FatCow. There is an SSL certificate on the site that is issued by Starfield, but purchased through GoDaddy. When I moved the domain name over to the newly created WPMU site, I noticed that some of the time when the page was loading it would be labeled as "not private." This seemed to be a problem with the SSL certificate, because the issuer was coming up listed as FatCow (the domain registrar but not the issuer), which is not correct. At other times if I clicked "show certificate" the one displayed would be from Let's Encrypt (your ssl). Sometimes it would read Starfield. I decided to wait for it to finish propagating, especially because your reps and other people were telling me the site looked OK to them.

In addition, the site would at times redirect to another domain I own,, that was not in use. I could not figure out why this would be but then I remembered that when I first built this site I had used that domain as sort of a staging site for it, and had the domain name changed over by GoDaddy afterward. It looks like maybe some of the content, mainly images, are still connected to, which I recently reassigned to one of the sites I'm now hosting here at WPMU. Confused yet? I have not had any problems related to this until I moved that domain name over to WPMU.

Now, I am getting all of these scenarios happening at various times:
1) Everything loads fine, and the certificate says it is issued by Starfield;
2) I get a "not private" response, and the certificate says FatCow;
3) Everything loads fine, and the certificate says "Let's Encrypt."
4) The site redirects to "," the URL I previously used when I built this site 2 or 3 years ago.

When your tech people check it, and it looks fine to them, I'm led to believe that I'm only seeing these things because of some caching issue on my end. But it has been a few days now, every cache I have access to has been cleared multiple times, and if there is some secret cache, through my ISP or something, it's got to be gone by now. No one clicks on the pages of my site more than I do, so it's not surprising others don't encounter the problems with the same frequency. I just need to get it sorted out.

I would prefer to keep my Starfield cert at this point because it's a little higher level of protection than the Let's Encrypt. but at this point I don't really care that much. I just want every click to produce the same results, and I especially would like to remove that other domain, moveit4younow, from the equation, though I'm really not sure why it's there in the first place.

Please help sort this out.

  • Adam Czajczyk

    Hello mary

    I hope you're well today!

    It seems there are actually "two issues in one" so let's go through this one by one.

    SSL Certification

    The "default" setup would be that when the site is set on our hosting, it's set under a temporary "" sub-domain which is automatically protected by Let's Encrypt certificate. Then, when you point your own domain to the server by updating domain's DNS settings, after the changes are propagated there's also Let's Encrypt certificate automatically generated and installed for you. This should work "out of the box" and no "3-rd party" certificate would be necessary and shouldn't be getting in a way.

    I assume then that this configuration isn't quite standard. You say that sometimes one cert comes up, sometimes other and sometimes it's "not secure" at all. Since there's no Starfield cert on our end, that would suggest that either the DNS wasn't still fully propagated and was "unstable" at the time - loading the site from one or other source "randomly" or that the domain isn't directed straight to our host.

    When checking DNS from outside, it shows that the domain is correctly pointing currently to the your WPMU DEV Host IP so that part is fine. I'm not sure about the details though: since you mentioned that the domain was purchased with FatCow but hosted with GoDaddy - did you make the change to DNS at FatCow or is it still "going through" GoDaddy?

    I'm asking because nameservers seem to be still pointing to GoDaddy even though A record points to WPMU DEV Host. In general, it's best to make change at domain registrar so that's where the DNS settings should be changed. Can you confirm that the change was done there and if you are still seeing that sometimes one cert is showing up and sometimes other?

    Wrong domain

    I checked and this additional (wrong) domain is not assigned to this host anymore so it shouldn't be getting in a way. However, since it was used before as a temporary one, there's some slight chance that there might either be some references to it left in the database or there's some on-site cache that's affecting it still - or that some references are "hard coded" e.g in the theme, some CSS or some custom code on site (if there is any).

    I realize that you already cleared caches but I'd like to take a closer look at this. Could you please enable support access to the site then? To do so, please go to the "WPMU DEV -> Support" page in your site's back-end, click on "Grant support access" button there and let me know here once it's done.

    Could you please tell me please whether these redirects to that old domain are happening rather randomly or if you were able to observe some sort of "pattern/rule"? Are they happening from homepage or back-end or some other pages on site?

    Kind regards,

  • mary

    I always enable access before chatting or writing a ticket, so you should have no problem getting in. Do I need to disable 2-factor or anything? I don't think you enter through the regular login so I'm guessing not.

    Initially, I migrated to and did not bring the domain name over because I wanted to take a few days making sure the copy was all working correctly before doing so. When I was ready to move it over, I got your rep Violeta on the chat. Initially, she suggested changing the A record at GoDaddy, but I wanted to change it at FatCow and eliminate the middle man. So that's what we did together on the chat. It was at that point that the certificate began to read incorrectly, listing FatCow as the issuer. I gathered from this that it was going to be problematic to eliminate GoDaddy from the loop as the certificate was issued by them, so with Violeta's input I changed the A record and nameservers at FatCow to point back to GoDaddy, and then changed these things at GoDaddy, where the DNS was set up to be managed, so that it flowed from there to WPMU. While I was on chat with her I also got on the phone with GoDaddy, who initially said they had to revoke the certificate, but when I told them it was a Starfield certificate and not Domain Control, which is their in-house SSL, they said it should be fine to transfer over. Well, that's obviously wrong. Do I need to get that certificate revoked? If so I don't want to do it until we are sure the site is loading from WPMU and not from GoDaddy.

    During the chat, Violeta told me everything was fine on her end, she was not getting and "not private" responses or redirects, so I decided this was probably happening because of the brief attempt to cut GoDaddy out of the loop, and would resolve itself once the site was fully propagated. But it hasn't.

    Is there some way other than the certificate to confirm that what is loading, at least the majority of the time, is the version on your server? It seems to me that, since during propagation I was more frequently getting the Let's Encrypt cert, it may be loading most of the time from GoDaddy still. If you are seeing the GoDaddy name servers, doesn't that indicate it is not getting through to WPMU? If i check the IP checker, though, it shows the WPMU IP address.

    As far as a pattern goes, I am getting the "not private" response mostly, at this point, when going o pages other than the home page. For example, I created a new URL to mask login, and that page initially came up as not private. If I back up and re-enter, it always resolves. It happens when going from the front end to admin as well.

    I am getting the alternate domain mainly on my mobile device at this point. I don't see a pattern with it but I will keep my eye out for one.

  • Adam Czajczyk

    Hello mary

    Thank you for your response and I'm sorry for the delay on my end.

    I was able to access the site back-end now so I checked it and the configuration of your WP looks fine, so that's a good thing. I checked the site also against the SSL certificate:

    - using different browsers both in "regular" and "incognito" mode
    - using my mobile device
    - using GTMetrix and Pingdom Tools
    - I also looked into The Hub to check configuration of the domain in your hosting panel
    - and I checked the certificate itself using SSL Checker here:

    Everything seems to be running fine now: site was always loaded over https connection, as secure, with a proper Let's Encrypt certificate served by WPMU DEV Host.

    One slight "glitch" that I noticed is only the "www" version of the domain (all the checks were made with the domain not prefixed with "www") which seems to not exist currently. This means that the "www" has to be set in DNS (either as A record pointing to your WPMU DEV Host IP or as CNAME record pointing to the domain itself). But this wouldn't case such issues - it simply makes the site unavailable via www-prefixed address.

    I also checked the DNS propagation for the domain and it does now seem to be fully propagated (I used two separate tools for this) so even if there was "DNS dance" (just my private term for not fully propagated DNS behavior when it likes to "switch" between locations, being a bit unstable) it shouldn't happen anymore.

    I admit I'm not really sure what is happening then but on the hosting end it all looks fine. What can possibly be still affecting this could be some caches such as cache on the mobile device (browser), internet provider might be doing some caching (e.g. there might be some "stubborn" DNS caching)... Also: did you check the site using incognito mode of the browser (and using various browsers) on your end? Or using various mobile devices? Did you check it - on your end - using different internet connection or the same connection always (if the same, restarting router might help clear any possible DNS caches)?

    I'm just trying to narrow down possible causes of that and pinpoint the cause of what you're experiencing with the site.

    I don't know if you've done something or are currently working on this, but now it is impossible to open a secure version of any page. Everything comes up as not private. If I don't get some sort of response soon I am going to make some changes myself, because I can't leave it like this.

    I didn't make any changes to the site whatsoever, nor previously neither now - I was only checking it. Currently the site loads over SSL (and the proper certificate) with all the checks that I made (so from my location but also using external 3rd party tools) and such behavior might actually confirm the DNS switching with the domain finally properly propagated but before SSL has been (re)generated.

    Kind regards,

  • mary


    I'm not having any SSL issues now either. It all seemed to clear up when I deleted my cpanel account at GoDaddy, removing the opportunity for confusion between the two sites. However... if I purposely type in http:// instead of https:// I am still some of the time being referred to, which is, as I said, an old domain I "recycled" as a staging site for this one. I know most people are not going to type in http but I think it does indicate that there's still some sort of issue. I'm not going to worry about it too much, though.

    I think FatCow is the originator of this particular problem. I just (for the first time in years) got a notice from FatCow that my Wordpress site had been updated to 5.1, but I don't HAVE any sites at FatCow. The site that's giving the problem originated on their managed Wordpress, so I have a feeling that all the DNS switching has somehow re-activated it, though that sounds crazy. I have had crazier issues with FatCow! I will contact them to see if they can shed any light on this. I'm going to close this ticket, but will reopen if I need further help.

  • Adam Czajczyk

    Hello mary

    Thanks for getting back to me with additional information. I think yes, that GoDaddy "getting in a way" and something "messed up" by FatCow sounds like a very reasonable explanation of the issues that you were experiencing. In case you'd need any further assistance with is (e.g. because of something that FatCow will tell you), just let me know please.

    As for "www" - I was refering to the "". While "crackedvesselvintage" works perfectly fine for me now, the "" doesn't load on my end, there's a DNS error stating that such domain cannot be resolved and the DNS check shows there's no "www" A and CNAME for that domain:

    There's also "" added to the site and this one's fine for both "www" and "non-www" versions.

    Best regards,

  • mary

    Hey, I see what you mean, I also can't reach the www now, though earlier when you mentioned this I was not having any issues with It has also been working fine since I migrated it, which was several days ago now. It was appearing on the list of domains with all green checkmarks before but now has a red "x" under DNS. I don't know how to alter the DNS for just the www; as far as I know they have always just been linked together. Do I need to add a www cname and a record to the DNS? If so, how do I do that?

    Since the www seems to have gone down after I eliminated the cpanel account, could the incorrect loads - the wrong ssl, the wrong redirect - have had something to do with this? Maybe the www was always loading from GoDaddy while the non www loaded from you guys? This would explain a few other mysteries, as well, since I was having crazy problems yesterday that looked as if someone else were accessing my admin and turning off things I just turned on. If I was in fact reaching 2 different admin sites - one for and one for, that would explain a lot. However, since it was previously showing that the DNS was correct, I don't know how that could be.

  • Adam Czajczyk

    Hello mary

    Yes, I think it was related to GoDaddy. If the domain was going through it somehow then if the "www" was only set up at GoDaddy's DNS, getting rid of GoDaddy would also remove that.

    Basically, you'd need to go to DNS editor at FatCow again and add either the CNAME record pointing to "" or the A record pointing to your site's WPMU DEV site IP; no need to add both, just either this or that - in both cases for "www". This should not affect already existing settings of the DNS but might again take time to propagate so while shouldn't "break" current settings, it might take some time (from just a few hours to 24-72 hours) until that "www" prefixed URL will become functional again.

    I believe you're right that "GoDaddy as a middleman" would explain some "mysteries" so I think: give that www a try and if that solves the problem and the SSL issues doesn't come back, that would just confirm that this "GoDaddy in a way" was the main culprit here.

    Best regards,

  • mary

    Ok. And of course I meant https not http in the previous post but it seems like you got that :slight_smile:. The DNS is still managed at GoDaddy, though; I eliminated the cpanel account which was conceivably putting a second version of the site out there, but the DNS management is a separate thing. Excuse my ignorance but there is no specific DNS for the www. Do I add a CNAME that is www, or what? How do I indicate that the www should be going to wpmu as well?

  • Adam Czajczyk

    Hi mary

    Yes, "there's no DNS for www" and that's exactly what's causing the "www issue" :slight_smile: You would want to fire up the DNS editor for the domain and add the CNAME. If that's at GoDaddy, this article should help:

    You'll have three fields there: "host", "points to" and "TTL". In the "host" field you'd put www, in the "Points to field" you'd put @ and you'd leave TTL intact, then save everything and wait.

    When adding this, you should have also a drip-down to select record type so you'd need to select CNAME.

    After the DNS propagates, that should make the www-prefixed domain work again and point to "wherever the is pointing" - in this case to your WPMU DEV Host.

    Best regards,

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.