OpenSSL commands that came in useful today

When nginx -t complained about a certificate/key mismatch this afternoon, I first assumed that the problem was on our end during our automated CSR/key generation or our certificate request process. I took a closer look at all three pieces to look for the source of the error using “The Most Common OpenSSL Commands“:

openssl rsa -in example.test.key -check

The info from the key check was pretty unhelpful, but it was a valid key. See the section below for how to better compare that.

openssl req -text -noout -verify -in example.test.csr

The CSR check was somewhat helpful as I was able to verify that the correct domain name and other request information was in place.

openssl x509 -in example.test.cer -text -noout

The certificate check was most helpful as I was able to diff the results of this with the results of a working certificate. This showed me that nothing was off and all data was formatted as expected, just different.

I turned to searching for the verbose error instead.

Via “SSL Library Error: 185073780 key values mismatch“, I used these commands to compare a certificate and private key to see if they were indeed not matching:

  • openssl x509 -noout -modulus -in example.test.cer | openssl md5
  • openssl rsa -noout -modulus -in example.test.key | openssl md5

Each of these generated an md5 hash that I was able to compare. In my case, the error reported by nginx -t was correct and the certificate generated by Comodo did not match my private key. I double checked this by comparing a working certificate/key pair that resulted in matching md5 hashes.

Bah. This is nice because it’s likely not our fault. This is not nice because now we have less control over fixing it. 😞

I do have a set of commands that may come in useful again. 😃

A Method for Managing Mixed HTTP/HTTPS Sites in Multisite

This is a brief rundown of the method we’re currently using at WSU to manage mixed HTTP/HTTPS configurations in a multi-network WordPress setup.

Our assumptions:

  • Sites that are HTTP (HTTPS optional) on the front end should be forced HTTPS in any admin area.
  • Some sites should be forced HTTPS everywhere. This may be because of form inputs or because it’s a nice thing to do.
  • New domains may not immediately have certificates. We can measure risk and provide brief HTTP admin support—usually with trusted users on a wired network.

To force HTTPS in admin areas, we use the WordPress constant FORCE_SSL_ADMIN. To determine whether this can be enabled, we start with the assumption that it should and then check for a stored option attached to the currently requested domain telling us otherwise.

<script src=””></script>

A bit further down, we use this information to actually set the constant.

This option is managed through our WSUWP TLS plugin, which tracks new domains and allows non server-admins to start the process of CSR generation and certificate upload. Once the domain goes through the entire process and is verified as working, the foo.bar_ssl_disabled option is deleted and admin page loads will be forced to HTTPS.

While the domain is going through this process, it will be accessible via HTTP in the admin, though the cookies generated on other sites will not work as they are flagged as secure. There’s probably some stuff I’m not aware of here, which is another reason to keep this very limited. 😬

Forcing HTTPS everywhere is much easier, as we can redirect all HTTP request for a domain to HTTPS in nginx (or Apache). At that point, we’ll set siteurl and home for the site to HTTPS as well so that WordPress generates HTTPS URLs for everything.

Screen Shot 2015-04-24 at 9.21.18 AM

I love that screenshot.

In a nutshell. Assume all admin requests are HTTPS, but have a config flag that allows you to offer temporary HTTP access. If a domain can be forced HTTPS everywhere, then handle that in the nginx/apache config.

Great WordPress Meetup showing off 4.2 tonight

Two more months and the Pullman WordPress Meetup will be a year old! This is our 3rd release oriented meetup, so we’ve been around since the old days of 3.9.

WordPress 4.2 and more!

Wednesday, Apr 15, 2015, 6:00 PM

Sweet Mutiny
1195 SE Bishop Blvd #1 Pullman, WA

7 WordPress Superfans Went

WordPress 4.2 will be released at the end of April. We can walk through what’s new during the April meetup.A second presentation may fit as well, let’s talk about that during the February meetup.

Check out this Meetup →

We timed tonight’s meetup perfectly with the release of WordPress 4.2 RC1 and I was able to show off each of the new features to the group. There was some fun conversation throughout.

I think the new Press This interface got the best immediate reaction. It’s especially nice for those who have never experienced it before and much better as a new interface to those who hadn’t.

Extended character support for 🍕 was definitely next. It’s nice to talk about improved global support for WordPress in addition to the joy we get from expressive food characters. 😜

Plugin updates are a little hard to get excited about in a meetup environment, but the interface (or lack of redirect) did perk some ears. I know I love not being bounced to a new screen.

I also covered—possibly for the first time—a general overview of the WordPress release cycle and how things have matured over the last couple years. I think covering that along with the various methods to contribute should be good recurring topics, even if they don’t fill up the entire night.

This is what happens when I can’t fit “tonight was a great meetup” into 140 characters. 📜

First thoughts on our new

Today we launched a gorgeous new home page at WSU. For the most part everything went as planned and definitely without catastrophe. We’ll have a full stack write-up at some point soon on with more details (still a few more things to launch), but I’ve had a few thoughts throughout the day that I wanted to note.

Screen Shot 2015-03-24 at 11.24.01 PMWe’re HTTPS only. And that’s pretty freaking cool. It was a year ago today that we flipped the switch on WSU News to SPDY and ever since then I couldn’t wait to get the root domain. I had anticipated some push-back, though I don’t know why, and we haven’t heard a peep. I plan on running a script through a massive list of public university websites to see how many do this. Many don’t even support TLS on the home page, let alone force it.

Screen Shot 2015-03-24 at 11.28.24 PM

Our root domain is on WordPress. Typing that address in for the first time today after everything went live felt really, really cool. I don’t think that feeling is going to wear off. Even though this is site ~600 to launch on our platform, it’s a huge statement that the University is behind us on this. I don’t remember all of our conversations, but I don’t think that having the root on WordPress was really on our radar for the first 2 years. Dig it.

We’re pretty damn fast. That’s become a lot easier these days. But we have a lot of content on the home page—and a really big map—and we still serve the document to the browser super quickly. I actually screwed up pretty big here by microcaching with Nginx at the last minute. It made things even faster, but cached a bad redirect for quite a while. Lessons learned, and we’ll keep tweaking—especially with image optimization, but I love that we went out the gate with such a good looking waterfall.

And as I stormed earlier in my series of “I heart GPL” tweets, every part of our central web is open source. We publish our server provisioning, our WordPress multi-network setup, our brand framework, our themes, and our plugins. 134 repositories and counting. Not everything is pretty enough or documented enough, and will often serve more as an example than as a product. But, everything is out there and we’re sharing and doing our best to talk about it more.

Lots of this makes me happy. More to come! :)

Wired on Drone Geo-Fencing

“This is NOT something users want,” another critic added. “I have a good relationship with my local airports and have worked with every local tower or control center. I get clearance to fly and they have been great, but this ‘update’ takes away my control.

”Ryan Calo, a University of Washingtonlaw professor who studies robots and the law, traces the resistance to two sources. “One is a complaint about restricting innovation. The second one says you should own your own stuff, and it’s a liberty issue: corporate verses individual control and autonomy,” Calo says. “When I purchase something I own it, and when someone else controls what I own, it will be serving someone else’s interest, not mine.”

Source: Why the US Government Is Terrified of Hobbyist Drones | WIRED

Intersections of technology and government regulation are interesting.

When a piece of technology is so small and cheap, it’s easy to apply personal ideas of how you should be able to interact with it. At some level it make sense to compare geo-fence restrictions on drones to DRM on e-books. But really, it’s not the same concept at all.

When something is large and expensive, such as a private plane, then it’s probably easier to agree with (and understand) restrictions on where you can use it. The same thing applies to cars—just because I own a vehicle doesn’t mean I can drive it down a one way street or onto private property without consequence.

Academic publishing and scholarly communication: a status report | Harvard Magazine Jan-Feb 2015

That price pressure from commercial journal publishers highlights the core conundrum of academic publishing: the conflict between the scholarly ideal of universal, open sharing of information, and the economic model of business: to make money by selling things.

Source: Academic publishing and scholarly communication: a status report | Harvard Magazine Jan-Feb 2015

Various Networking Configurations in VVV

I dug in to some different configurations in VVV today and decided to write them up as I went. This will be posted in some form to the VVV wiki as well. There are other networking configurations available in Vagrant, though I’m not sure that any would be useful in development with VVV.

I would recommend using default settings for initial provisioning as things can get quirky inside the VM when trying to access outside sources. Run vagrant reload to process any network configuration changes.

Private Network (default) :private_network, ip: “”

This is the default configuration provided in VVV. A private network is created by VirtualBox between your host machine and the guest machine. The guest is assigned an IP address of and your host machine is able to access it on that IP. VVV is configured to provide access to several default domains on this IP address so that browser requests from your host machine just work.

Outside access from other devices to this IP address is not available as the network interface is private to your machine.

Port Forwarding “forwarded_port”, guest: 80, host: 8080

One option to provide other devices access to your guest machine is port forwarding. Uncommenting or adding this line in VVV’s Vagrantfile and then running vagrant reload will cause any traffic on port 8080 directed at your host machine to instead communicate with port 80 on the guest machine.

This configuration will work with private or public IP configurations as it deals with port forwarding rather than the IP of the virtual machine itself.

An immediate way to test this once configured would be to type your host machine’s IP address into a browser followed by :8080. With port forwarding enabled, something like would bring up the default VVV dashboard.

Of course, this doesn’t do you much good with the default WordPress sites, as you’ll be stuck adding port 8080 to every request you make.

The easiest hack around this is to setup port forwarding on your router. Point incoming requests for port 80 to port 8080 on the IP address of your host machine. Requests through the router will then traverse ports 80 (public IP) -> 8080 (host) -> 80 (guest) and your development work can be shared with devices inside and outside of your network.

Say my router’s public IP is and my computer’s local IP is

  • Enable port forwarding in Vagrantfile.
  • Configure router to forward incoming port 80 to port 8080 on
  • Visit on my phone, connected through LTE.

There are other things you can do on your local machine to reroute traffic from 80 to 8080 so that it forwards properly without the use of a router. Sal Ferrallelo has posted steps to take advantage of port forwarding directly in OSX using pfctl.

Public Network “public_network”

Replacing our default private network configuration with a public network configuration immediately provides access to other devices on your local network. Using this configuration without specifying an IP address causes the guest machine to request an address dynamically from an available DHCP server—likely your router. During vagrant up, an option may be presented to choose which interface should be bridged. I chose my AirPort interface as that is what my local machine is using.

==> default: Available bridged network interfaces:
1) en0: Wi-Fi (AirPort)
2) en1: Thunderbolt 1
3) p2p0
4) bridge0
5) vnic0
6) vnic1
    default: What interface should the network bridge to? 1

Once the guest machine receives an IP address, access is immediately available to other devices on the network.

  • vagrant ssh and type ifconfig to determine the IP address of the guest – mine was
  • Visit on my phone, connected to the wireless network.

To me this is most desirable as it provides access to devices on the local network, not to the outside. If you are using public wifi or another insecure network, be aware–this does open your machine up to other devices on that network. “public_network”, ip: “”

The same configuration would be available without DHCP by specifying the IP address to use. If you know what subnet your network is on, this may be a shortcut for providing access without having to use ifconfig inside the guest machine.

Science for the People!

Partly inspired by the experience, BSSRS staff member David Dickson later wrote in New Scientist magazine calling for “Community Science Resource Councils”. The idea, which sadly never took off, was a sort of scientific equivalent of legal aid. It would have provided scientific knowledge and technical expertise to minority and under-represented groups, and also allowed them a greater chance to shape what questions get asked and answered by science. “Perhaps the greatest gain would be in public education,” he wrote. “Members of the community would be able to answer back.”

People today often call for evidence-based policies, but the problem is that the power to collect evidence isn’t evenly distributed. In the 1970s, BSSRS worked to change this – and build a science for the people.

There are some fun parts to this story, which was passed to me in an internal email thread today. Especially great in the context of land grant universities.