Whither Wi-Fi? Recommendations in an AirPort-less World

Today, Bloomberg Technology News released a story that heralded the death of one of my favorite products over the years, the AirPort. It is one of the few products currently available at Apple that predates my career as an Apple Admin(1). Over the years, we’ve seen a lot of features crammed into these little boxes, and I have a tremendous fondness for them overall.

My thanks to Apple for building a good, solid little box that did so much. I’ve got some recommendations that I’ve been thinking about for some time, along a couple different lines of thought:

Budget Performance

I have yet to find a device that I like more than the current AirPort Express, just in terms of what it does: Home Router, Home Wi-Fi, AirPlay speaker, remotely managed. There isn’t anything I’ve found that is as easily-managed as the AirPort line is. But there are some good options:

  • Archer C7 (<$99) – 802.11ac, 3×3:3, USB Port for basic NAS

* The UI doesn’t totally blow
* Good performance for throughput
* Good coverage for 5GHz for single-floor, drywall construction dwellings

* Not great at density
* Not very useful just as an access point
* NAS performance very limited.

* Synology UI that you like from your NAS
* Beamforming Support to alter coverage areas
* Good performance for throughput

* No USB for direct storage, meant to be used with an existing Synology NAS

Mesh Networking

In the early days of Wi-Fi, Wireless Distribution System (WDS) was an extension of 802.11g that would allow you to use Wi-Fi access points as wireless relays to expand coverage. I wrote a piece for an early edition of Make Magazine on how it works, and it’s been something we’ve used various places over the years, but mostly only when we’ve had to. Each wireless link in the chain can halve your bandwidth, and clog the airwaves. It’s a last ditch effort.

Or, it was, until some new players like eero and Luma started to dip their toe in the proprietary Wi-Fi world, and brought legacy companies like Netgear to the fight. Neither eero nor Luma carry Wi-Fi Alliance certification, but I don’t think that should be the end-all, be-all of the world. I’ve recommended both eero and Luma to clients, and some have adopted it. There are some interesting choices that they’ve made, and there are some consequences to that. Overall, these technologies share the same Pros & Cons:

* No wires required!
* iOS App Setup
* Interesting features not found in other platforms
* Works as a Router solution

* less configurable radios
* proprietary is harder to troubleshoot
* wireless backhaul is still problematic for throughput

eero 3-pack – $499
Luma 3-pack – $296
Netgear Orbi 2-pack – $397

Prosumer Wi-Fi

There are a couple of good options from the big providers of Wi-Fi for home use, too. They’re a step up in cost, but they come with a good step up in performance, too. These are all pure access points, though, they’re not routers, and they don’t have router-like options. This is all about the best Wi-Fi you can build, not AirPlay, not Routing, not remote management.

UniFi and Xclaim are the two that I see most often, and both represent good values. Xclaim is the budget line from Ruckus, and is meant to be cloud-controlled. It is equivalent to the R300 and R500, but without the 6dB of interference mitigation or any of the beamforming that make their APs my go-to on the Pro side. The UniFi APs from Ubiquiti are solid performers, but don’t carry the interference mitigation a large urban environment may require.

  • Xclaim Xi-3 ($249) – 802.11ac, 2×2:2, Made by Ruckus
  • Xclaim Xi-2 ($220) – 802.11n, 2×2:2, Made by Ruckus

* Free cloud dashboard
* Includes POE Injector
* Supports multiple SSIDs and controls
* iOS/Web configuration tools

* No beamforming or interference mitigation
* Only 2×2:2

* Good value APs
* Works with a local Cloud Key controller or AWS t1 micro instance
* Supports multiple SSIDs and controls

* Interference mitigation is a problem in dense environments
* 802.11n AP susceptible to hardware failure after 2 years
* UAP-PRO is only 2×2:2
* UAP-AC is almost $300.
* Needs either a Cloud Key or an AWS instance for best management.

Final Thoughts

The end of the AirPort is a sad day for me, I’ve probably managed close to 100 of them for clients in the last ten years, and I know we are currently supporting 25 of them in daily use. I don’t think there’s a good AirPlay option out there to replace them, sadly, so if that’s your current favorite streaming audio technology, now would be a good time to stock up on extras.

AirPort was a groundbreaking technology when it was released, and the first AirPort-capable Macs were magical in a way that we take for granted now. When people ask me what my favorite miracle of modern technology is, I reply without hesitation: Wi-Fi. Apple lead the way for a long time, focusing on building consumer-friendly products that did a lot. None of the solutions above carry with it the user-friendly function-focus of the AirPort, and that makes me sad. But, new companies like eero and Luma are making wireless do things that Apple has decided not to do, and so the future lives with them, or with the professional access point manufacturers who work down market like UniFi and Xclaim (Ruckus). I think we’re in good hands, even if they’re not Apple’s.


(1) The portables have all changed names, the mini, iPod, iPhone and iPad didn’t exist, the PowerMacs became the Mac Pro, only the AirPort and the iMac carry their original monikers. Crazy, right?

Tech Tips for a Hostile World

I’m not all the way through Kubler Ross just yet, but I’m starting to think about how to respond in a way that’s productive, engaged, and focused on reality.

I’m a tech person, so I’m gonna talk about tech things. There are people that are going to be able to talk to you about effective protest tips, effective lobbying, good organizations to send money to, and all those things. This isn’t about that.

One of the most important things in a hostile world is the ability to protect yourself, and your communications. I’m going to tackle this in a couple different pieces:

Encrypt Your Mac

In a world where the central authorities are scary, and where you might want to protect your data, it’s really important to have some level of data protection. I strongly recommend the Filevault 2 technology that’s built into macOS and Mac OS X 10.9 and later. If you have a laptop with fast storage (an SSD), you won’t notice a difference. If you have an older machine with a spinning drive, this will cause a 20% performance hit.

Your computer may have helped you turn this on already. Open System Preferences, go to Security & Privacy, and click on the FileVault tab.

You will see a message that is unequivocal about the status of your computer’s drive. If FileVault is off, turn it on.

When you turn on FileVault, as part of the encryption process, it will generate a key that can unlock your computer that is separate from your computer password. This is a failsafe key designed to get you back in if everything else has gone to hell. Your computer will offer to escrow the key with your iCloud account with security questions protecting it. You can provide security questions there, but know that any answers you give are case sensitive and will need to be provided to Apple exactly as they are written in order to recover that key.

I wouldn’t recommend this if you’re really concerned with security, though. I would strongly recommend you print a copy of that key and give it to someone you trust, or someone that is bound by contract to store it without turning it over, like your lawyer if you have one. You could probably talk to a trusted IT professional who would keep that key safe.

Use iOS’ Built-in Security

While the Black Jeopardy skit makes fun of using your fingerprint on your phone, saying “that’s how they get you,” the TouchID sensor on iOS devices – and coming soon to a laptop near you – is a remarkably secure technology. The TouchID sensor has a direct connection to the Secure Enclave co-processor on the device, which uses encryption techniques that even the FBI and NSA will have trouble working against. Your fingerprint is tied to your passcode, and without your passcode, on boot your phone will not accept your fingerprint as proof of identity.

That means if you’re in trouble, shut your phone off.

All of this advice applies only to personally owned phones. If you’re using a phone that work gave you, do not expect privacy on that device, and don’t sign into your secured services on a work-owned device. Work-related devices will often be enrolled in a Mobile Device Manager that your employer can use to clear your passcode and provide access to third parties. This is the end-around for the San Bernardino situation that saw Apple in court with the FBI. If the device isn’t 100% yours, it’s not something you should trust your privacy on.

Use Only End-to-End Encrypted Messaging

If you’re part of the overall iOS/macOS ecosystem now, iMessage is a technology that is encrypted from device to device, which means no one in the middle can decrypt those communications. When your device connects to the iMessage servers for the first time, it creates a set of encryption keys that are used in all future communications, and those keys are what keeps your communications secure. Every message is individually encrypted using those keys, and the public keys of the person you are talking with. No third party can read them. This is called end-to-end encrypted messaging.

Facebook’s WhatsApp also uses end-to-end encryption. Please be aware that Google’s Allo and Google Talk products do not use end-to-end encryption, nor does AOL’s Instant Messenger, nor is standard SMS encrypted. These are all technologies that can be warranted and searched, and shouldn’t be considered private communications.

Use a VPN

There are a lot of great options you have to protect your traffic from prying eyes at your internet service provider, or the ISPs of your favorite coffee shop or any other public place. I recommend Cloak which is $120/yr for unlimited data, and shunts your data traffic securely out to an Amazon instance. Their privacy policy isn’t perfect, but take solace in the fact that, at least for now, the FBI won’t be knocking on their door until well after the 16 day window for records expires.

There are other options for this, and I would encourage looking around. I’ll update this post with other suggestions.

Use a Password Manager

Lastpass, 1Password, the iCloud Keychain, these are all examples of password managers, designed to help you use unique and complex passwords to access your online accounts. It’s good practice to have a unique password for every service you use. Embrace this, and use a good password manager with a strong master password you can remember.

Use Two-Factor Authentication

Much as your ATM card is useless without the PIN you have memorized, if you’re using two-factor authentication (2FA), just having your password won’t be enough to get access. Your Google, Dropbox, Facebook, Twitter and other accounts can support 2FA, and if you want a step-by-side guide, there’s a good one at Turn on 2FA, and you can use that to help you. I’ve been using Authy on my iPhone, and it’s been pretty great so far.

Join Organizations That Will Fight For Your Privacy And Rights

We’re all just individuals, but when we band together, our powers for good can magnify. I strongly recommend picking some organizations to join and be part of to help fight the battle on your behalf. Here are some organizations I’ll be donating to:

You can pick your own, or join me with these three. Suggest more in the comments!

Never Surrender, Never Give Up

I’m pretty exhausted right now, and I’m not sleeping well, but I figured it might help to outline some things people can do to help improve their privacy in the face of a government that is increasingly hostile.

Because of, and in Spite of, Cupertino

After Saturday’s piece, I stopped to think more about the state of the Mac, the state of Mac IT, and the state of Apple, generally. I am left with even more confusion than I had hoped.

First, let me be upfront: I am, to borrow a title from my friend Marcus Ransom, a consulting Apple engineer. I don’t work for Apple, but I work around Apple, sometimes hand-in-hand with Apple (often their local Retail stores who have been excellent partners for us and for our mutual clients.) We’re the parties responsible for the continued operation of these machines after they leave the factory, and until they are put out to pasture. In short, I’m the guy that makes sense of how these machines are used every day, and I’ve been doing it for fifteen years.

Second, let me be clear: I have been an Mac user since I was 5. I have used a Fat Mac, Mac Plus, Mac SE/30, Mac II, PowerMac 6100/60, PowerMac 8500/120, Blue & White G3, Lombard PowerBook G3, Titanium PowerBook G4, iMac G5 and then a series of MacBook Pros, from 2010 to 2014, and Mac minis from 2009 through 2014. My bona fides here are a lifetime of machines from Apple, and probably close to $20,000 in personal dollars, and in the last four years, probably closer to 400 machines for clients, representing more than half a million dollars.

The last five years have brought incredible leaps forward in the management and development of Macs. A lot of that work came behind the scenes from Cupertino, as Apple built technologies like FileVault 2, System Integrity Protection, the MDM Specification, better Active Directory plugins, and better user tools like Photos, and expanding services (which some don’t yet trust, understandably) like iCloud. You can couple that with good, reliable, affordable hardware, that carries good extensibility, even if good expandability is no longer on the table.

But, a lot of that work came out of the community, as tools like munki, autopkg, AutoPKGR, AutoDMG, and Deploy Studio have created an ecosystem out of the gaps and hooks left by Cupertino. Other providers like Jamf, Filewave and Lanrev have built their own ecosystems out of that space, as well. Those are the pieces that are holding together the Mac in the field, those are the implementation details that Apple lacks in their complete entirety.(1) Those are the pieces that make a Mac up to $500 cheaper to support over its life.

In many ways, Apple is succeeding because the community and the marketplace are driving them to success, and the community is doing it in spite of the obstacles that Apple is placing in its path, be those increased security requirements, or be those new, less effective hardware and core software opportunities. In many ways, the community exists because they love what Apple has done in their past, the hardware, the innovation, the entire package. I don’t expect that there will be a wholesale migration to Windows, or to Desktop Linux (as funny as that might be), I can see a community that’s less enthusiastic create less imaginative tools. Less useful tools. Less functional tools.

We are where we are because of Cupertino, no question. The Macs of my youth, of your youths, represented the pirate spirit we all champion now.

We are where we are in spite of Cupertino, also. The tools we are making ourselves, or buying in the marketplace, are every bit the equal – perhaps more – of the Mac itself.

For all of my career, I have been a Mac person because of personal affinity. That affinity remains. But realizing that we are now the engine of how the Mac works instead of Cupertino, that’s the biggest shock I’ve had in ages.

The bigger shock is that it’s been true for longer than I thought. But what’s that mean?

Reading The Tea Leaves

There’s a change to the management of Macs that is coming soon, if my reading of the tea leaves is correct, that makes community-based Mac management tools and workflows much, much harder to use. If you haven’t yet, stop and read Mike Lynn’s m(DM)acOS, which lays out a lot of the ground work for the reading we’re all doing. The push toward an MDM-only future has three problems that I can see:

1) Currently, Community-based MDMs are an implementation nightmare

Right now if you want to spin your own MDM, you’re in for a world of hurt, and Apple isn’t making that process easy for you. In some part, this may represent a push toward commercial solutions like Jamf Now, Airwatch, Meraki Systems Manager, which have had the MDM Spec for a number of years. That would be fine, but for the fact that we’re now attached to two separate organizations who aren’t responsible to us.

2) Apple is then the only Gatekeeper for management

In a world where the only install commands come from mdmclient commands, you’re stuck using an MDM of some kind, and that’s going to eat into that $534 savings that Apple will be so keen to advertise at CIO/CTO forums for the next few years. Couple that with Apple’s aggressive stance toward deprecation, and the cautious admin, or the one who needs customization, is faced with a difficult or impossible future.

3) Device Management still isn’t a solved problem for the Mac

There are a lot of things you can’t set with config profiles as it stands, and there are a lot of things that admins need to deploy that can’t come in that pathway. We’re hopeful that Apple is listening to our coversation, and will respond to our Radars, but that’s far from a given.

These three problems represent the biggest challenge for the community in a generation. While IT Admin Generations are much shorter than People Generations, this is the biggest step for us since the end of fat images. It’s actually a bigger challenge, because it may involve us leaving our LaunchDaemon-based solutions behind, in favor of mdmclient commands that don’t yet exist. We’re faced looking at the edge of the known world not knowing there’s a map of any kind at the horizon.

That is both wonderfully freeing, and terribly scary. We’re about to all be explorers again.

So, What Should Happen Next?

I am just one member of the Apple Consultants Network supporting 400+ Macs. There are organizations far more likely to get responses from Apple than I, and they’re actually far more capable to determine the effective future of management, because they have whole members of their team who can be tasked to think about it.

But, if this post happens to find itself at Infinite Loop, and you wanted my advice, this is what I’d ask for:

1) Bring Back the Admin Track at WWDC. If this is the goal, take the time to enframe the vision for those of us who will be tasked to implement it. Right now there aren’t a lot of compelling reasons to go MDM-only for the Mac. DEP is a good start, but it doesn’t represent the entire spectrum of management needs. Let’s do this together, discuss it together, and bring the engineers to meet the implementors. It will be critical to your success.

2) Build Your Path With Signposts. I am very grateful to those wise voices within the Apple ecosystem who have been leaving breadcrumbs along the path. Breadcrumbs aren’t enough. Build signs, and let us help show you the sections of the path where we’re walking in the grass because it’s more efficient.

3) Focus on Building Great Software and Hardware. I’m not going to retread Marco Arment’s “Functional High Ground” argument, because I didn’t totally agree then, or now, but I will say that the number of users who have pushed back against software changes for change’s sake has been substantial, and it’s leading to questions like “What is going on over there?!” from a lot of corners I never would have expected. I know so many Apple employees who just want to build amazing things, please help them find the way toward building things that we can all use and love, even if it means slowing your pace to get them right. I don’t think I’m the first person to say this, I won’t be the last, but this isn’t iterate or die season unless you’re iterating badly.

I’ve spent ten years building our practice to support the Mac, and the last four years to programmatically support the iPad and the iPhone. I am all-in on this, and I know so, so, so many other admins and consultants and technicians who are right there on the front lines with me. We just want to make this all work, and more importantly, work well, so that we’re not stumbling about in the dark.

I know this runs against the grain of Apple’s longterm goal of producing incredible products in secrecy, showing them only when the time is right. I understand that the stock market is a weird thing that makes disclosures subject to regulation. There must be a way to innovate around these restrictions and provide good guidance toward the future without speaking in vagueries and platitudes. Please help us see this. Thursday didn’t help.

(1) Please don’t bring up Profile Manager. I still have scars. It doesn’t count.

Port Confusion

This video showed up in my Twitter timeline today:


The video is short, and the juxtaposition with Apple this week is almost painful. Apple is not the underdog it once was – and it hasn’t been for some time – and the marketing machine that was so critical to its success is now, I believe, running the show in ways that are holding back the products that it’s creating.

I no longer believe the design team at Apple is innovating to make the best product experience, rather they’re deep in “pure math” territory, exploring the boundaries of innovation itself. I feel like this can go one of two ways. One of these is a future where Apple is a pillar of the desktop and laptop community, one of these is a future where the Mac is both expensive and underperforms.

I fear that we’re heading toward the second future.

The cost equation for the Mac got a shot in the arm last week at the Jamf Nation User Conference, where IBM revealed that the Mac is substantially cheaper to support. 48 hours ago, Apple essentially raised prices on everything in the field. While the MacBook Air remains on sale, Apple is instead pushing a machine $500 more expensive as a “replacement” to that model.

Couple that with a machine that can only handle 16GB of RAM for “battery and performance reasons”, and a total dearth of desktop updates, I’m left with more questions than answers. The first one is: “Why is thinner and lighter always better?” and I can’t come up with an answer that leaves me satisfied.

In the meantime, I’ll likely line up and replace my MacBook pro, maybe buying another cable case from Skooba to hold all the extra dongles I’ll need. Don’t count me as mourning the Mac just yet, but like any friend who’s started to veer off from the path you’re taking together, I’m starting to wonder what’s up over there, and I hope I’m shown to be foolishly wrong sooner rather than later.

Deploying NoMAD with Configuration Profiles

It feels a little silly to be so excited about something so simple as NoMAD, but there’s nothing simple about NoMAD behind the scenes. It’s doing a lot of heavy lifting that you’d usually need binding to accomplish. Preventing the complication of binding simplifies your Mac environment. On the Macadmins.org Podcast recently, we spent an hour talking with Joel Rennich about just that.

We’ve now deployed NoMAD for a single site, using Munki to deploy the application bundle, but when it comes to deploying the preferences, I’ve decided to take some notes from the tea leaves being read and move my deployment strategy to take advantage of Mobile Configuration Profiles. Rusty Myers has a good meta-repository of Profiles if you’re not familiar with all the options available.

From our testing rig, where we finalized the settings for deployment, we built a good configuration. You can use the system defaults command to play out what NoMAD is setup to do. defaults read com.trusourcelabs.NoMAD will give you the entire contents of the prefs domain, but you don’t need everything from that file. This is what we took forward from that file:


Now, if you want the full payload of preferences, there is a published guide to all of the settings options.

defaults read displays the contents of the preferences file in the old MCX format, which is exactly what we need to generate a profile for upload to MDMs, or deployment directly via Munki. Tim Sutton has written an MCX-to-Profile python script that can take the contents of that file and turn it into a mobileconfig profile. Name the MCX file com.trusourcelabs.NoMAD so that the correct permissions domain is applied – or just change the name once the profile is built.


To get the profile out, we made it an update for the NoMAD installer itself, set as an unattended installation. When NoMAD is installed by Munki, it gets the profile as an upgrade in the background, installed and ready for first run. In this case, we’re using NoMAD even while bound, just to simplify the installation of an X509 identity for use with 802.1X and Cisco ISE for Wi-Fi purposes. There are a lot of good reasons to use NoMAD to simplify your world.

Five Years On: Designing IT Experiences Steve Would Have Liked

There’s a group of people in every IT Department over a certain size that are tasked with “Executive Support”, meant to interact with the high-touch execs of any company, mostly to help them deal with whatever IT policies have been put in place by a CISO or CTO to help make the company more secure, often at the cost of user experiences.

In my first IT job, I was the executive support for a particularly difficult vice president, someone who could make you feel small and useless if you didn’t have the right answer at the right moment. It was a difficult job, being in Sauron’s eye, sometimes. I imagine that working for this person was a bit like working for Steve Jobs: highly demanding, highly sensitive to bad design, highly willing to grab a flamethrower and start marching on the cubes.

I am a better IT professional today because I think to myself every time now: “How will my clients and staffers feel about this particular change?” Will the results of this change be potentially ambiguous, and thus confusing? Will this change affect their user experience? If so, can I justify that change, and present them with the information ahead of their install?

Your staff and your colleagues are counting on a user experience that is comfortable to them, and thus, changes to their environment without clear justifications (valid reasons include security, data safety, and increased functionality; invalid reasons include capricious restrictions and management without explanation) are unwelcome, unfamiliar, and will cost them productivity, and worse, their trust in you.

Your open dialog with your coworkers and clients relies on them to trust you not to mess with their user experience without providing countervailing benefits in other places. Don’t forget that. If you do, your coworkers and clients will do everything they can to undermine your position, work around your protections, and distrust you. This is not the role of good IT.

So if you do something today to mark the passing of Steve, make it something that empowers your coworkers and clients, make it be something that surprises and delights. Be there for your people, because you’d want them to be there for you. Every coworker and client deserves the level of support you give to the executives, from the office admin, to the line manager, to the C-suite. That’s what Steve’s vision of the Mac was all about. It’s our job to carry that legacy onward.

Steve Jobs by Ben Stanfield
Photo of Steve Jobs by Ben Stanfield

Exporting S/MIME Certificate Identities For iOS Use

Cryptographically-signed email is a complicated subject. There’s keys and certificates, there’s signing authorities, all of the wonderful PKI structures that allow us to communicate securely. Securely signed email is an easy way to indicate to other parties that you’re taking some precautions with your email that authenticates the sender in an end-to-end way. A typical free commercial certificate, say, from Comodo, will affirm that the original certificate creator can receive email at a given address. This allows you to sign outgoing emails, which wraps the message in a secure envelope that confirms that you are who you represented yourself to the certifying authority to be.

Generally, these certificates are commissioned on a desktop computer, like any Mac. You end up with a certificate stored in your Login keychain that Mail.app or Outlook use to sign your outgoing messages, or decrypt messages signed with your public certificate. If you open Keychain Access, select your Login Keychain, and then set it to filter by certificates, you will see your email signature.

If you want to sign email with your iPhone or iPad (and you do), you’ll need to move this certificate to your device in a way that your device will be able to work with it.


Normally, you might just drag your certificate out to the desktop and embed it in an MDM Profile, or something similar. Your certificate also contains a private key, and that is a critical element. The drag and drop method won’t work this time. What you need to do is export the certificate in .p12 format (also known as PCKS #12). To do this, right-click on the Certificate and select Export.


Pick a location for the file. I recommend the Desktop, since we’re going to be emailing this file.


You’ll be prompted to pick a password for this .p12 file. You’re going to need this when the certificate gets to the iOS device. This is what lets you securely move the certificate and private key together in a safe package.


Pick a password that you’ll remember and that isn’t just password. If your email is compromised, an attacker could take this .p12, and with suitable equipment, some good luck, and a super computing farm, sign email on your behalf, unless you revoke the certificate at the Certificate Authority. Note the password down carefully, you’ll need it in a moment.


You may be asked to allow access to the private key by the system. You’ll need to allow access in order to export. I think this step might be unnecessary in most cases. If it doesn’t present, don’t worry about it.


Now, attach the .p12 file to an email that your device can receive. Now, what follows is instructions for use with the built-in Mail app on the iPhone. There may be ways to work with S/MIME in other mail clients, but this post will not cover them.


Once you have the .p12 in Mail on your iOS device, tap on the attachment to open it. The Settings app on your iOS device will now open and you’ll go through the standard profile installation process. If you have an iOS Device that is paired with an Apple Watch, you will get prompted to pick whether you want to install the certificate on your Watch or your iPhone. You want it on your iPhone.


Keep in mind – you aren’t working with a signed standard identity certificate, but that doesn’t mean the payload won’t certify up the trust chain.



Accept these dialogs by tapping Install, and continue. You will now have to enter the password for the .p12 container that you wrapped around your certificate and private key. Enter it and tap Next when you’re ready.


Lastly, you’ll need to finalize the profile and confirm the install.


Your certificate is now resident on the iOS device, and it’s time to go turn on S/MIME in your Mail Account. Go to Mail Settings, and select your account, and then head to the Advanced Settings. Turn on S/MIME, and turn on the signing settings.


You can confirm that your identity is selected, or select which identity your device is using to sign messages, by tapping on Sign.


You can tap the i at the end of the line to review the signing identities that are configured for your account. If you start using S/MIME certificates, be ready to keep old expired certificates around in the event that you are not just signing messages, but encrypting them. Messages encrypted with your public certificate by other people will only be decrypted by that old, expired certificate and its private key.

If you want to review your S/MIME certificates, you can do so in the Profiles section of Settings. Tap on Settings, then General, then Profiles.


You can get detail on an individual certificate and see more information surrounding the certificate, which should be on your calendar.