Need help? Check out our Support site, then

Unable to connect to WordPress due to self-signed certificate in cert chain

  1. I have JetPack installed on WordPress 3.5 which is running on IIS8. When I hit the "Connect to" button after installing JetPack, I receive:

    Jetpack could not contact register_http_request_failed. This usually means something is incorrectly configured on your web host. SSL certificate problem: self signed certificate in certificate chain

    My site does not actually have an SSL certificate, but I would assume that this would be a trust issue between my Server 2012 VM and WordPress' SSL cert chain itself, correct?

    The blog I need help with is

  2. Hi there,

    You will want to check your SSL certification. If you don't have one, you don't actually have a problem. Jetpack will connect like normal, despite that kind of intimidating warning. If you do have one, it may need some reconfiguring.

    I hope that helps!

  3. I don't have any SSL cert in place for my blog on the Azure VM. JetPack won't connect regardless -- it always throws up that error.

  4. Hi there,

    Hmmm... that's interesting. Well, on my end, I ran your URL through our Jetpack connection test, and it came back sound as a pound. Are you able to see your Jetpack functionality, or is it as if it's not connected at all?


  5. Sorry, I think that auto posted my URL that is hosted on WP. The URL I'm testing with did not have an A record (I was using a hosts file since it is just for testing purposes). I've created an A record and will try again in a little while.

  6. So I've tried again with an A record in place and still no-go. All of the features just say "Learn More". In my Azure Web Site's instance of WP, I think some of the features had configuration/settings button (I forget off-hand).

    URL is

  7. Hmmm,

    I don't see a connection for that URL, either. Which makes me think your Jetpack is not working (as you suspected).

    Can you do the following:

    *Go to admin → Jetpack

    *At the bottom of the page, there’s a link called “Debug”. Click that link.

    *Some arcane debugging information should appear. Copy and paste that information to us.

    I’m particularly interested in the line that starts with “CERT”.

    Additionally, you should switch your theme temporarily to Twenty Eleven and turn off any other plugins you have while we get your Jetpack correctly configured.

    Sorry for all the extra rigamarole!

  8. This is sensitive information. Please do not post your BLOG_TOKEN or USER_TOKEN publicly; they are like passwords.

    CERT: 0
    VERSION: 2.0.4:1355983592
    OLD_VERSION: 2.0.4:1355983592
    USER_ID: 1
    PHP_VERSION: 5.4.9

    Note values that are blank are actually blank and not removed by me :)

    Current Theme
    Twenty Eleven

    By the WordPress team Version 1.5

    Looks like I've been using that theme all this time.

  9. Also, no other plugins are enabled. The only other plugin installed is Akismet, but updated from the one included with the WP install.

  10. Great, thank you for this!

    So apparently this error is caused by extra whitespace somewhere in the config file. The solution is the same as with this error message (detailed instructions at the link):

    I know the error is different, but I am assured that you should be able to solve the issue by following those steps :)

    Let me know how it goes!

  11. FYI I applied an SSL certificate from StartCom (which is generally trusted) and changed my WP address to https://<same domain>, keeping the blog URL the same. No dice and the CERT is still "0".

  12. AH thanks for the follow up, I've been using WordPad since it correctly parses UN*X-style carriage returns, unlike Notepad. I'll have to install Notepad++ :) I'll let you know how it turns out.

  13. So I am still running into the same issue. I downloaded the WordPress zip file again, grabbed wp-config-sample.php and modified that with my current wp-config values, then changed the file name and overwrote my existing wp-config.php file.

    Also uninstalled/reinstalled JetPack with no luck.

  14. One thing I noted was that the wp-config and wp-settings don't have a closing ?> tag. I figured this was normal due to the default files being this way.

  15. I do know that the closing ?> tag isn't necessary in PHP. And that was news to me! But another user pointed it out on a thread I was helping with, and our internal team clued me in. :)

    I'm running your issue down with the internal team, and I'll circle back around with you when I know more :)

  16. Hi again,

    They have asked me to ask you to go ahead and completely delete your Jetpack from within WordPress, then go download a fresh copy and install it.

    Let me know how it goes!

  17. Already did that, prior to installing the SSL cert though. I'll try it again.

  18. Same issue with deleting/reinstalling.

  19. So when I run a netmon trace, it looks like I'm getting:

    TLS: TLS Rec Layer-1 Encrypted Alert


    54 7F EE 53 98 C1 00 15 5D 46 B9 46 08 00 45 02 00 2F 51 40 40 00 80 06 56 30 0A 4C FE 44 4C 4A FE 7B C1 07 01 BB C0 76 1D 1A C2 0C B5 A8 50 18 01 FE FA 62 00 00 15 03 01 00 02 02 30

    30 hex (40 decimal) translates to "unknown_ca" in the TLS spec. This would be during the handshake with the SSL cert * which leverages.

    Even though I've imported the appropriate Intermediate (Go Daddy) and Root CA (Starfield Technologies) certs into my Local Machine trusted store on Server 2012, the issue persists. Not sure where to go from here.

  20. That should be "48 decimal", not 40.

  21. And some more detail... Modified the JETPACK__API_BASE URI from https:// to http://. In my browser, I then changed the URI from http:// to https:// manually, and then using my browser's connection information, exported the certificate chain to a p7b. From there, I imported that cert chain to my server. I then set the JETPACK__API_BASE URI back to the default https://. Now I can get through to the point where it asks me to authorize JetPack against my WP account. When I click authorize, I'm passed back to my Control Panel but have this error and no JetPack-enabled features:

    Jetpack could not contact token_http_request_failed. This usually means something is incorrectly configured on your web host.

    SSL certificate problem: self signed certificate in certificate chain

  22. The values in debug for CLIENT_ID, BLOG_TOKEN, and PUBLIC now have a value. The USER_TOKEN says "[this user has no token]".

  23. If I change the JETPACK__API_BASE value from https to http, then I can get through the entire process (although IE throws mixed content warnings back on my WP control panel when viewing JetPack features). I'd really rather not leave it this way, and for now have disconnected from WP.

    This does appear to be a certificate trust issue with what root certificates Windows Server 2012 trusts, but it would be nice to get better information by those who control the * SSL certificate. If they could provide the exact certificates that need to be imported to fully trust the WordPress wildcard certificate, that would be really helpful.

  24. For another test I built a Server 2012 VM on my home machine (not hosted on Windows Azure) and repeated the installation steps. Same result with the untrusted certificate.

    It would really be nice to resolve this as I can't move my blog over without the features of JetPack.

  25. And one last try, I built a 2008 R2 VM running IIS7, PHP 5.3.19 and WinCache 1.3 with WordPress 3.5... same issue per Network Monitor. So it doesn't appear to be limited to IIS8/Server 2012 hosts. From everything I can see, it appears to be an issue with the certificate chain for *

  26. Any thoughts before I give up? I can connect successfully if I change from https:// to in jetpack.php. My certificate does check out. After connecting, I'm able to change it back to https://, but I don't know if I'm going to miss out on any functionality. After making this change, the JetPack Debug page can still connect to my blog, but the JetPack Compatibility Test Plugin still reports that there is a self signed certificate in the cert chain connecting to

    The only thing I can figure is that * is sending an unnecessary root certificate (validated here: This does seem to be the certificate that the NetMon trace breaks on.

  27. Hi again,

    I'm so sorry for the very long delay - I'm not sure why I wasn't alerted to your responses above. I've resubscribed to the thread...

    Anyway, since it looks like you're still having the issue and it seems unlikely that it resolved on it's own, could you run the compatibility plugin and see what happens?


Topic Closed

This topic has been closed to new replies.

About this Topic


No tags yet.