Originally Web posted Monday, 10 September 2018.
Content last modified Thursday, 17 September 2020 .
External links last verified Monday, 10 September 2018.
After a pleasant respite with 10.12 Sierra with Mail’s security indicators finally once again working correctly, Apple managed to bung things up for High Sierra. So much for the alternate year’s macOS release being a bugfix year! As well, other bugs remain. Hopefully this article will help you whack through them and get some good use out of Mail in High Sierra (or you could just stay with/revert to/move to Sierra). The High Sierra experience mostly looks and works like OS X 10.10 Yosemite and 10.11 El Capitan, and macOS 10.12 Sierra, with some minor user interface changes, such as squishing down the button bar inline with the window “stoplight” dots on incoming emails in separate windows, as was already the case in Mail 10 for Sierra for outgoing message forms. Even though the major version number of Certificate Assistant is identical to Mavericks 10.9, the build number is different, and for the first time in a long time, Keychain Access gets a new major version.
As with macOS versions since 10.12 Sierra, Mail 11 and the security infrastructure in macOS 10.13 High Sierra require the Key Usage Extension (KUE) to exist and be properly filled out for there to be any hope of S/MIME to work in Mail. If your existing certificates have the KUE, you’re good to go—and if you’ve been successfully using secure S/MIME email in Mac Mail in macOS 10.12 Sierra or newer, this is already true for you. If you’ve used this set of articles after August 2017 to make your self-signed certificate, you’re good. If you followed the instructions on this series of articles in the past (through end of August 2017) recommending omitting the KUE and have been living in a pre-Sierra Mac universe, you’re hosed: you need to make new self-signed certificates with a proper KUE.
The following instructions have been formulated running macOS 10.13.6, its Mail 11.5, Safari 11.1.2, Keychain Access 10.0 (55237.50.3), Certificate Assistant 5.0 (55174.50.1), and all current updates to these items as of 4 September 2018. They will likely work the same with earlier versions of OS 10.13 and its components, but i never tested those earlier versions. These instructions will probably continue to apply to any later updates as well, though versions newer than those listed above have not been explicitly tested by me.
These instructions assume you already have at least one working email account set up and properly operating in Mail (in the usual insecure manner of standard Internet email). If you don’t, please go set it up and test it now, following Apple’s/other’s instructions.
Even if Apple hadn’t made the absent email address error which renders a default certificate useless for secure email, the default lifetime for the certificate is set for one year. Most people will find renewing their certificate each year—and getting all their correspondents to renew it as well!—a huge hassle not worth undertaking. For all these reasons, be sure to check.
Your public and private keys need no further attention—they’re ready to run. All they need to do is sit there on your system and work.
In Keychain Access, looking at your login keychain, double-click your newly-made certificate. You can select thecategory in the lower left column to filter out items in the main window frame which are not certificates, to make it easier to find. Click the arrow next to the word Trust just below the certificate icon, and the trust options will be revealed. Here’s what they’ll look like at first:
Now is the time to back up your new certificate, public key, and private key, archive them, or both!
Please see Backing up your new security credentials on the common page for all the step-by-step details.
As discussed in the Sharing One Set of Credentials with Other Machines part of the Points common to all OS versions section of the main article page, one set of email security credentials should be used on all devices you own.
The easiest and possibly best way to do this is to place a copy of the keychain you made with your 3 security credentials on each device and import the items from there. Here’s how it works moving these credentials to a different Mac:
If instead of saving the 3 credential items in a separate keychain you exported each item individually, you will need to usein Keychain Access on each of your backed up/archived .cer and .p12 files for the certificate and private key, respectively. Don’t bother exporting the public key (.pem) for S/MIME usage, as it’s more work, is not needed, and you’ll only get an error message.
Due to bugs in Keychain Assistant (and/or the security infrastructure) for OS X all the way from Tiger through Lion (at which point i ceased testing this individual item method), then again when i tested Sierra (have not tested since), during my testing the certificate went in to the new system just fine, but there was an error message for both the public and private keys (i only tested the private key on Sierra, and the wording may not be identical, but is close):
The private key went in despite this error message; the public key did not. This problem occurs whether i double-click the file in Finder or usewithin Keychain Access. Thankfully the public key truly is redundant, and the private key does import despite the error message!
This completes the setup for your email security credentials at your end. Quit Keychain Access. Launch Mail, and open a new message form. If all is well, you should see a new pair of icons in the lower right part of the header area, just above the white message body area:
Yours may or may not look like the screenshot: your seal may have an x in it instead of a checkmark. If you have more than one email account and the currently-selected account in Mail is not the one for which you just created security credentials, both icons may be grayed out. As long as you see these two icons in some form (gray, black, or blue, selected or not selected), you have successfully completed setup. The final step is to exchange certificates with your correspondents.
When you first receive an email message with a new, self-signed certificate, Mail will not be able to trust the certificate and will alert you to this fact, first with a banner:
One very interesting thing about this banner is thebutton: This message has no remote content! This is an exciting new bug introduced in OS 10.13 High Sierra. You will only see this if you’re a punctilious privacy person and have disabled in Mail’s Viewing preference panel. If you see this, go ahead and click the Load Remote Content button, then you should see the same thing without that button:
Due to at least one straggling bug amazingly still in place in OS 10.13 High Sierra which was one of many also in OS 10.7 Lion through 10.12 Sierra, do Not do Not do Not go through the process of showing details and eventually trusting the certificate from within Mail—it’s broken and it doesn’t work! Actually as of High Sierra, it’s a different bug which at least fails so spectacularly that everyone knows nothing has improved. Specifically, as soon as one lets Mail try to fix the problem, nothing has changed: the signature is still untrusted. Going back and looking at the security settings show them reverted to defaults. Indeed, letting Mail attempt to “fix” a certificate’s trust can break the trust settings that may already exist! See “Mail offered to change the Trust Settings to fix the problem and Didn’t, or Made Things Worse!” below, for more information. (If you want to see what it would look like if it did work, go to this section on the page in this series of articles for OS 10.6 Snow Leopard.)
Quit Mail and follow the same instructions above to use Keychain Access to trust the certificate, as you did previously for your own.
Yes, Gaaaaaaaah! is a suitable response for this new-in-High Sierra icky Apple bug. Until they fix it, consider downgrading to macOS 10.12 Sierra, or work around the problem by always tapping/clicking the spurious and extremely misleadingbutton. At that point, one of two things will happen:
For case #1, you’re all done, other than sending feedback to Apple regarding how awful, unnecessary, and annoying this bug is!
For case #2, there actually is almost certainly something wrong. Quite likely, you’ve hit one of Apple’s other bugs related to secure email. Most likely, you or someone accepted Mail’s kind and generous offer to take care of fixing trust settings, which hasn’t worked properly for about a decade now (since OS X 10.6 Snow Leopard and its Mail, keychain, and certificate systems). Even if the symptom is different, try the workaround under Mail offered to change the Trust Settings to fix the problem and Didn’t, or Made Things Worse!, 2 items below here. (There are also screenshots down there, showing the buttons discussed both there and here.)
If you’re quite sure no one on your local Mac in the current OS user account has let Mail touch any trust settings, consider reviewing the certificate trusting procedure.
Note that this bug is only triggered by message signatures, signed with the sender’s public key. Receiving an encrypted message sent by someone else encrypted with your own public key does not trigger the bug. Most people most of the time both sign (with their own public key) and encrypt (with the recipient’s public key), so this is going to show up often.
People who leave the Mail Viewing preference forchecked (enabled) will not see this problem. They also will be much less private and easily traceable, for whose emails they’ve opened when (those using invisible pixels and other stealth tracking arrangements). It’s sadly ironic that the security-minded people most likely to uncheck this box and experience this bug are the very same people most likely to set up S/MIME and expect it to work.
As of macOS 10.12 Sierra and all macOS versions released since, Apple changed the security requirements Mail 10 and later consider acceptable for a properly formed S/MIME certificate. On the older OSes and versions of Mail, it did not matter whether the Key Usage Extension (KUE) was present or not. Now it matters. Unfortunately if your existing certificate lacks a properly filled out KUE (signature and key encipherment checked), it cannot be made to work with Mail 10 in OS 10.12 nor any newer version released to date, including Mojave. You will need to create/obtain a new certificate with a proper KUE. As of end of August 2017, i have updated the older pre-Sierra OS/Mail pages with the currently-correct KUE information, with the Sierra and later pages having the correct information since initial release, to help with the process. The good news is that your new cert will not only work on the newer macOS versions, but will work all the way back to OS X Tiger 10.4.11/Mail 2.1.3, like your old KUE-less one used to.
As of the moment, the Extended Key Usage Extension (EKUE) remains optional, as does the Subject Alternate Name Extension (SANE). It may not hurt to leave them at the Certificate Assistant defaults, which don’t harm anything and look legit moving forward to the future, in case either or both become requirements later on.
Allowing Mail to change the trust settings of a certificate has not worked correctly since OS 10.6 Snow Leopard, and as of 10.13 High Sierra, things have gotten worse (see earlier OS articles for what used to happen on those).
No matter what is going on with security, when you first open an email message with a signature, as described in the first item in this section, you will always see this banner:
Per the first bug listed in this section, always, before doing anything else, tap the button. You may still see this:
It’s OK if you want to look at the details, but do not under any circumstances use the handy and extremely broken checkbox Mail gives you to fix the problem. This would be very elegant if it actually worked, but as noted, it hasn’t ever actually worked except in the OS 10.6.x Snow Leopard series (and maybe in early 10.5.x Leopard before Apple totally 100% broke S/MIME in that OS).
The bottom line is that Mail cannot be trusted to modify certificates. If you find yourself needing to make changes, you must make them in Keychain Access if you want things to work properly:
Anyone at Apple wanting to look into this should check my Radar bug, #11742852. This bug was reported 25 June 2012 and as of 1 August 2020 is still not fixed, making me wonder whether 20-teens 2020s Apple ever fixes its bugs (wrote the former 1990s Apple software QA tester). The new bug for the spurious Load Remote Content issue was 44211476, which was closed as a duplicate of 40092662 which i’m not allowed to see because that one’s not my bug, though it too appears to be closed and things are not working.
It would be really nice if Apple finally fixed these bugs, before Apple abandons High Sierra… Sierra… El Capitan… Yosemite… Mavericks… (etc. sigh etc.). Feel encouraged to send Apple feedback if you’d like to see these bugs fixed.
Many things can cause this failure, esp. in Lion and all newer OS X and macOS versions, so far. Here are the ones i know:
Comments? Found an error? Let me know, and i’ll see what i can do.