Links for PFS, DH, DHE, and ECDHE and SSL in general

So many acronyms.

I have many tabs open right now that I’m about to close and I’m not great at bookmarks. Here are some of the things I’ve been reading while trying to figure out PFS in SSL.

And I just bought this book: Bulletproof SSL and TLS


Managing the Environment

This is a brief companion post to the talk I gave yesterday for Web Conference at Penn State 2014. The tagline for the conference was “the future friendly web”, and the talk covered how this web can be created with rapid, incremental improvements with defined workflows around version control, provisioning, deployment, and testing.

It’s a bit interesting that the talk links on the conference site don’t have dates in URL. Let’s see if that web remains future friendly. :)

Thanks to everyone that attended the talk, hopefully there were some good takeaways. Please reach out if you have any questions about any of this.

Slides: Managing the Environment – Web Conference 2014

Useful links from the presentation:


Figuring out how to serve many SSL certificates, part 2.

I’ve been pretty happy over the last couple days with our A+ score at SSL Labs. I almost got discouraged this morning when it was discovered that LinkedIn wasn’t able to pull in the data from our HTTPS links properly when sharing articles.

Their bot, `LinkedInBot/1.0 (compatible; Mozilla/5.0; Jakarta Commons-HttpClient/3.1 +`, uses an end of life HTTP client that happens to also be Java based. One of our warnings in the handshake simulation area was that clients using Java Runtime Environment 6u45 did not support 2048 DH params, something that we were using. I’m not entirely sure if LinkedIn has their JRE updated to 6u45, but I’m guessing that anything below that has the same issue.

I generated a new 1024 bit dhparams file to solve the immediate issue and reloaded nginx without changing any other configs. LinkedIn can now ingest our HTTPS links and we still have an A+ score. :)

Figuring out how to serve many SSL certificates, part 1.

In the process of figuring out how to configure SSL certificates for hundreds (maybe thousands) of domains in a single nginx configuration without a wildcard certificate, I decided it would be cool to use `server_name` as a variable in the nginx configuration:

`ssl_certificate /etc/nginx/ssl/$server_name.crt;`

Unfortunately, per this aptly named request on Server Fault—nginx use $server_name on ssl_certificate path—that’s not allowed.

Nginx docs explain it more:

Variables are evaluated in the run-time during the processing of each request, so they are rather costly compared to plain static configuration.

So with that, I’m going to have to generate a bunch of `server {}` blocks that point to the correct certificate and key files before including a common config. I can’t find any examples of this yet, so I’m still wondering if there’s a better way.

I’m about to create a repository named something like WSUWP-P2-Common that contains all common P2 related plugins and/or themes for use throughout the WSUWP ecosystem.

It’s purpose will be more of a built package rather than a development area. Development will still occur in individual repositories. When releases are pushed in those repositories, they can be deployed to the central package repository as well.

I feel like I’m reinventing the wheel though and that if I understood Composer enough, I could use that. But then part of me doesn’t care if I’m reinventing the wheel because it will just work with our current deploy process without much effort.

I also wonder if this is better of as a private repository. I guess if we run into a plugin that isn’t GPL compatible for some reason, we can create a separate repository for WSUWP-P2-Common-Private, but I’m hoping that isn’t the case.

If this works as a model, we’ll likely have other “package” repos in the near future for other sites.

2013-07-07 14.15.17

v1.1 of Varying Vagrant Vagrants has been pushed

This is a smaller release in the grand scheme of things, though the first (!) as a new organization. The milestone has been ready for several weeks now. Thanks goes to Aaron Jorbin for prodding it along. :)

Quite a bit has been stable since v1.0, so we’re in a good spot to make a couple big changes in the next release including PHP 5.5.

From the changelog:

  • Transition to Varying Vagrant Vagrants organization.
  • Add a CONTRIBUTING document.
  • Add --allow-root to all wp-cli calls in VVV core.
  • Use a new global composer configuration.
  • Add zip as a package during provisioning.
  • Introduce a helpful caveats section.
  • Remove tcp_nodelay config in Nginx. Reasoning in 0cce79501.

As always, feel free to stop by and open an issue if there’s something you’d like to see!


A Varying Vagrant Vagrants Organization

This is a very transformative moment for the Varying Vagrant Vagrants project.

About a week ago, I reached out to Jake with a proposal to move VVV from under the wing of 10up to an organization of its own. We’ve been cruising along for just over a year, have around 125 unique visitors on the repository a day, and have a nice regular community of contributors. We have received pull requests from just around 40 contributors (!!!) and the issues are constantly a lively place of discussion.

Jake immediately agreed and we were able to talk through the process and the future very quickly. 10up has been a gracious and excellent host for VVV this entire time—the farewell post is great—and I’m looking forward to future steps we can take as a community now that we’re on our own.

I’d like to think that the goal to bring Vagrant to the forefront of WordPress developers’ minds has been accomplished. Through VVV and other related projects, the use of a development environment that closely matches production has come a long way.

I do think that VVV is the best tool out there for contributing to WordPress core. We provide stable, trunk, and develop versions of WordPress and everything needed to run the Grunt build tools and PHPUnit unit tests.

With that in mind, I think we should be able to line up a few goals.

  1. Continue being the place for a WordPress core development environment. This primarily means that we stay on top of the tools that core introduces into the development flow. Providing an approachable way to use these tools and documentation will go a long way.
  2. Directly related to goal one, some of the advancements we make should be around testing multiple versions of everything. If we can make it easy to fire up a PHP 5.x environment and test Nginx or Apache with WordPress 3.x or 4.x, that would be amazing.
  3. VVV has an excellent method for auto site setups. Over time we’ve had some nice demand for a few that could help quite a bit. It would be great to see a couple that provide basic setups for WordPress multisite and WordPress under Apache rather than our default of Nginx.
  4. Bring other tools to the forefront of WordPress developers’ minds. It may be great to see versions of VVV that harness Salt, Puppet, or Chef rather than the bash scripting that we’ve forced upon the project so far. VVV has an opportunity to be a learning tool for all of us in exploring methods of testing, provisioning, and deployment.


So please chime in with any suggestions that you may have. I’d love to toss the keys to a few new repositories over to anybody that’s interested in building out new tools. Feel free to use the main VVV repository under the Varying Vagrant Vagrants organization to open an issue and discuss your thoughts. We can split things off as needed.

Over time we’ll get more organized and setup a more official forum for discussions as well as some contributing guidelines. I’m going to reach out to a few regular contributors and get them added as committers. We also need to spend some time with licensing to see if we can get away with GPL for everything or if another would be more applicable to the work that we’re doing.

That’s that. Thank you all for being so great. Here’s to the next year of VVV. :)


VVV Turns One

A year ago yesterday, I decided I wanted to break up with MAMP.

A year ago today, the Varying Vagrant Vagrants repository was created after an exciting couple nights pounding away at a server config that allowed me to troubleshoot WordPress in Nginx on a local virtual machine.

Since then, VVV has had almost 750 commits from 36 contributors (!!!) on 121 pull requests. The project has been forked 135 times, has 61 watchers and 440 stars.

What a pretty cool year it has been.

Did I mention 36 contributors? On an average of about once every 10 days, somebody decides that VVV is interesting enough to stop what they are doing and submit a pull request containing an improvement.

This blows my mind. Thank you all.

Version 1.0

And now we’ve reached our 1.0 release, which brings us one of the coolest features yet thanks to a wonderful effort from Weston Ruter and Simon Wheatley.

Auto Site Setup

Auto Site Setup allows for projects to be picked up automatically by VVV with custom web structures, host names, Nginx configurations, and provisioning scripts. If you dig into the wiki page explaining how to get started, you’ll get an idea of how powerful it can be.

From a project version control standpoint, it’s fun to geek out about how this came together through a pull request of a pull request of a pull request.

Vagrant Up Just Works

For quite a while, if you ran `vagrant up` on a machine that had been halted, you would also have to run `vagrant provision` in order for all of the services to start up properly.

Version 1.0 is so much happier.

At this point `vagrant up` just works and your workflow can start to match exactly what is expected of a machine that is powered off rather than actually destroyed.

As a side effect of this change, we now copy our config files to the virtual machine from mapped drives on the local machine rather than symlinking them. This may cause some confusion at first if you’re used to changing the configs and having them immediately reflected, but it makes a lot more sense from a provisioning and state management standpoint. This is where `vagrant provision` can be used liberally to reapply any changed config. Commit 1fbf329 contains a more detailed description of the decision and the implementation.

Other Changes

  • Begin implementing best practices from Google’s shell style guide in our provisioning scripts.
  • Databases can now be dropped in phpMyAdmin. Pro-tip, drop database wordpress_develop in phpMyAdmin followed byvagrant provision clears your for reinstall.
  • Allow for dashboard-custom.php to override the default dashboard provided by VVV


We’re still moving forward. Check out the 1.1 milestone report on GitHub to see what’s in store for the next version and feel free to jump in with pull requests or questions. As part of a greater community of Vagrant users in WordPress, there is also a newer WordPress and Vagrant mailing list that has had some activity. Feel free to stop by and ask any questions there as well.

Vagrant Error in OSX: There was an error while executing `VBoxManage`, a CLI used by Vagrant for Controlling VirtualBox

I got the following error earlier in OSX when launching my powered off VVV instance with `vagrant up`:

There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below.
Command: ["hostonlyif", "create"]

Stderr: 0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to create the host-only adapter
VBoxManage: error: VBoxNetAdpCtl: Error while adding new interface: failed to open /dev/vboxnetctl: No such file or directory
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component HostNetworkInterface, interface IHostNetworkInterface
VBoxManage: error: Context: "int handleCreate(HandlerArg*, int, int*)" at line 66 of file VBoxManageHostonly.cpp

I was able to fix this by running the following:

cd /Library/Application\ Support/VirtualBox/LaunchDaemons/
sudo ./ restart

This reset the services used by Virtualbox and allowed Vagrant to talk correctly to the virtual interfaces again. My guess is that this would help solve related errors as well, not just the one that I received.