Jetpack bug (resolve DNS)

Could you tell me more about your current site and server configuration, so I can try to reproduce this issue?

Thanks!

Hi, as you could see the main site is under wp.lamardebits.org only pointing it as an A all started to work and now also wordpress admin page goes faster.

Could you tell me more about your site setup? You mentioned it was a Multisite instance? Is wp.lamardebits.org the main site in the network, or a subsite? Do you use the Domain mapping plugin on that network? If so, is wp.lamardebits.org a mapped domain?

What constants did you end up keeping in wp-config.php? Did you keep JETPACK_SIGNATURE__HTTPS_PORT set to 80?

If you’ve added an SSL certificate to your site, do you use that certificate only on the dashboard, or all over your site? Did you set both home and siteurl values to use HTTPS?

1. wp-config.php: define( ‘JETPACK_SIGNATURE__HTTPS_PORT’, 80 );
2. main network site: wp.lamardebits.org (home and siteurl is well configured -if not it could be impossible to administrate that!-)
3. yes, it’s a multi-site instance with domain mapping plugin, but as being main site, it doesn’t affect.
4. certificate: using trusted certificate from let’s encrypt set in a frontal nginx server (proxy-http). I don’t allow to access to blog using http, only https. Setting allowing to http also was not working.
5. wordpress hosted in a lxc container with apache non-https (everything in apache points to wordpress folder). Virtual machine could reach internet domains (DNS is OK) and reach internet (gateway is OK).
6. permissions of wordpress folders OK. www-data user is allow to rw the files and folders.

As I told in first message, now it’s working, what I have do is set wp.lamardebits.org as A, not as CNAME.

Please, add jetpack plugin also work over CNAMEd subdomains!

Thanks you much! ??

• This reply was modified 8 years ago by blackhold.
• This reply was modified 8 years ago by blackhold.

Thanks for the extra details!

main network site: wp.lamardebits.org (home and siteurl is well configured -if not it could be impossible to administrate that!-)

Are home and siteurl set to use http, or https?

• This reply was modified 8 years ago by Jeremy Herve.

to https, because if set to http, is not possible to administrate the blog, because nginx frontal server redirect always http to https

• This reply was modified 8 years ago by blackhold.
• This reply was modified 8 years ago by blackhold.

Thank you.

I’ve just tried to replicate that setup. I believe I now have something similar to your site, except it’s a single site and not Multisite network.

I can’t replicate the issue though. I wonder if the A record error message may have been a red herring; it seems your site didn’t use HTTPS when it was first connected to WordPress.com, and that caused some issues when you then switched to HTTPS.

If you were to switch back from A record to CNAME for your subdomain, does the connection issue appear again?

Yep, maybe the first time when setting wp.lamardebits.org was not an https and now it is.

Why that have to be a problem? and why to be an A registry not a CNAME registry is the problem? how exactly it works? is it possible to be updated? usually blogs could move to other hostings.

I try in a while and I tell you the result.

Yep, maybe the first time when setting wp.lamardebits.org was not an https and now it is.

Why that have to be a problem?

When you connect your site to WordPress.com, some of your site’s options (like the site URL, the site language, …) are synchronized with WordPress.com. This allows WordPress.com to then use that information to communicate with your site, and to provide information for the modules that rely on the WordPress.com cloud like Publicize, Stats, Related Posts, …

However, if one of the site URL values saved on WordPress.com isn’t correct, it can break the connection between your site and WordPress.com. I think this may be what happened here.

why to be an A registry not a CNAME registry is the problem?

This should not be a problem. It doesn’t have an impact on the Jetpack connection in my tests.

Hi, I get problems again with that before upgrading wordpress and jetpack plugin… it were working for some days and the DNS configuration didn’t change.

I tried to disconnect jetpack (and check that don’t appear the site in wordpress.com), edited in database siteurl and home from wp_config table, defining it to https (remember, apache does not have https, but nginx server it does) and connected again.

Before doing that I tried to connect with jetpack with no chance ?? and always get the same error:

SELF:
	Array
(
    [headers] => Requests_Utility_CaseInsensitiveDictionary Object
        (
            [data:protected] => Array
                (
                    [server] => nginx
                    [date] => Mon, 12 Dec 2016 00:41:29 GMT
                    [content-type] => text/plain;charset=utf-8
                    [expires] => Wed, 11 Jan 1984 05:00:00 GMT
                    [cache-control] => no-cache, must-revalidate, max-age=60
                    [x-hacker] => Jetpack Test
                    [x-ac] => 3.lhr _dca
                    [strict-transport-security] => max-age=15552000
                )

        )

    [body] => {"error":"Can not resolve your domain \"A record\"","error_description":"We were unable to resolve the A record for your domain. It is likely that you have recently registered your domain name. It takes several hours for new or transferred domain names to start working, so please come check back later. If you're still having the same error after 48 hours, please contact your web hosting provider."}
    [response] => Array
        (
            [code] => 400
            [message] => Bad Request
        )

    [cookies] => Array
        (
        )

    [filename] => 
    [http_response] => WP_HTTP_Requests_Response Object
        (
            [response:protected] => Requests_Response Object
                (
                    [body] => {"error":"Can not resolve your domain \"A record\"","error_description":"We were unable to resolve the A record for your domain. It is likely that you have recently registered your domain name. It takes several hours for new or transferred domain names to start working, so please come check back later. If you're still having the same error after 48 hours, please contact your web hosting provider."}
                    [raw] => HTTP/1.1 400 Bad Request
Server: nginx
Date: Mon, 12 Dec 2016 00:41:29 GMT
Content-Type: text/plain;charset=utf-8
Transfer-Encoding: chunked
Connection: close
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=60
X-hacker: Jetpack Test
X-ac: 3.lhr _dca
Strict-Transport-Security: max-age=15552000

{"error":"Can not resolve your domain \"A record\"","error_description":"We were unable to resolve the A record for your domain. It is likely that you have recently registered your domain name. It takes several hours for new or transferred domain names to start working, so please come check back later. If you're still having the same error after 48 hours, please contact your web hosting provider."}
                    [headers] => Requests_Response_Headers Object
                        (
                            [data:protected] => Array
                                (
                                    [server] => Array
                                        (
                                            [0] => nginx
                                        )

                                    [date] => Array
                                        (
                                            [0] => Mon, 12 Dec 2016 00:41:29 GMT
                                        )

                                    [content-type] => Array
                                        (
                                            [0] => text/plain;charset=utf-8
                                        )

                                    [expires] => Array
                                        (
                                            [0] => Wed, 11 Jan 1984 05:00:00 GMT
                                        )

                                    [cache-control] => Array
                                        (
                                            [0] => no-cache, must-revalidate, max-age=60
                                        )

                                    [x-hacker] => Array
                                        (
                                            [0] => Jetpack Test
                                        )

                                    [x-ac] => Array
                                        (
                                            [0] => 3.lhr _dca
                                        )

                                    [strict-transport-security] => Array
                                        (
                                            [0] => max-age=15552000
                                        )

                                )

                        )

                    [status_code] => 400
                    [protocol_version] => 1.1
                    [success] => 
                    [redirects] => 0
                    [url] => https://jetpack.wordpress.com/jetpack.testsite/1/?url=https://wp.lamardebits.org/xmlrpc.php
                    [history] => Array
                        (
                        )

                    [cookies] => Requests_Cookie_Jar Object
                        (
                            [cookies:protected] => Array
                                (
                                )

                        )

                )

            [filename:protected] => 
            [data] => 
            [headers] => 
            [status] => 
        )

)

Your site appears to be properly connecting to WordPress.com right now. I see no connection trouble on our end. If you still have trouble, could you tell me more about the problems you’re running into?

I think you can ignore that A record for now; it’s most likely an issue with the debugger itself.

Hi, I’m triyng to access to admin pannel and goes extremely slow! I have other CMS in these servers and go ok and faster.

Finally I could access to jetpack section and in the top still it appears

Outbound HTTPS not working

Your site could not connect to WordPress.com via HTTPS. This could be due to any number of reasons, including faulty SSL certificates, misconfigured or missing SSL libraries, or network issues.
Jetpack will re-test for HTTPS support once a day, but you can click here to try again immediately: Try again WordPress reports no SSL support
For more help, try our connection debugger or troubleshooting tips.

Please tell me what checks I have to do to test that…

Thanks you much!

• This reply was modified 7 years, 11 months ago by blackhold.

Outbound HTTPS not working
WordPress reports no SSL support

This will be displayed when your site isn’t able to make outgoing HTTPS requests.

I’d recommend reviewing your site configuration to make sure that gets fixed. You’ll want WordPress to return true for a test connection like wp_http_supports( array( 'ssl' => true ) ). You can read more about it here:
https://developer.www.ads-software.com/reference/functions/wp_http_supports/

In wp-includes/http.php I have that

function wp_http_supports( $capabilities = array(), $url = null ) {
        $http = _wp_http_get_object();

        $capabilities = wp_parse_args( $capabilities );

        $count = count( $capabilities );

        // If we have a numeric $capabilities array, spoof a wp_remote_request() associative $args array
        if ( $count && count( array_filter( array_keys( $capabilities ), 'is_numeric' ) ) == $count ) {
                $capabilities = array_combine( array_values( $capabilities ), array_fill( 0, $count, true ) );
        }

        if ( $url && !isset( $capabilities['ssl'] ) ) {
                $scheme = parse_url( $url, PHP_URL_SCHEME );
                if ( 'https' == $scheme || 'ssl' == $scheme ) {
                        $capabilities['ssl'] = true;
                }
        }

        return (bool) $http->_get_first_available_transport( $capabilities );
}

• This reply was modified 7 years, 11 months ago by blackhold.

Yes, the function is part of WordPress, and is used by WordPress to test if a HTTP Transport exists on the server to process a specific request. On your server, it appears that WordPress can’t find anything that can be used to make outgoing HTTPS requests. That’s a problem, since WordPress and its plugins (like Jetpack) will try to use HTTPS since you use HTTPS on your site.

You could force Jetpack to ignore that and make HTTP requests instead, but that won’t solve other problems that may appear later with WordPress itself and with other plugins.

To force Jetpack to use HTTP, you can add the following to your site’s wp-config.php file:

define( 'JETPACK_CLIENT__HTTPS', 'NEVER' );