• Gmail Settings For Mac Mail El Capitan Dmg

By doing so, you’ll delete all mail settings, the email auto complete history (when typing an email address), and all locally downloaded mail. The latter isn’t an issue if all of your mail is stored on Gmail or an Exchange/IMAP server. The location of your stored Mail messages isn't readily apparent. They’re buried in a folder in the Library, and the archive uses a.mbox file extension. Since there may be times you want to copy your email to another computer, or even back up stored messages, here's how to find and access all your stored Mail email files.

The ability to manually configure an email account in Mail in El Capitan has been changed from difficult to almost impossible, but it still can be done.

Start by adding a new Account and use the Other account button.

• If in Internet Accounts, choose Add Other Account, then Mail Account.
• If in Mail, choose Other Mail Account, then Continue

For the username and password, just enter random characters for both (username must be in <chars>@<chars> format).

You will then have a screen where you can set the Account type and the incoming and outgoing servers.

Fill in the correct details for your account.

Originally Web posted Sunday, 3 April 2016.
Content last modified Saturday, 9 January 2021.
External links last verified Sunday, 27 August 2017.

El Capitan: Apple’s OS/Bundled Software Decline Continues (Fast Track to Unusability)

I’d like to write that El Capitan 10.11 and all the software included in it fixes exsiting bugs and does not introduce any new ones, however sadly the exact opposite is the case. If you truly appreciate full-function secure email and want to have it in Apple Mail via S/MIME, do yourself a favor and stick with OS 10.6.8 Snow Leopard (still far and away the best choice) through 10.9.5 Mavericks, until Apple gets their act together. Or, you may wish to use a different email program or perhaps add on alternate email security, such as GPG (GPGMail or whatever else). To the degree it functions, El Capitan looks and works exactly like OS X 10.10 Yosemite and looks slightly different though works like OSes 10.7 through 10.9, in terms of secure email. In fact, since the versions of Keychain Access and Certificate Assistant are identical to Mavericks 10.9, the lack of changes should be no surprise. It too continues with the revised security interface originally introduced with OS 10.5 Leopard. It even shares the same bug still in these older OSes as of this writing and adds a horrid new one in the Mail user interface. Be sure to follow these instructions carefully to work around the remaining bugs!

The following instructions have been formulated running OS 10.11.6, its Mail 9.3, Safari 9.1.2, Keychain Access 9.0, Certificate Assistant 5.0, and all current updates to these items as of 27 July 2016. They will likely work the same with earlier versions of OS 10.11 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. I truly, truly hope Apple will fix its bugs and i can update this page to remomve the disparaging complaints!

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.

Creating a Self-Signed S/MIME Certificate-key pair

1. Quit Mail, if it is running.
2. Open Keychain Access (from the Utilities folder). From its eponymous menu, select Certificate Assistant and Create a Certificate…:
   
3. Certificate Assistant version 5.0 will run. You’ll be presented with the Create Your Certificate window:
   Self Signed Root is exactly the type of certificate we wish to create. Given that S/MIME (Email) is most definitely the Certificate Type we want, one might think that it would be OK to merely verify the name and click Continue. But Apple chose inappropriate default settings, so default certificates can never work correctly! The biggest problem is that Certificate Assistant never asks for/confirms the email address, without which the certificate is useless for email! In many (but not all) cases, Certificate Assistant fails to insert any email address whatsoever into a default certificate, rendering it useless for email. Even in cases where Certificate Assistant finds one or more email addresses, when there is more than one, Certificate Assistant does not allow the user to select which one to use. Equally severe, Apple neglected to default select Key Encipherment for the Key Usage Extension, so even if the email address is present and correct in the default certificate, it cannot be used for encrypting outgoing messages… only for signing them. As of this writing, Apple has not fixed this problem, all the way through the most recent version tested, OS 10.11 El Capitan. Note that even though OS X versions 10.6 and later now contain an added layer of complexity to work around these mistakes, this added layer is not backward-compatible with older OS X versions! It is also unlikely to be compatible with non-Apple systems.

   Even if Apple hadn’t made the several errors which render 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 Let me override defaults.

4. Click Continue, and you’ll see:
   If, after reading Apple’s warning, any of you are not comfortable at this point and want to go to the trouble of paying a reliable Certificate Authority (CA) for a guaranteed certificate and following their instructions for installation, or wish to hunt around for any CAs who may be still offering free certificates for personal use (and jump through their hoops), by all means go ahead… see ya ’round! The rest of us will simply click Continue and move on.
5. Because of the necessity of overriding the defaults, you’ll now be presented with a series of detailed settings windows. The first of the series of detail windows—Certificate Information—asks you to fill in basic information:
   I have not found that the Serial Number matters, in my testing. If you think you may wind up having multiple certificates for the same user name and/or email address on one system, it is probably a good idea to ensure that the serial numbers differ (though i did not find any issues in brief testing where they were the same). I strongly recommend choosing a longer Validity Period, to minimize the hassle of re-creating a new certificate, distributing it to all your secure correspondents, and getting them to do the work to get the new one trusted on their system(s). The tradeoff with a longer time is that there is a much longer time span over which the valid certificate may be compromised by some malefactor getting ahold of your security credential set (certificate + public & private keys) and pretending to be you. I’m finding that 10 years is working as a decent compromise, so i usually fill in the box with 3652 (approximately 10 years, measured in days). Once these items are verified/set, go ahead and click Continue.
6. The second Certificate Information window asks for “personal information […] to be used in the certificate”. As discussed in the Points common to all OS versions section, the only essential item is the email address. Entering a Common Name is highly recommended, as it will make it easier to find the certificate in keychains, on backups, etc. The other items are optional. They may be filled out frivolously, though if the certificate might ever be used for other purposes or on non-Apple systems, there might be cases of failure if certain fields do not match reality (or at least expectations). Note that all this information becomes part of the certificate you’ll be sharing with the outer world.
   click Continue when finished.
7. You will now be asked to approve Key Pair Information. The defaults of 2048 bits key size and RSA algorithm are good (to the point that i did not bother testing any other options. The newer ECC option looks intriguing, but it would not be backwards-compatible with Leopard 10.5 nor Tiger 10.4 systems, and possibly not with non-Apple systems, therefore i cannot recommend it). These values are generally regarded as secure (as of the creation date of this article). 2048 bits is the largest (most secure) option for RSA on all versions of OS X from Tiger through El Capitan (and hopefully will remain compatible with newer OS X/Mail versions released in the future). I also notice that with Certificate Assistant 5.0 on El Capitan, 2048 bits is the only allowable key size option.
   Click Continue.
8. Next you’ll be offered the Key Usage Extension settings. Details for this extension are discussed on the separate page X.509 v3 Certificate Extensions. Here again, Apple made a mistake: the certificate cannot work for encrypting outgoing email messages unless Key Encipherment is selected!
   I used to recommend disabling (unchecking) “Include Key Usage Extension”, however due to changes made by Apple as of 10.12 Sierra, the Key Usage Extension MUST be included for a certificate to be valid. If you wish for your certificate to work on Sierra or newer as well as all OS X/Mail versions back to 10.4 Tiger/Mail 2, you must enable Key Encipherment (and leave Signature enabled). Once you’ve made your selection(s), click Continue.
9. Next you’ll be hit with the Extended Key Usage Extension settings:
   This one’s defaults are OK. It is OK to include it if you want, or disable it if you want—both ways work, in my testing. I tend to leave it engaged with settings as shown, in case future software starts to get picky about seeing specific usages indicated within certificates. As always, click Continue to move on.
10. The Basic Constraints Extension gets us back into a controversial area where the experts are not in agreement. Some say that this extension should always be enabled and “Use this certificate as a certificate authority” (which will appear in this window when Basic Constraints is enabled) should be checked, for all self-signed certificates. Others disagree. In my testing, i left it at its default—disabled—and things worked fine.
    
11. The last of the array of extra-work-making extensions is the Subject Alternate Name Extension (which i’ll abbreviate: SANE):
    As discussed in the SANE section of the X.509 v3 Certificate Extensions page, SANE is not required. I did a lot of testing with and without it, with no difference in results. If it is used, it is essential that the rfc822Name field include the same exact email address as listed above under Certificate Information. Normally, Certificate Assistant fills this in automatically and correctly, so all you’ll need to do is double-check it. If for some reason it shows up empty as in the screenshot above, carefully type it in, correctly: just the you@youresp.com part… nothing else. Once you’ve made your choices, click Continue.
12. Finally, Certificate Assistant will ask you to Specify a Location For The Certificate:
    The default location of the login keychain is the correct answer. When you click Continue, Certificate Assistant will now (finally) create the usual three items in your login keychain: the certificate, your public key, and your private key. See New Security Credentials part of the Points common to all OS versions section of the main article for further information.

Done!

Trusting a Certificate

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 the Certificates category 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:

Only two of these need to be adjusted, for secure email:

• Secure Mail (S/MIME)
• X.509 Basic Policy

Set each of these to Always Trust:Close the window. You’ll be asked to type in your current OS X user’s account credentials to allow Keychain Access to make the needed changes:Once that’s done, you’ll see Keychain Access showing the certificate as trusted:

Preserve Your New Security Credentials: Back Up!

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.

Other Machines?

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:

1. Place a copy of your secure email credentials keychain on the Mac. I tend to put it on the desktop.
2. Double-click the credentials keychain file. Keychain Access should open, and the keychain should be visible in the list, shown locked.
   
3. Select the credentials keychain. Select all 3 items (certificate, public key, private key) within the keychain and drag them to the login keychain.
4. You’ll get a warning that Keychain Access is attempting to modify the system keychain. (I don’t know why this is showing up since we’re dragging into the login keychain and not the System keychain, but there you have it.) Authenticate as an administrator to continue.
   
5. Keychain Access will now ask for the password/passphrase for the credentials keychain. Enter it.
   
6. The certificate and two keys will move out of the importing keychain into the login keychain.
7. The certificate is not ready for email yet. Double-click it in the login keychain. Be sure both Secure Mail (S/MIME) and X.509 Basic Policy are set to Always Trust. Close the window.
8. You will see the change to certificate trust settings window. OK the change of certificate trust settings with your current OS X user credentials.
9. Delete the credentials keychain (now empty) from within Keychain Access via the Delete Keychain option in the File menu.
   Select Delete References & Files to get rid of both the references inside the Keychain Access application itself and the actual credentials file, now empty (you did use a copy of this file in the first step of this sequence, didn’t you?). The deleted keychain might vanish immediately or remain in the list of keychains until Keychain Access is quit and reopened (no need to do that now), depending on things like permissions.
10. Quit Keychain Access. Done!

If instead of saving the 3 credential items in a separate keychain you exported each item individually, you will need to use File > Import Items… in Keychain Access on each of your backed up/archived .cer, .pem, and .p12 files for the certificate, public key, and private key, respectively.

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), 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:

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 use File > Import Items… within Keychain Access. Guess we’d better hope that the public key truly is redundant when importing!

Verify that Setup is Complete

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. It won’t look identical to this older screenshot since Apple has nicely added a bright blue color to these icons when they’re active (as on iOS, of course)—a major improvement in my opinion. 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.

Trusting Others’ Certificates

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:

Due to at least one straggling bug amazingly still in place in OS 10.11 El Capitan which was one of many also in OS 10.7 Lion through 10.10 Yosemite, 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! It looks like it works and it might possibly intermittently work for some people some of the time, depending whether Keychain Access is running or quit and likely due to other factors beyond what i can track. It can and will show the message as signed, but if you try to send an encrypted reply, no encryption for you-oooh! See “Can’t Encrypt a reply email immediately after trusting an incoming certificate”, immediately below this section. (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.

Bugs and Problems

Can’t Encrypt a reply email immediately after trusting an incoming certificate

Padlock remains grayed out, even though the certificate shows as trusted. This currently happens if you try to allow Mail to change the trust settings of a certificate.

Workaround: If you find yourself stuck in this situation:

1. Quit Mail, if it is running.
2. Open Keychain Access. Double-click the troublesome certificate (the one you received from someone else and mistakenly tried to trust within Mail).
3. Change “When using this certificate” to “Use System Defaults”. Close the certificate window to save the changes (very important), authenticating as needed.
4. Re-open (double-click) the certificate and its trust settings area. Change both Secure Mail (S/MIME) and X.509 Basic Policy to Always Trust. Close the certificate window (again) to save the changes.

Anyone at Apple wanting to look into this should check my Radar bug, #11742852. This bug was reported 25 June 2012 and as of 27 July 2016 is still not fixed, making me wonder whether 20-teens Apple ever fixes its bugs (wrote the former 1990s Apple software QA tester). It would be really nice if Apple finally fixed this bug, before Apple abandons El Capitan. Feel encouraged to send Apple feedback if you’d like to see this bug fixed.

Can’t Encrypt an outgoing email message: Can’t Lock Padlock

Many things can cause this failure, esp. in Lion and all newer OS X versions, so far. Here are the ones i know:

• Do Not change Trust settings via Mail! See the item above.
• With Lion and all newer OS X/macOS versions through (so far) El Capitan, one has to explicitly trust both the recipient’s and the sender’s security credentials in Keychain Access. Even though the message is being encrypted to the recipient using the recipient’s public key (in their certificate), i have seen a case where the sender’s Mail refused to allow the padlock to be locked until the sender’s certificate was fully and correctly trusted in Keychain Access.
• Verify that the recipient’s certificate allows for encryption. If it has the Key Usage Extension, Key Encipherment must be selected. This is not the Apple default in any version of Certificate Assistant released through 27 July 2016.

No Visible security information on incoming messages!

This appears to be a degradation of the Mail 8/Yosemite bug Incoming messages show as Encrypted, but not Signed. Here’s how it fails to work now:

1. Incoming message neither signed nor encrypted: No Security line—expected result.
2. Incoming message signed, not encrypted: Security line appears, showing Security: Signed—expected result.
3. Incoming message not signed but is encrypted: Expected result: Security line appears, showing Security: Encrypted. Actual result: No security information at all! No Security line! Identical to an unsigned, unencrypted message!
4. Incoming message both signed and encrypted: Expected result: Security line appears, showing Security: Encrypted and Signed. Actual result: No security information at all! No Security line! Identical to an unsigned, unencrypted message!

This is a critical user interface element which somehow has been working from at least as far back as Mail 2 in OS 10.4 Tiger all the way through Mail 7/OS 10.9 Mavericks. It needs to be fixed pronto!

Comments? Found an error? Let me know, and i’ll see what i can do.

Secure Email in OS X, Apple MailThe Sonically Pure Pages

Gmail Settings For Mac Mail El Capitan Dmg

This Siber-Sonically Pure Page is and Transitional compliant.