Setup and Testing Week

The Setup

Now that I have access to the production server, I had to pull the project’s code from our git repository into the server’s filesystem. Shortly after that, I needed to check if the server application could be built and executed. No major issues in that regard. Everything seemed to be going well at that point. Dr Shawn had already set up the actual Woocommerce site and gave me access as a Store Manager. Before doing anything else in that site, I had to set up the webhook such that the server application could receive requests while it is running in the production server. Here is where the problem arises.

The Woocommerce site and the server application are residing in the same data center, therefore they can communicate with one another via the internal network. Supposedly, I could put the internal IP address of the production server, and the port number in which the application was listening on, as the webhook’s URL and it should work. However, it was complaining that the URL provided is not valid, which is surprising because the URL provided was clearly valid. It turns out that WordPress, by default, does not accept any internal IP addresses.

I had this problem with the Bitnami WordPress VM that I was working with before as well, but the workaround was that I edit this function in one of the WordPress PHP file. At the apply_filters() line, changing the boolean flag from false to true was the solution to that problem. The same can’t be done with the live Woocommerce store though. Dr Shawn tried to circumvent the problem by editing the /etc/hosts file in that WordPress hosting server, such that the specified hostname would be resolved to that IP address. Then, I could just put the hostname instead of the IP address itself in the webhook URL. Unfortunately, the results were the same.

Since it was unexpectedly such a hassle to get the store and the server application to use the internal network, then we had no choice but to communicate via the Internet for now. The server application had to first bind to any IP addresses of its host machine, so that it is reachable on the Internet. In IPv4, this is done by specifying 0.0.0.0, but we used the IPv6 equivalent, which is 0::0. Substituting in the actual domain name of the production server into the webhook URL works. At the moment, the communication uses the unencrypted HTTP protocol, but this is not to be used when the application actually releases.

Browser Tests

Despite the earlier troubles, I could now reach the server application using the Internet. This means I could start testing how the user would import the client certificates in different browsers. Dr Shawn already prepared a Macbook for me to test out the Safari browser, and that’s where I would start. I first created a simple subscription product on the store, and then make its purchase using PayPal, but the PayPal account is a sandbox account with unlimited cash. This would trigger the webhook and send the JSON payload to the server application as expected. The email containing the certificate download link was sent to my work email address. I opened the email in the Safari browser and click on the certificate download link. The PKCS#12 was downloaded successfully.

macOS uses an external application to aid in the importing of the client certificate, hence clicking on the file would bring up that application and would guide the user for certificate import. But then, it starts complaining and the import was not successful. Oh no. That same PKCS#12 file could be imported into Chromium in Ubuntu though. I tested with my own AESTE client certificate as well, and the import was successful. What was the difference? The AESTE client certificate had the full certificate chain stored in the PKCS#12, i.e from the end-entity certificate to the intermediate CA certificate and all the way to the root certificate. Also, it is using an RSA private key, and maybe that macOS application could not support the EC Curve that is being currently used for generating the private keys in our application. It could be one of the two reasons. A simple test with a manually generated PKCS#12 with the full certificate chain proves that it is the first reason.

I quickly tested out the same procedure with Microsoft Edge in Windows 10, using my personal laptop. Windows also uses an external application to import certificates, which is the Windows Certificate Import Wizard. Without the full certificate chain, the certificate could still be imported, but the certificate would not be prompted when attempting to connect to the server application with HTTPS. It works entirely fine, however, for importing a PKCS#12 containing the full certificate chain. So now I know that there is one more thing to be done in the server application.

Stay tuned for next week.