Wordpress Jetpack: Wpcom Connection Test Error

[mt-dev (Kenny Stier)]

1. Caddy version (caddy version):

v2.2.1 h1:Q62GWHMtztnvyRU+KPOpw6fNfeCD3SkwH7SfT1Tgt2c=

2. How I run Caddy:

Caddyfile

a. System environment:

Debian 10 via systemd, installed using official Debian repo
PHP 7.4.11 (cli) (built: Oct 18 2020 19:44:48) ( NTS )

b. Command:

sudo systemctl start caddy

c. Service/unit/compose file:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile or JSON config:

https://cloudfree.shop {
	root * /var/www/html/cloudfree.shop
	php_fastcgi unix//run/php/php7.4-fpm.sock
	encode gzip
	file_server
	respond /uploads/*.php 404
	header {
	Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
	X-Content-Type-Options nosniff
	X-Frame-Options DENY
	Referrer-Policy no-referrer-when-downgrade
	}
}

3. The problem I’m having:

Wordpress’ Jetpack plugin is unable to fully connect to Jetpack servers

4. Error messages and/or full log output:

5. What I already tried:

I have reached out to Jetpack support. Here are the details they have given me.

26 Oct 2020

Specificially, I’m seeing this error in the XML-RPC requests for your site: The required “url” parameter is malformed. With response code:invalid_signature. It’s possible that something on the server isn’t set up quite right and is causing this response.

3 Nov 2020

Our developers have provided an update on the matter.
After some debugging here’s what they have found out that for some reason, it appears that your server is not informing the port being used in the PHP variable $_SERVER['SERVER_PORT'].
On our side, we don’t handle this very well, and the port ends up being considered as 0 here:

https://github.com/Automattic/jetpack/blob/master/packages/connection/legacy/class-jetpack-signature.php#L78

We then append :0 to the URL and, later on, this URL is considered malformed and thus the XML-RPC error we get.
To solve the immediate situation, we have to understand why your server is not properly returning the port number to PHP.
From this PHP documentation:
Note: Under the Apache 2, you must set UseCanonicalName = On, as well as UseCanonicalPhysicalPort = On in order to get the physical (real) port, otherwise, this value can be spoofed and it may or may not return the physical port value. It is not safe to rely on this value in security-dependent contexts.
So it may be that your Apache configuration is not returning the physical port value.

6. Links to relevant resources:

https://www.php.net/manual/en/reserved.variables.server.php

TL;DR: How do I set the SERVER_PORT PHP variable in Caddy 2?

[francislavoie]

Hmm, that should’ve been fixed by this PR, which is included in v2.2.1:

https://github.com/caddyserver/caddy/pull/3570

But anyways, you can add an env subdirective to php_fastcgi directive to override it for the moment:

php_fastcgi unix//run/php/php7.4-fpm.sock {
	env SERVER_PORT 443
}

Edit: Well, I’d say this isn’t Caddy’s fault… Caddy is being spec compliant as per the fastcgi RFC, jetpack is relying on something that shouldn’t be relied upon when it comes to the SERVER_PORT env. They should be a bit smarter and default to 80 or 443 based on the scheme, if they encounter an empty value.

[mt-dev (Kenny Stier)]

Adding the environmental variable did solve the issue, thank you. That makes me think that the issue isn’t resolved. It seems nonsensical for WordPress to assume :0 so I sent them the link to this thread, but as long as the issue is resolved on either end, no one else will run into the issue in the future.