Over the weekend I was migrating several of my sites over to an nginx-based VPS.  Whilst the migration itself seemed to go fine, I was getting a weird issue with the WordPress admin where the styles and javascript was not fully loading.

After inspecting the requests with the Firebug Console, I saw that the culprit was the request:


I tried the normal fixes such as checking permissions, updating everything, and even reinstalling WordPress but to no avail.  Then I started looking on Google for a potential fix and found this article which not only provides the solution, but also a detailed explanation of why the error occurs in the first place.

As soon as I made the recommended updates, all the sites started working properly with no issue whatsoever.

Full credit goes to the article author.  Just posting here for my own reference more than anything else!

UPDATE: As the original article no longer exists I’ve posted the instructions below:

It turns out the solution to this is quite simple. Nginx and php-fpm need to run as the same user and the directory /var/lib/nginx needs to be owned by that user. Personally I like to run all my web-related services under a www-data user, but running it under a nginx or apache user is also common. To change the user nginx runs under, edit the main nginx config file usually located at /etc/nginx/nginx.conf:

user www-data;
worker_processes 4;
pid runnginx.pid;

Now to change the user php-fpm runs under we need to edit its config file. On my Amazon Linux system this was located at /etc/php-fpm.d/www.conf while on my old Debian setup it was located at /etc/php5/fpm/pool.d/www.conf. There are two user-related settings in the config file. First, if php-fpm runs as a socket (as opposed to listening on a port), the user and group owner of the socket should be set to the same user as nginx so that nginx can access it to run php files. This is not relevant for our error, but can cause other issues if nginx doesnt have permissions to access the socket. Second, the user and group that the php-fpm process runs under needs to be the same as nginx.

    user  = www-data
    group = www-data
    listen = varrunphp5-fpm.sock
    listen.owner = www-data
    listen.group = www-dataL

To change the ownership of the nginx lib directory simply run the command chown -R www-data:www-data /var/lib/nginx as root (sudo will do on most systems). Finally, if we edited any config files, we need to restart the appropriate services for the changes to take effect. On most systems this can be done by running service nginx restart or /etc/init.d/nginx restart as root. For php-fpm the service name is php5-fpm.

Telegram messenger recently released an API that lets you easily create bots for their platform.  After deciding to have a bit of a play with it, I found that I had an issue where the webhooks would not send any updates to my server with no apparent error.

The Problem

I made all the following checks:

  1. Valid SSL certificate
  2. Webhook successfully registered using the Telegram setWebhook method
  3. The method responded properly when I sent a test request using a REST service tester
  4. Server access logs – look like Telegram had never even hit the server

The Solution

After a full day of searching, testing and bashing my head against the keyboard, I found this thread on Reddit, where the user described a problem where a full chained certificate was required on the server, not just the server certificate.

To create chained certificate you’ll need to have a look at what instructions your certificate issuer provides.

In my case the certificate being used was a Comodo PositiveSSL, for which I downloaded all the certificates that they sent, which contained:

  • Root CA Certificate – AddTrustExternalCARoot.crt
  • Intermediate CA Certificate – COMODORSAAddTrustCA.crt
  • Intermediate CA Certificate – COMODORSADomainValidationSecureServerCA.crt
  • Your PositiveSSL Certificate – my_domain.crt

I had to combine them all into a file in the following order:

  • my_domain.crt
  • COMODORSADomainValidationSecureServerCA.crt
  • COMODORSAAddTrustCA.crt
  • AddTrustExternalCARoot.crt

For the example above the command would have been:

cat my_domain.crt COMODORSADomainValidationSecureServerCA.crt AddTrustExternalCARoot.crt COMODORSAAddTrustCA.crt > bundle.crt

After that it was just a case of uploading the new bundle.crt to my server, updating the nginx config, and hey presto, within minutes I was receiving all the responses for my webhooks