WordPress/PHP Nonsense

fault code -32700 parse error. not well formed

That’s what I’ve been getting when I tried to use any client to connect to my WordPress instance. The WP web UI worked fine and I wasn’t seeing any errors in the dashboard.

I’ve been trying to get back into the habit of using my micro.blog account for a while now, but kept having trouble with the micro.blog apps. I could read just fine, but I couldn’t post to micro.blog via the app (which in turn posts to my self-hosted WP blog).

This process used to work a few months ago and I thought it was a problem with micro.blog itself. After more investigating and some pointers from Manton Reese via Micro.blog support, I finally figured out the issue…

The server was missing the package php-xml. Turns out, WordPress will happily run without it and the xmlrpc endpoint will even respond with XML without it, but it won’t actually work. After doing a quick:

yum install php-xml

I was back in business. I’m surprised WordPress didn’t detect this and point out that a required package was missing. Maybe it did and it just didn’t make it obvious? I’m not really sure, but I see lots of people with the same issue when I search for the solution. I had to dig through several Google results to finally find the answer which was also surprising.

So if you get an error saying “fault code -32700” and “parse error. not well formed”, make sure your php-xml package is installed.

Trying Out Let's Encrypt

If you’re like me, you probably never bothered setting up a security certificate on your personal/hobby projects since there was a cost to get the certificate and some pain with actually acquiring/installing the certificate.
If you haven’t heard of Let’s Encrypt, it’s a publicly available, free, certificate authority that you can use to generate SSL/TLS certificates for any website. Now that Let’s Encrypt is available, I thought I’d give it a spin since it looked easy enough and the price was right.

Installation with Nginx

I expected the process to be somewhat painful to get signed up, get the certificate issued to my server, and get it installed. It turns out, it’s really not painful at all thanks to this nifty tutorial from Digital Ocean.
All you really have to do is install some packages with your package manager, run a simple command line command, follow the prompts, and then configure your preferred web server to use the certificate. It’s worth noting that nothing in that tutorial is specific to Digital Ocean. I prefer Linode and run everything there, but the instructions are very generic, so they should work just fine with any host.
Nginx is my default choice for a web server/proxy. Apache support is baked into Let’s Encrypt, but I’m happy to report that Nginx works just fine as well. The only real difference (as I understand it) is that you’ll need to manually or programmatically handle the renewal of your Let’s Encrypt certificates. I believe you get that taken care of “out of the box” if you’re using Apache, but that tutorial link above has a nice solution for Nginx.
The actual certificate generation & download amounts to this (see tutorial for details):
sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
sudo service nginx stop
cd /opt/letsencrypt
./letsencrypt-auto certonly --standalone

You probably noticed there was an nginx stop command in there. That’s needed for this particular install method because Let’s Encrypt temporarily uses port 80 to authenticate your server before issuing the certificate. There are other ways of doing it, but this is a super easy way to get that first certificate. In the tutorial, they explain how to automate certificate renewal and that process does not require Nginx to stop, so this is a one time per root domain kind of deal.

Gotchas

For my use case (personal & hobby sites), Let’s Encrypt works perfectly. While I was researching it, I did see a few situations where it may be less than optimal, so I’ll point them out in case they are important to you.

No Wildcard Support

You can include any number of domains in your certificate, but you must explicitly list out each one. If I wanted to get a certificate for project1.adambyram.com, project2.adambyram.com, and project3.adambyram.com, all in one certificate, I definitely could.
What isn’t allowed though is getting a certificate that covers all subdomains (*.adambyram.com). This is only an issue in cases where you have a SaaS application that generates a dynamic subdomain for each user/account.

Certificate Issuance Throttling

You may be thinking you could work around the lack of wildcard support by automating the process of getting a new certificate when you need it. The catch is that you’ll be throttled to 5 certificates per top level domain per week. I’m sure this limit is subject to change, so double check this restriction before you give up. This wouldn’t be as bad if it didn’t apply to the top level domain, but unless/until that changes, this makes using Let’s Encrypt on a service that uses dynamic subdomains a no-go.

Required “A” DNS Record

In order to verify your domain, Let’s Encrypt will check your DNS entries and verify that the server that is attempting to generate the certificate is the same server matching the domain’s A DNS record. That means you’ll have to run the certificate generation script from your server. It’s probably not a huge deal for most small scale sites, but for larger sites or PaaS-hosted sites, it may be an issue.
There are alternate ways to get the certificates, including using a CSR to do it, so you can still use Let’s Encrypt in these cases, but the tutorial I linked to won’t be as helpful.

90 Day Certificate Expiration

Not necessarily a gotcha, but something to be aware of. All Let’s Encrypt certificates expire 90 days after issue, so you’ll need to plan for that (you can renew it programmatically). You can regenerate the certificates anytime you want, so I decided to follow the tutorial’s advice and generate new ones when the existing certificate was 30 days or less away from expiration. Obviously, the more domains you secure, the more overhead this adds, but at least it’s relatively easy to automate.

Final Thoughts

In less than 5 minutes, I had my non-HTTPS site upgraded with a brand new SSL/TLS certificate and all traffic rerouted through the secure channel. I’m really impressed it wasn’t more involved.
The security certificate seems to be trusted just fine by all of the devices & browsers I’ve tried. The fact that the certificates have to be renewed at least every 90 days is a little bit of an annoyance, but it’s easy enough to automate that I don’t really see it being an issue. Overall, Let’s Encrypt is really an awesome solution and I plan to roll it out to all of my personal/hobby sites going forward.
If you’re curious what the certificate looks like in your browser, this blog has one of my Let’s Encrypt certificates, so feel free to check that out.

Trying Out Let’s Encrypt

If you’re like me, you probably never bothered setting up a security certificate on your personal/hobby projects since there was a cost to get the certificate and some pain with actually acquiring/installing the certificate.

If you haven’t heard of Let’s Encrypt, it’s a publicly available, free, certificate authority that you can use to generate SSL/TLS certificates for any website. Now that Let’s Encrypt is available, I thought I’d give it a spin since it looked easy enough and the price was right.

Installation with Nginx

I expected the process to be somewhat painful to get signed up, get the certificate issued to my server, and get it installed. It turns out, it’s really not painful at all thanks to this nifty tutorial from Digital Ocean.

All you really have to do is install some packages with your package manager, run a simple command line command, follow the prompts, and then configure your preferred web server to use the certificate. It’s worth noting that nothing in that tutorial is specific to Digital Ocean. I prefer Linode and run everything there, but the instructions are very generic, so they should work just fine with any host.

Nginx is my default choice for a web server/proxy. Apache support is baked into Let’s Encrypt, but I’m happy to report that Nginx works just fine as well. The only real difference (as I understand it) is that you’ll need to manually or programmatically handle the renewal of your Let’s Encrypt certificates. I believe you get that taken care of “out of the box” if you’re using Apache, but that tutorial link above has a nice solution for Nginx.

The actual certificate generation & download amounts to this (see tutorial for details):
sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
sudo service nginx stop
cd /opt/letsencrypt
./letsencrypt-auto certonly --standalone

You probably noticed there was an nginx stop command in there. That’s needed for this particular install method because Let’s Encrypt temporarily uses port 80 to authenticate your server before issuing the certificate. There are other ways of doing it, but this is a super easy way to get that first certificate. In the tutorial, they explain how to automate certificate renewal and that process does not require Nginx to stop, so this is a one time per root domain kind of deal.

Gotchas

For my use case (personal & hobby sites), Let’s Encrypt works perfectly. While I was researching it, I did see a few situations where it may be less than optimal, so I’ll point them out in case they are important to you.

No Wildcard Support

You can include any number of domains in your certificate, but you must explicitly list out each one. If I wanted to get a certificate for project1.adambyram.com, project2.adambyram.com, and project3.adambyram.com, all in one certificate, I definitely could.

What isn’t allowed though is getting a certificate that covers all subdomains (*.adambyram.com). This is only an issue in cases where you have a SaaS application that generates a dynamic subdomain for each user/account.

Certificate Issuance Throttling

You may be thinking you could work around the lack of wildcard support by automating the process of getting a new certificate when you need it. The catch is that you’ll be throttled to 5 certificates per top level domain per week. I’m sure this limit is subject to change, so double check this restriction before you give up. This wouldn’t be as bad if it didn’t apply to the top level domain, but unless/until that changes, this makes using Let’s Encrypt on a service that uses dynamic subdomains a no-go.

Required “A” DNS Record

In order to verify your domain, Let’s Encrypt will check your DNS entries and verify that the server that is attempting to generate the certificate is the same server matching the domain’s A DNS record. That means you’ll have to run the certificate generation script from your server. It’s probably not a huge deal for most small scale sites, but for larger sites or PaaS-hosted sites, it may be an issue.

There are alternate ways to get the certificates, including using a CSR to do it, so you can still use Let’s Encrypt in these cases, but the tutorial I linked to won’t be as helpful.

90 Day Certificate Expiration

Not necessarily a gotcha, but something to be aware of. All Let’s Encrypt certificates expire 90 days after issue, so you’ll need to plan for that (you can renew it programmatically). You can regenerate the certificates anytime you want, so I decided to follow the tutorial’s advice and generate new ones when the existing certificate was 30 days or less away from expiration. Obviously, the more domains you secure, the more overhead this adds, but at least it’s relatively easy to automate.

Final Thoughts

In less than 5 minutes, I had my non-HTTPS site upgraded with a brand new SSL/TLS certificate and all traffic rerouted through the secure channel. I’m really impressed it wasn’t more involved.

The security certificate seems to be trusted just fine by all of the devices & browsers I’ve tried. The fact that the certificates have to be renewed at least every 90 days is a little bit of an annoyance, but it’s easy enough to automate that I don’t really see it being an issue. Overall, Let’s Encrypt is really an awesome solution and I plan to roll it out to all of my personal/hobby sites going forward.

If you’re curious what the certificate looks like in your browser, this blog has one of my Let’s Encrypt certificates, so feel free to check that out.