Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the hueman domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/CloudIngenium.com/htdocs/wp-includes/functions.php on line 6114
Error activating Jetpack: SSL certificate problem: self signed certificate in certificate chain – Knowledge eXchange

Error activating Jetpack: SSL certificate problem: self signed certificate in certificate chain

Error activating Jetpack: SSL certificate problem: self signed certificate in certificate chain

I haven’t had the need to activate Jetpack on a new site for a while but now that I did I came across this issue:

Jetpack could not contact WordPress.com: register_http_request_failed. This usually means something is incorrectly configured on your web host.

SSL certificate problem: self signed certificate in certificate chain

sometimes you could also be getting the following:

Technology.Bauzas.Com - Jetpack - register_http_request_failed - SSl certificate problem unable to get local issuer certificate

 Jetpack could not contact WordPress.com: register_http_request_failed. This usually means something is incorrectly configured on your web host.

SSL certificate problem: unable to get local issuer certificate

I immediately thought this was part of an issue I have experienced in the past with my host provider (you can read more about it here: “Jetpack could not contact WordPress.com: register_http_request_failed.”) but it turns out this is a new issue that is affecting others as well. I have not been able to pinpoint what the root cause for this is, and reading on the internet I haven’t found the answer yet. However, I did come up with a workaround that seems to be popular on other web blogs to address this issue. I will include at the end another possible workaround for this issue I have not been able to verify (because I already activated my site and I am lazy to test this other one) but it sound legit.

Workaround 1:

This workaround is quite simple. The idea behind it is to modify JetPack to use http instead of https for communication that way avoiding the SSL checks. Word of caution: Communication through a nonsecure channel such as http instead of https makes it possible for hackers and others to capture your information with not too much hassle. If your site, password, or whatever is highly important/sensitive this might not be the best approach for you so I would jump to Workaround 2. However, this is the simplest one I know of and I am willing to take my chances.

Here are the simple steps to follow:

  • Open jetpack.php and replace the following line (You can find Jetpack on your plugins directory under the Jetpack directory):

define( ‘JETPACK__API_BASE’, ‘https://jetpack.wordpress.com/jetpack.’ );

to

define( ‘JETPACK__API_BASE’, ‘http://jetpack.wordpress.com/jetpack.’ );

  • After you remove the ‘s’ from ‘https’ you will be able to activate your jetpack instance. Proceed to click on the Connect to WordPress.com button
  • After you are presented with a screen to log-in to WordPress.com I suggest you manually change the URL on your browser to https instead of http before logging in. This way your password is sent securely over the network.
  • The activation will fail as you used HTTPS to authenticate with WordPress.com. Fear not, go ahead and try again to activate your site with jetpack.
  • Now you are presented not with a login screen but with a screen that allows you to connect your site (as you are already logged in). Go ahead and connect your site to WordPress and Jetpack!
  • You’re done! So here although our password was sent securely over the network, when we connected our site to WordPress and Jetpack the token to authenticate was sent over a nonsecure channel. The risk here is that if some hacker was sniffing your traffic now they can access your site’s information on JetPack without your consent or knowledge. If this risk is material or important to you I would recommend using the next workaround… if you don’t care if someone has this information, or simply wish to take your chances (again, for most of us our traffic isn’t being monitored and captured I hope) then this is the simplest method.

As an alternative to this which I think it is more complicated you could edit a php file to avoid it using SSL:

wp-content/plugins/jetpack/jetpack.php.

On line 1290, change the current:

if ( $jetpack->use_ssl[$method] ) {

to:

if ( false && $jetpack->use_ssl[$method] ) {

Workaround 2

This solution revolves around temporarily disabling the cURL function on the site. What is cURL? Beats me probably some library WordPress uses for external http communication, etc. Below are the simple steps to temporary disable cURL and activate Jetpack while at it. Please remember to re-activate cURL once you are done activating your Jetpack installation:

  1. Install and activate the Core Control plugin
  2. Under Tools click Core Control
  3. Select ‘HTTP Access Module 1.0′ and click ‘Save Model Choices’
  4. Under the Core Control title click on ‘External HTTP Access’
  5. Under ‘Manage Transports’ find ‘cURL’ and click ‘Disable Transport’
  6. Now activate the Jetpack plugin with your WordPress.com account.
  7. Once verified that the Jetpack plugin has activated successfully you can go back in Core Control and activate the cURL transport: Tools -> Core Control -> External HTTP Access -> Manage Transports -> cURL -> Unselect Disable Transport.

 

 

 

 

Enhanced by Zemanta

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.