Security Certificate Alerts on Whatever — Don’t Panic!

Every once in a while I get an email or other notification from someone about their browser (usually Chrome but occasionally Firefox) warning them that Whatever is insecure and asking them if they really want to continue onto the site. In the interest of quelling concerns and also not having to write this up every single time it happens, let me tell you what’s going on.

1. Whatever is housed on WordPress’ VIP service (and happily so) at; the address maps there.

2. Whatever’s security cerificate, however, is to the domain, not the domain.

3. So, if you’re directing your browser to use https, it may throw up a warning letting you know the domain doesn’t match.

So, the URL isn’t being hijacked — unless you see on the warning page that the security certificate is going somewhere other than

I’ll look into seeing what can be done about figuring this out. In the meantime, if you are getting these warnings, here’s what you can do.

1. Use “http” rather than “https” when you put in the URL (note this is nominally insecure) and you’ll be taken to Whatever without fuss.

2. If you see the security certificate for the site is from, go to the advanced settings and click through, it’ll be fine (and your browser will probably remember your preference in the future).

3. Alternately, if you use https, substitute “” for “” and you’ll be taken to Whatever without any security alerts. Note that once you’re there, the URL will show up as “” Mapping is wacky. This works for sub-urls as well (direct links to entries, etc). Update: Note that IT folks in the comments say that when you’re punted back to, you’re being sent back to the site without https enabled.

Update: 4. Another option I just enabled it to access Whatever via a shared SSL Encryption setup. The URL to use is: (it will also work with individual entry URLs). Note using this will strip out insecure elements of the page (usually things like embedded media).

Hope this helps.

19 Comments on “Security Certificate Alerts on Whatever — Don’t Panic!”

  1. This thread is the one that you want: It says you can’t (currently) do what you want to do.

    The only way I can think of to make it work would be for you to have your own server somewhere with your own SSL certificate for, and just have that server do 301 redirects for everything to But it would involve some expense, and be tedious to maintain.

  2. You would need to find out whether WordPress’s VIP service can serve a certificate valid for both and when asked for either of those two domain names. Right now it’s serving a certificate which is valid for any single subdomain of but nothing else (*, which may mean that they can’t do it (because their system has no ability to deliver a certificate tailored for a specific site). Their customer support ought to know whether or not this is possible and, if not, why they don’t offer it (yet).

    Also, the “note that once you’re there, the URL will show up as ‘'” part is because, if you go to, the browser is instructed to reload the page under the name Which means that it should throw up the security error regardless of which name you visit first; that it doesn’t is either a bug or a backward compatibility hack that will go away eventually.

  3. One way to fix this if WordPress won’t do anything would be to set up your own webserver on and use it as a reverse proxy with mod_rewrite or something similar. Not ideal, but certainly less expensive than hosting a copy of WordPress yourself and porting everything over (which would certainly be a pain).

  4. Why not have whoever is generating the certificate put in a “Subject Alternate Name” which is a field on the cert that allows you to put alternative names, such as “” while having the MAIN name be The field has been around for a long time exactly for scenarios like this. It just needs to be “baked” into the certificate. Here is a really quick and dirty webpage on it.

  5. This is EXACTLY the sort of post a hijacker would author to assuage our fears and get us to drop our guard!

    . . . I’m not falling for it . . .

  6. Dear John,

    I would kindly ask you to reconsider this post for the following reasons:

    1. The problem is on the server side, not on the user side. It is technically feasible to provide a certificate that fixes the problem. Though you provide serious efforts on how security conscious people can check it, working around IT security miss-configurations on the user side should not be encouraged.

    2. Telling someone to use HTTP instead of HTTPS is never a good idea. If we want to achieve any kind of IT security, encryption everywhere should become a standard, not a measure for tin foil hat wearers. Though i seriously doubt Chinese intelligence or any other nation state attacker will use your site as an avenue, it still would be a good example.

    If I use, I am redirected to the unencrypted site. Please ask your service provider, not to do that.

    No matter how you decide, thanks for reading that far.

    Yours, Martin

  7. FWIW, I fully endorse Martin Seeger’s comment above. The reason “works” is because the browser connects with the full strength of SSL to wordpress, tells wordpress “I want to see stuff on”, and wordpress says “Oh, try again with this domain name – – and this time, don’t use any of that silly encryption stuff.” That is, in the bounce to the domain, it explicitly tells you to use http (no s).

    In short, your blog doesn’t support https, and wordpress may have made it impossible for you to do so for the foreseeable future. Which kind of sucks, but sometimes the marketplace doesn’t give us what we want at the price that we want.

  8. Martin Seeger:

    What’s to reconsider? People are wondering why there’s a mismatch, I’ve told them and why and how to get to the site without security alerts. I don’t believe I am suggesting the site is secure.

    I will note that I am in the process of encrypting that site generally; note that the impeding factor here will be my own technical competence.

  9. I think the short version is that at the present time, it is impossible to do all of these three at the same time:

    1) Host a blog on WordPress’ VIP service
    2) Use a custom domain name for that blog (that is, one that doesn’t end in “”)
    3) Support https on that blog

    According to the thread drplotka linked to up above, as of mid-June last year this was “on their roadmap”. I would suggest you try to get a better idea from them through their support on how this work has been progressing.

  10. @John: Sorry it sounded confusing, I am currently down with fever. What I wanted to say:

    Your post gave recommendations that (from my PoV) train bad security practices. A “I know of the problem and will be working on it once my time allows it” would be better.

    When back up&running again, I am willing to contribute what I have as comptence-emulation ;-).

    Sorry for the short answer…. drop me an email if I am allowed to help. May be offline a few days.

  11. If you ever do decide to ‘move’ your WordPress site to another server (or for any lurkers), there is a great plugin called “WP Clone” (from WP Acadamy) that makes it painless. Install it on the current place, backup up everything (simple command), create a WP at the new place, install the plugin there, then Restore via the URL from the old place. Everything comes over: users, posts, pages, uploads, pix.

    Easy-peasy. I’ve done it on lots of sites that I have developed in a test area, then cloned it to the ‘live’ place. Recommended from this WP geek.

  12. So what is the security threat?

    It seems to me that a spoof site could harvest the email addresses of commenters, but beyond that, what does it mean for a blog to be unsecure, nefarious actors pretend to be John Scalzi and promote their books?

  13. Huh. I had no idea about specifically using “https” on any site. I thought some sites just were and some weren’t.

%d bloggers like this: