Posted by Charles Edge on January 10th, 2015

When setting up a Bushel account, we require you to setup a certificate between an Apple ID and your Bushel account. This is a little file exchange that protects your data with Apple. No other Bushel user (and certainly not we who run Bushel) can access your secure connection with Apple. When you’re first setting up a Bushel account, you’ll get prompted to configure a certificate. That’s done by downloading a file from us and giving it to Apple (to prove our authenticity to Apple) and then downloading another file from Apple (to prove their authenticity to us).

If it seems complicated, don’t worry, it’s actually much simpler than we’re probably making it out to be – so we’ll walk you through it now. From the first Bushel screen, you’ll see some basic instructions. Here, click on “Download Plist file” and a file will by default download to your Downloads directory.

Screen Shot 2015-01-08 at 2.54.21 PM

Once downloaded, click on the Go to Apple Certificates Portal button and login using an Apple ID. Now, at some point, the company will need to renew this file (because certificates expire) and someone will need to login. We therefore recommend using what we call an institutional ID to do so. This ID uses an email address from the company but isn’t tied to an individual user. For example, you might use bushel@domain.com if your email domain were domain.com to setup the account with Apple. Once you’ve got an Apple ID you’d like to use, login using that Apple ID and click on Create Certificate.

Click on “Upload plist” and then choose the certificate in your downloads directory. Once create, you’ll see a confirmation screen. Click on Download.

Screen Shot 2015-01-08 at 2.44.25 PM

Once downloaded, go back to Bushel and click on the bottom button for . Upload Push Certificate.

Screen Shot 2015-01-08 at 3.00.56 PM

You’ll then have a dialog to select the certificate, which is the one you just downloaded from Apple. Once uploaded, click Continue and you’re all done. Happy Busheling!

Posted by Charles Edge on January 7th, 2015

Apple Mobile Device Management (MDM for short) is a means of distributing data and settings to iPhone, iPad, iPod Touch and OS X. Using MDM, you can push email, security settings, apps, app settings and even content through devices. Bushel uses Apple’s MDM to push these to Apple devices. There are some limitations and misconceptions, so here are 5 things you should know about how Apple Mobile Device Management really works:

  1. Your data doesn’t route through Apple. All Push Notifications do route through Apple, but the data in these is small and minor. For example, if you use Bushel to push an email account to a device, the email settings (which are otherwise easily attainable on the Internet) are applied to a new email account on a device; however, the mail password never flows through that connection. The Push notification that goes through Apple only indicates there is a setting on the Apple Mobile Device Management solution, the Mobile Device Management suite sends the settings and then the person using the device provides the password, building in at least 2 layers of security between Apple and the password.Unknown
  2. You cannot change the background of an iOS device through MDM. Apple doesn’t allow changing the background of a device except using the device itself. You can restore a backup to a lot of devices to get a consistent background on devices, using Apple Configurator or iTunes. But no MDM solution can mass change backgrounds of iOS devices.
  3. You must have your own APNS certificate. The hardest part of setting up a Bushel account is installing your Apple Push Notification certificate. We know this. But installing a Push Notification Certificate, and renewing it when it expires is necessary for all Mobile Device Management suites.
  4. If you send a VPP app to a device from any Mobile Device Management solution then that app is removable. If you send a web-clip then whether it’s removable is optional. If you remove the device from the Apple Mobile Device Management solution then the app will always remove. The web-clip will remove only if it’s been set to being removable.
  5. All devices added to an Apple Mobile Device Management solution through DEP devices are supervised and can only be unsupervised if you remove the device via DEP. DEP is one option to enroll but there are many others if you don’t need users unboxing and setting up their own devices.

There are hundreds of other little factoids out there about MDM. But these are the most common questions we’ve gotten recently!

Posted by Charles Edge on August 8th, 2014

Hopefully you don’t need to know a thing about this stuff. But in case you do, here’s some information about the important ports that we use to communicate with Apple.

Apple Push Notification Servers (APNs) are how devices communicate with Bushel. Apple provides a special platform for us to communicate with devices through their servers, known as a Mobile Device Management (MDM) Application Programming Interface (API). Similar to how you know you can trust apps available on the App Store, the MDM API is one way you know that the data you store with us is as safe as can be.

Communications between devices and servers and servers and devices occur through TCP/IP. TCP/IP uses ports for communicating between all this stuff. The ports that we use include the following TCP ports (and therefore you may end up needing to open these ports at some point to Apple’s addresses ( if you’re showing this article to your firewall admins):

  • 443: Fallback port (since it’s pretty much always globally open anyways)
  • 2195: Sends notifications to the APNs via gateway.push.apple.com
  • 2196: Sends feedback to the APNs via feedback.push.apple.com
  • 5223: How iOS and OS X devices communicate to APNs servers using the MDM API)

Posted by Charles Edge on August 8th, 2014

You can do some pretty simple testing to Apple’s APNS of ports and network communications using strategies I’ve outlined in the past with tcpdump, trace route, telnet, curl, stroke and of course ping. These are classic ways to test connectivity to servers. However, netcat has a few interesting things you can do with it; namely actually run a port super-quickly to test traffic between subnets, forcing scans of ipv6 traffic, debugging sockets, keeping connections alive, parodying through SOCKS 4 and 5 and just checking for daemons that are listening rather than actually sending data to them.

In this first example, we’re going to just check that Apple’s web server is accessible (adding -v for verbose output):

/usr/bin/nc -v www.apple.com 80

The result would be pretty verbose

found 0 associations
found 1 connections:
outif en0
src port 50575
dst port 80
rank info not available
TCP aux info available

Connection to www.apple.com port 80 [tcp/http] succeeded!
HTTP/1.0 408 Request Time-out
Server: AkamaiGHost
Mime-Version: 1.0
Date: Tue, 29 Jul 2014 15:41:34 GMT
Content-Type: text/html
Content-Length: 218
Expires: Tue, 29 Jul 2014 15:41:34 GMT

Request Timeout

The server timed out while waiting for the browser’s request.

Reference #2.48cf4d17.1406648494.0

If we added a -w to timeout we’ll cut out all the cruft (but wouldn’t know that the server’s at Akamai). Next, we’ll get a little more specific and fire up a test to check Apple’s push gateway at, using port 2195:

/usr/bin/nc -v -w 15 gateway.push.apple.com 2195

But, I want the cruft for the purposes of this article. Next, we can add a -4 to force connections over IPv4 and check the Apple feedback server and port 2196, also required for APNs functionality:

/usr/bin/nc -v -4 feedback.push.apple.com 2196

Right about now, something is probably happening at Apple where they’re getting sick of me sending all this data their direction, so let’s add a -z option, to just scan for daemons, without actually sending any data their way:

/usr/bin/nc -vz -4 feedback.push.apple.com 2196

Because of how NAT works, you might notice that the src port keeps changing (incrementing actually). Here’s the thing, we’re gonna’ go ahead and force our source port to stay the same as our destination port using the -p option:

/usr/bin/nc -vz -4 -p 2196 feedback.push.apple.com 2196

Now, what if this is failing? Well, let’s spin up a listener. I like to start on my own subnet, then move to another subnet on the same network and ultimately to another network so I’m checking zone-by-zone so-to-speak, for such a failure. So, we can spin up a listener with netcat in a few seconds using the -l option on another host:

/usr/bin/nc -l 2196

Then I can scan myself:

/usr/bin/nc 2196

I could also do this as a range if I forgot which port I used per host:

/usr/bin/nc 2195-2196

Now, as is often the case, if our connection problem is because data isn’t parodying, we can also use nc to check that using the -x operator followed by an IP and then : and a port. For example:

/usr/bin/nc -vz -4 -w 10 -p 2196 -x feedback.push.apple.com 2195-2196

Fun times with push notifications. Enjoy.

Posted by Charles Edge on August 8th, 2014

At first glance, Apple Push Notification services seem pretty darn complicated. Luckily, we’re all about demystifying technical things here at Bushel. So let’s take a moment to look at what happens when an Apple Push Notification transaction occurs. In this example, we’re going to look at using our tool to send some command to a device, like enforce a passcode policy. Now, you send this passcode enforcement in what is known as a profile. That’s just a way of saying some code that tells the device to enforce a passcode policy. That transaction of sending the profile might seem like it’s as simple as just send the code from the server to the device, but the server doesn’t communicate to the device, the device communicates to our servers.

Under the Hood

So here’s what’s really happening behind the scenes:

▪ You create a policy
▪ The policy gets saved into a profile
▪ The fact that there’s a profile change gets communicated from us (the Provider) to Apple’s Push Notification Servers, or APNS.
▪ When the device checks into APNS (over port 5223), it gets what Apple calls a token. The token is an anonymized bit of data that doesn’t actually know what is being sent in the profile. This is key as it means that Apple themselves never know what policies you’re sending you to your devices.
▪ Once the token is received, the device checks in with us, the Provider.
▪ We send the command to the device. This could be a profile change, sending an app to a device, a lock command, unlock command or even a device wipe.
▪ Once the device gets the command we sent, the device processes the command, letting us know the result of the command.

OK, so it’s a little complicated. But not technically, just logistically. Luckily, you hit a button and we handle all the other stuff. But if you’re ever curious about what we’re doing under that hood, now ya’ know!