Originally Web posted Monday, 15 April 2013.
Content last modified Saturday, 9 January 2021 .
Without question one of the greatest challenges in terms of real-world usage of secure email is getting your correspondents to set things up on their end. People are busy and have other interests, and may not share your personal desire to securely exchange email messages unless you make it dirt-easy for them.
Fortunately, Apple seems to have considered precisely this situation! They’ve built in some very nice abilities into their Certificate Assistant software, allowing you to become your own Certificate Authority (CA) and create viable S/MIME email security credentials on behalf of other Mac users—securely and remotely—with little effort on their part.
Unfortunately, Certificate Assistant and Keychain Access and the whole security infrastructure remain a buggy minefield of GOTCHAs. I’ve done the best i can (as an uncompensated volunteer documenter) to find, track, and test various functions, but there are simply too many possible ways of doing things and too many bugs which i find hard to reproduce to provide you an iron-clad, guaranteed path to success. What lies below is my best effort, with all the workarounds i could find.
Warning: Serial Numbers Matter when you’re your own Certificate Authority! I found out the hard way that Certificate Assistant and Keychain Access will not allow more than one certificate from a given CA to share the same serial number—including the root CA certificate.
Be certain you keep track of serial numbers for all certificates issued by your CA! By default, copies of certificates you create for others are placed in your own default keychain (except in OS 10.4 Tiger), so right there we have the potential for massive conflict!
Certificate Assistant’s counter for tracking serial numbers lives in its configuration file ([Name of CA].certAuthorityConfig). The counter intermittently counts when defaults are overridden when making certificates from this CA in Certificate Assistant, on a version-specific basis:
Any certificates made with defaults overridden may not increment this counter! For this reason, carefully track all serial numbers on all certificates made by Certificate Assistant as a CA. You may need to re-do a certificate which pops out with an already-used number, overriding defaults or manually incrementing the counter in the .certAuthorityConfig (Plist format) file.
Warning 2: Back up your entire macOS before experimenting with this in macOS High Sierra, Mojave, or Catalina. There exists a bug which can create a Certificate Authority certificate which cannot be properly trusted and cannot be removed. If you get yourself into this bind, you’ll have to either go really deep into Terminal Land (e.g. Super Duper User), or revert to your backup from before you started playing with making a Certificate Authority in any of these affected OS versions. (It would be kind of you not to ask me how i know this.) While backing up is always a good idea, it’s far less dire a problem on OS 10.12 and earlier.
There is an option (default disabled) to “Create a CA web site”. This might be useful if you’re able to set up a secure website and plan to distribute certificates to a large number of people. I did not test this option.
There is also an option to “Sign your invitation”. This option will ensure that invitation emails you send out will be signed with one of your own pre-existing certificates (if you have any), so recipients will know that it came from you and was not altered in transit. Note that it is not an option to use the CA certificate itself for this purpose, as it has not yet been created. Even though it is shown selected in the screenshot, i do not recommend using this option. (I’ve found what i think is a better method, which i’ll explain below. You’ll sign, but not via this checkbox option. This option might also prevent interoperation with older OS X versions predating its existence, based upon limited testing i did.)
Note that issues new in macOS 10.14 Mojave and ongoing 10.15 Catalina make attempting to send an invitation email an exercise in futility. More exciting?: Certificate Assistant with these same OS versions insists on an email address in this window, even though it’s unusable for this purpose.
For greatest compatibility with other systems, i suggest using the defaults of 2048 bit Key Size and the RSA Algorithm. Actually, unless you’re only working with 10.13 High Sierra and newer systems, you will have to stick to 2048 for RSA when acting as a CA rather than each person doing self-signed certificates. If you’d rather use ECC, you may step one additional OS version back to 10.12 Sierra, but no further. These limitations are because the keys are actually generated on the end user’s system, so if it is an older OS, the older OS’s Certificate Assistant, Keychain Access, and Mail limitations all apply (mostly the first of those Cert. Asst. limitations).
Confused? Consult Key Size, Algorithm, Security, and Compatibility Considerations for S/MIME in Apple Mail Mac to ensure your choice will be compatible with and possible to implement on the macOS versions you wish to cover. Start with the Certificate Assistant Key Generation Options Chart to ascertain the capabilities of the older system, then check both the Keychain Access Ability to Utilize Chart and the Secure Email in Mail Chart to ensure there are no Fail indications for the key length and algorithm you wish to use (or if there is one, do your own testing if you want to try to work around it).
If you intend to use one certificate for the CA and as an end-user certificate for S/MIME email, you will need to selectif you choose to use this extension, as is the case for individual self-signed certificates, or omit this extension entirely (no longer recommended, since Mail for Sierra requires a valid S/MIME KUE). (I did very little testing omitting the KUE entirely for a CA certificate.)
You may leave it at its defaults or disable the EKUE entirely, as you wish. As of this writing, i find no particular benefit to either option (tested only between various Macs running various OS X and Mail versions). As of about 2018 i stopped testing omitting the EKUE: Apple has repeatedly included it as the default, so whether or not it is required today (or recently), it likely will be required in the future. My testing since this time always included/includes the EKUE.
There is a button to CA-Initiated Email, below, and in the next item., which opens up the Finder window with the CA settings file and certificate. This window is the same for Certificate Assistant 2.0 for Leopard through Cert. Asst. 5.0 for Mountain Lion and newer to date (example just below. Tiger has a more primitive version of the same idea, also discussed below). On all versions except Tiger, if a website was set up for the CA, the button will be enabled. Also on non-Tiger versions, there’s a button, which shows the content of the new CA certificate. Finally, and potentially most usefully, there is a button to (says “Mail Configuration File…” on Tiger Certificate Assistant version 1.0). This option will be discussed further in the section
Certificate Assistant successfully creates (except on Tiger) both the settings configuration file and the .pem (Privacy Enhanced Mail) certificate file in the default location:
~/Library/Application Support/Certificate Authority/[folder: name of CA]
which, for the Finder screenshots below, is literally:
~/Library/Application Support/Certificate Authority/Monte the Mountain Lion CA
Tiger (in my testing) creates the following:
~/Library/Application Support/Certificate Authority
successfully puts the settings configuration file in that folder, but fails on its promise to put any sort of CA certificate into this folder. See Version Quirks below for additional information.
On OS 10.5 through 10.12, assuming you checked the “On this machine, trust certificates signed by this CA” when setting up the CA, you should be all set. Verify this by opening up the CA’s certificate (in Keychain Access) and checking the trust settings. Apple’s default is to Always Trust for every possible option. If yours is not set this way, make this change now (or if you have specific needs/goals, make changes as you require). If you neglected to check that box during setup or intentionally did not do so because you’re on High Sierra or newer and being wise, you will definitely need to make this change manually before continuing. At this point it is safe even in High Sierra and newer (tested through Catalina), which will trust it only for this specific macOS user account, which in my testing will work properly.
Due to severe bugs, Tiger users will need to do the dance of putting a copy of the CA root certificate in the X509Anchors keychain, using the same method as for self-signed certificates on that OS. The Trust settings override options in Tiger are virtually nonfunctional in my experience.
I am finding some severe bugs in the keychain infrastructure on the newer OSes prior to 10.13 (confirmed in Mountain Lion) whereby failing to selectduring CA setup may lead to a situation where the CA root certificate will not function properly. I have yet to find a workaround for this bug, which unfortunately blocks certificates from working on the system(s) where it happens.
If you have multiple Macs and you use these other Macs for CA work and/or use that same email address for everyday secure email and/or you will be corresponding with other people for whom your CA issues certificates on these other machines, you’ll want to move a copy of your CA credentials (or at least the certificate) over to these other systems and trust the certificate on them. Check out the section “Other Machines?” on the self-signed certificates page for your particular OS X version for details. The same information applies as for self-signed certificates + their matching keys.
If a self-signed certificate user fails to adequately back up their credentials (certificate and private key at least, though also saving the public key is advised), they’re only screwing themselves over. A Certificate Authority is screwing over not only themselves but also all their users. Don’t… use a sane, reliable, redundant backup arrangement. If you’re not up to it, you might want to re-think acting as a CA.
It is up to each end user to back up their own credentials, though you should back up the piece you have on your CA system (other than Tiger): each of their signed-by-you certificates. They’ll still be screwed if they lose their private key (and their correspondents are using encryption on messages sent to them), but since that key is normally not on the CA’s system, it isn’t strictly your problem. Use your discretion for family/small business situations where you may want to take on the additional responsibility of backing up your users’ private keys, and be sure that if you do this you do so very securely!
The mechanics are identical to what is needed for self-signed certificates. Please refer to the Back Up! section of the main article.
It is possible to create one certificate which can be utilized as both a CA and end-user S/MIME email certificate—and in fact Certificate Assistant for 10.14 Mojave & 10.15 Catalina force this, whether you want it or not. I have read in the past (and didn’t save the sources so can’t cite them here) that it is unwise to have one certificate do both: it is better to keep the CA and end-user functions separated, in separate certificates. My vague recollection is that this prevents cross-contamination, such as the CA certificate going down in flames (and taking with it all certificates it has ever signed as well as itself) if it somehow becomes compromised, possibly related to its secure email or other functions. There may also be an argument regarding granularity of certificate ability permissions. In any case, for the purposes of this section i’m assuming there exist one or more good reasons to separate the functions.
Of course, if you’ve previously created your own self-signed certificate you may continue to use that. However if you’re just getting started with secure email and hoping to have many people participate with you making certificates for most or all of them, it will be easier on everyone to have your own S/MIME secure email user certificate be either your CA root certificate or a “leaf” (derivative, subordinate) certificate of your Certificate Authority.
Please note that i’m distinguishing a user’s CA function from their personal daily use of secure email. I’ve learned over the course of testing that letting the CA have a full set of secure email credentials in its own root certificate makes the process easier for setting up other users of the CA. If that is all that this particular user identity does, there may be no need to make one’s own secure email user certificate. Or, if the person acting as CA is using only one email address for being CA and in their everyday life, adding another certificate for the same email address is likely to only confuse OS X and its bundled software, so it is better to just use the CA root certificate for both functions. If there are different email addresses the person uses as CA and in their daily life, given the vague memory of the un-cited references i recommend creating a certificate separate from the CA certificate for non-CA secure email uses. If you fall in this latter category, read on and make a separate leaf certificate for your (distinct) daily use email address. If you fall in one of the other two categories (single email address for CA only or CA + daily use) or you have the misfortune to be doing all this under macOS 10.14 or 10.15 (most recent tested; may still apply to newer versions) where you have no choice in the matter, skip this section and just use the CA root certificate you already made for both CA and everyday secure email purposes.
The procedure is mostly similar to, yet slightly different from, creating one’s own self-signed certificate. Whenever you see me type “the usual” and rather terse information below, this procedure exactly matches the self-signed procedure. You’ll be able to see full details with (usually) OS-appropriate screenshots in the Detailed Setup Information section of the main article, for your particular OS version.
This is a great way to go when your correspondent is too far away for easy in-person contact—as long as neither you nor they are using 10.14 Mojave or 10.15 Catalina (maybe newer). For these OS versions, any time Certificate Assistant is run, the items created Must be saved to disk rather than emailed directly from Certificate Assistant. See Endless spoked wheel wait indicator in Certificate Assistant: endless loop! bug details below.
Here are the detailed steps for OS 10.8.3 Mountain Lion and its Certificate Assistant version 5.0 and Mail 6.3 (in places interacting with OS 10.4.11 Tiger, Mail 2.1.3, and Certificate Assistant 1.0 acting as the CA):
One might think that if the
Instead, manually create an email message to your correspondent(s), sign it with your CA certificate, and be sure to attach the configuration file (file suffix .certAuthorityConfig) inside the folder with the name of your CA (full path is at the end of the section above).
If you’d like to use Apple’s invitation message text but didn’t save a draft, here it is (corrected to say “double-click”). Be sure to fill in your actual CA’s name in place of [the placeholder text box, like this]:
The “[name of CA goes here]” Certificate Authority is now available to accept certificate requests from you. Double click the attachment and the Certificate Assistant will guide you through this process.
CertificateSigningRequest.certSigningRequestThe CA sees the Issuing Certificate Authority window:
People acting as CAs need to pay careful attention: there is a bug in some versions of Certificate Assistant (confirmed on versions 2.0, 3.0, and 4.4) whereby the CA’s copy sometimes generates a new, spurious set of user keys along with a certificate in the CA’s keychain. The CA’s Certificate Assistant should only generate a new user certificate (in the CA’s keychain and in an outgoing Mail message form). If you the CA see a pair of new user keys appear in your own CA keychain on this step, please immediately detour to User Certificate Fails to Work and/or CA Certificate Assistant Generates Spurious User Keys.
Note that in this process, the user’s (remote correspondent’s) private key is generated on their own system via their own Certificate Assistant utility program, using the CA’s configuration file initially emailed. Their private key never leaves their system and remains secure. Clever!
If the CA followed the instructions carefully and everything went well, the CA’s certificate should have been provided to the user via the initial email invitation, when that message was sent out signed with the CA’s self-signed root certificate. Or, if not on the initial message, perhaps the one conveying the newly-signed certificate. Assuming this happened and the user trusted the incoming CA certificate on their system, the process is now complete at both ends. Remember that it will be necessary to Quit Mail (all OS X versions to date, and maybe maybe not the newer macOS-named versions—try it!) and restart it before secure email options appear.
If the CA failed to send out a properly signed invitation, or if the recipient user had reasons not to trust the certificate (maybe they were not expecting the invitation, which could come from anyone) or had trouble trusting it, the user will have to obtain the CA’s root certificate (if they don’t already have it) and trust it on their system. Because the CA certificate is not yet in the user’s system or is not yet trusted, they will see a warning on their own certificate regarding its being signed by an unknown CA:
Apple’s original intent (judging from Help file content and other explanatory text) appears to have been that the CA would make its certificate available on a secure server of some kind. Seems to me that the main issue with sending a CA certificate via email is knowing whether it actually came from the CA, and whether or not a “man-in-the-middle” may have modified it. This same situation arises with individual self-signed certificates and i propose the same solution:
This verification procedure is discussed further in the main article section ID Verification. (The main article discusses two-way verification. It is only necessary to one-way verify the CA certificate for the setup procedure we’re describing here.)
The final step is the user manually trusting the CA’s certificate on their system. Follow the steps for your particular OS version, same as for a self-signed certificate, other than CA root certificates are normally trusted for all abilities, in case the CA issues a user certificate for other/additional functions.
It is not necessary for an end user to receive an invitation from a CA with a settings file as the first step. It is entirely possible for the end user to use their copy of Certificate Assistant to create a key pair for themself, generate a CSR, and send it to the CA (if they have the CA’s email address) or via some other means (if they don’t have the CA’s email address). We’ll cover each of these cases, starting with the first.
Once again, with feeling: because late 20-teens—2020 Apple apparently likes to break their own software, anything involving 10.14 Mojave or 10.15 Catalina (and possibly later) cannot involve Certificate Assistant emailing anything. Y’all need to skip this option and move down to Method 3 below.
It may be the case that an end user knows of a Certificate Authority (CA) but does not have their email address or for some reason wishes not to use email to convey the CSR to the CA—or as in one of my testing cases with earlier versions and perpetually every time in 10.14 Mojave and newer (tested through 10.15 Catalina), Certificate Assistant may/will fail on the emailing out step, requiring a workaround. All versions of Certificate Assistant provide for this scenario as well. The procedure in this case is very close to that described above, for email submission of the CSR to the CA.
Whichever method is used to generate end-user correspondents’ security credentials, they have the same need as you to ensure that they don’t lose them. Especially their private key, without which they cannot decrypt and read existing encrypted email messages sent to them!
Unless you have secure remote access to their system (in which case this whole credential-making procedure could be handled many different ways), you’ll need to count on them to follow the same steps as users of self-signed credentials do, discussed in the main article, to back them up. Or, make that long-overdue in-person visit and fix that garage light while you’re there!
I successfully tested the full process from CA invitation through installation and testing of a new user CA-signed certificate between each version of OS X from 10.4.11 Tiger through 10.8.3 Mountain Lion, in both directions (in other words: with each OS taking a turn as both CA and end user)—all 20 combinations. In all cases the process worked correctly.
Given the changes in security credential handling in Mail 10 for macOS 10.12 Sierra, i retested between it (as the CA) and OS 10.4.11 Tiger. Again, the process worked correctly. Presumably this “longest reach” test covers the intermediate OS and bundled software versions too.
While they were busy breaking their own software, Apple made sure that in addition to having 10.14 Mojave and 10.15 Catalina (and maybe newer) incapable of full CA functionality within the same OS version, they’d break the ability for 10.4 Tiger to work. Nothing new: the same issue with Tiger Mail crashing when opening a signed email sent from these newer OSes, covered in the respective 10.14 and 10.15 self-signed certificate sections. Theoretically backwards-compatibility exists to 10.6 Snow Leopard, though my testing of this was minimal and perfunctory, not extensive. Minimal basic tests did work correctly.
Certificate serial numbers matter for your own CA-generated certificates—all of them, including the root CA certificate! Track them and do not duplicate them in any certificates issued by your CA. Failure to mind this point is likely to lead to failure of Certificate Assistant to successfully create or install some certificates. See the note near the page top for more.
I saw one case where Certificate Assistant 1.0 for Tiger could not open a Certificate Assistant 5.0 settings file. Yet when i tested this combination later, it worked fine. I did not thoroughly re-test (i need to get back to the rest of my life), but my suspicion is that the configuration file which could not be opened may have been due to that file being signed by the CA using the handy checkbox during CA setup.
Now, my understanding is imperfect. I thought that the checkbox during CA setup would not affect the configuration file itself, but only what happens in Mail such that the outgoing message is signed or not signed. I’ve seen a couple of configuration files with “garbage” in them before and after the properly formatted Property List content. I do not know whether this is intentional or a bug.
In my testing, if the configuration file from the CA is a clean Property List file with nothing preceding nor following the <?xml…>… </plist> content, it should work correctly.
Testing between Certificate Asssistant 5.0 on OS 10.11.6 El Capitan between two different user accounts on the same Mac. I created a CA in a user account which already had a working self-signed certificate for email. The CA’s certificate did have a different serial number, but the same email address. Going against my own advice, i sent out an invitation straight out of Certificate Assistant. When the other OS X user attempted to run the configuration file, they got:
I spent about 20 minutes trying to find a workaround, coming up with nothing other than the same thing which i figured out years earlier during the first observation: ignore what the CA sends and have the non-CA user send the CA a CSR (see below).
Same deal as for El Capitan, other than the CA’s email address differed as well as the serial number, so there should have been no conflict whatsoever. Identical error message as above when the client attempted to open the CA-sent configuration file.
To avoid this issue, i strongly recommend:
If the CA’s configuration file simply won’t work, have the user ignore it and use thecommand in their version of Certificate Assistant. I’ve not yet seen that fail to work.
There is a bizarre show-stopping bug experienced with some versions of Certificate Assistant (2.0 for OS 10.5 Leopard, 3.0 for OS 10.6 Snow Leopard, 4.4 for OS 10.7 Lion, 5.0 for OS 10.11 El Capitan, and a variant described below for 5.0 for OS 10.15 Catalina) and likely existing in all Certificate Assistant 2 through 5 versions through at least Catalina: Usually only on the first run with a newly set up CA (esp. for Snow Leopard) when the CA runs the user’s CSR, the CA’s Certificate Assistant generates a spurious new pair of user keys on the CA’s system along with a certificate to match those keys—not the keys already (securely) generated on the user’s system by their Certificate Assistant. Sometimes Certificate Assistant presents an error message that the new user’s certificate cannot be placed into the keychain as it is a duplicate!
Fortunately, there is a workaround:
This is a very difficult bug to reproduce on the earlier OSes (Leopard through Lion)! In my Snow Leopard testing, once Certificate Assistant for the CA starts working correctly, it continues to do so unless the whole OS X installation is blown away and installed fresh, or at least all user accounts on the Mac and existing CA-related email messages (on the email server[s]) are blown away AND caches are wiped out. Then on another day the first certificate of the session failed in this way even though it was an existing installation which had previously been working (but the workaround still worked). On 10.5 Leopard it happened with the second CSRequest. 10.7.5 Lion did this to me once under circumstances not in any way noticeably different than the other 3 times i did the (probably not literally) exact same thing with the very same CA installation with no problems whatsoever.
The good news is that, up through Yosemite, whenever this bug occurs, no matter what OS X version, the workaround described above (trashing the bogus cert. and keys and re-running the very same CSR a second time) has succeeded. Even so, keep reading: there’s something you really ought to check on all OS X/macOS and Certificate Assistant versions.
As of OS 10.11 El Capitan, what had previously been intermittent became continuous, failing to yield to the prior workaround. I found a reproducible case where the failure keeps going, even after trashing the spurious keys and certificates. As with the User’s Certificate Assistant Fails to Work with CA’s Configuration File bug (previous one here) a corrupted CA.certAuthorityConfig file triggers this bug. To avoid problems, ensure that your CA’s config file is OK before issuing certificates. This is discussed soon below, after the Summer 2020 OS 10.15 Catalina addendum.
The bug is still with us as of Certificate Assistant version 5.0 (55188) supplied with OS 10.15.6. Thankfully there is a difference, which in this case i’ll call an improvement: the client Certificate Assistant notices the damage and throws an error:
This is an improvement because with older versions, the client Certificate Assistant would blithely proceed to create a CSR, and then the CA Certificate Assistant would generate the spurious keys and useless certificate. Not as good as things working correctly, but at least we know there’s a problem. You’ll note that this is the same error as for the User’s Certificate Assistant Fails to Work with CA’s Configuration File immediately above. They may be the same bug with different symptoms depending upon conditions and software versions.
I learned during testing that having the client fix the damaged CA.certAuthorityConfig file (discussed below) is not a good idea: the CA’s system no longer wants to accept it. This is entirely reasonable. The CA should fix the .certAuthorityConfig file on their own system.
In terms of how this file gets messed up in the first place, i have a new theory, which i am not going to test (unless someone compensates me in a manner satisfactory to me): this happened when creating a CA when that entity already had a self-signed non-CA S/MIME certificate and keys in their login keychain. Note that the serial numbers differed and the email addresses differed, so those aren’t the problem. This pre-existing certificate was the one Certificate Assistant offered and user-confirmed selected for emailing out the config file to the client (which never happened because of the Mojave and Catalina can’t send email endless loop bug). Anyone who wants to test this should try the following:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>BasicConstraintsPresent</key> […] </dict> </plist>
0Ä *ÜHÜ˜ †Ä0Ä 10 +0Ä *ÜHÜ˜ †Ä$ÄÇt<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"><dict> <key>BasicConstraintsPresent</key> <integer>0</integer> […] </integer></dict></plist>†ÇB0Ç>0Ç&† 0 *ÜHÜ˜ 0C1 0 UZyla10 U US1%0# *ÜHÜ˜ email@example.com 160727191319Z 170727191319Z0C1
Note that i forced a few line wraps in the corrupted example above, to prevent this page from trying to display too wide. The original is even messier! For presentation here, all kinds of control characters have been replaced with spaces. As well, firstname.lastname@example.org is a placeholder for a legitimate (uncorrupted within itself) email address i do not wish to share here.
In my summer 2020 testing of Mojave and Catalina, on Catalina the plist was properly formed other than garbage quite like the example above both before and after the formal XML. Manually editing the file in TextEdit, deleting all the garbage and leaving only a clean, well-formed plist file resolved the issue, which on the test system was the client’s Certificate Assistant’s inability to even open the configuration file.
Anyone internal to Apple who may be reading this might consider checking out my bug on this issue, Radar #13665874.
I encountered at least one case with Mountain Lion 10.8.3, Certificate Assistant 5.0, Keychain Access 7.0, and Mail 6.3 whereby Mail refused to acknowledge the brand-new user certificate right there in the CA’s account, even though Keychain Access showed everything was just fine and dandy and i’d quit and restarted Mail several times (to refresh its outlook on certificates—the only way i know). Interestingly, Certificate Assistant’s “Evaluate a Certificate” function claimed there was no root certificate found for the new user certificate:
I stumbled into a workaround by accident: When i added the CA self-signed root certificate to the list of certificates to be evaluated in Certificate Assistant, BOINK!—everything started working. Certificate Assistant now showed “Evaluation Status: Success” and Mail now happily accepted the new user certificate (after a fresh start of Mail).
Unfortunately, another time this happened (and i don’t recall which OS), Certificate Assistant temporarily showed that everything was fine when both the root and user certificates remained in its evaluation window, but after any sort of logout or restart or maybe even quitting Certificate Assistant, the failure returned.
I have not found a workaround/fix. This problem occurred when i failed to select “On this machine, trust certificates signed by this CA”, and attempted to trust later in the standard OS X user account, apparently triggering this failure.
The author of this site had no idea what PhoneGap Build even was until i looked it up. Between that and having never touched Apple’s Developer Console, i believe the safest course of action is for me to quote relevant parts of his submission in its entirety:
For the past 10 hours, I’ve been struggling with PhoneGap Build’s iOS error “Certificate doesn’t match profile: The default keychain doesn’t have an identity matching”, but I have a solution!
My Mac’s OS is version 10.8.5, and my KeyChain is version 7. After following the instructions in the Be Your Own Certificate Authority article [this one —Sonic], I opened Apple’s Developer Console. I used Apple’s Console to create a Certificate and a Provisioning Profile. Finally, I created a p12 file using the Certificate I created following the instructions in the Be Your Own Certificate Authority article; please note, this final process was not a part of the instructions – but a process I picked up in the past from working on previous iOS apps.
The solution is to create your p12 file by using KeyChain to export the Certificate created by Apple’s Developer Console. KeyChain version 7 will display Apple’s Certificate with a warning/error message, stating “This certificate was signed by an unknown authority”. This can be ignored.
If you’re like me, when you saw this warning/error message, you used unnecessary caution, and created your p12 file by using KeyChain to export the Certificate created in the Be Your Own Certificate Authority article. Again, the caution is unnecessary.
As I had mentioned before, ignore the warning/error message “This certificate was signed by an unknown authority”. Create your p12 file using the Certificate you created in Apple’s Developer Console. PhoneGap Build will accept the p12 and Provisioning Profile created from the Developer Console Certificate. That’s it! I will be posting a much briefer version of this solution on PhoneGap Build’s forum only, since this situation originates in PhoneGap Build.
Changes in the security infrastructure lead to a disconnect between system-wide trust and individual macOS user account trust: trusting a Certificate Authority’s self-signed certificate created by Certificate Assistant at the system level prevents individual macOS user accounts from being able to trust that very same certificate. I’ve found no workaround. Further, i found it impossible to remove the system-level certificate via the Mac GUI, even from the admin macOS account (which is the only place where i could even see the certificate in the System keychain). Do not accept Certificate Assistant’s kind and generous offer to have it have the OS trust the new certificate authority’s certificate for all users of this Mac! Instead, each user must trust the CA’s certificate individually, using the usual methods.
Welcome to The Decline And Fall Of Apple, or at least macOS. Something changed, likely in the security infrastructure, such that whenever Certificate Assistant attempts to get Mail to send a message on its behalf, the process never completes: Certificate Assistant gets stuck in an endless loop waiting for Mail to respond/finish, but Mail never even gets into forming a human-visible outgoing message. Whatever else is supposed to happen at that point happens: certificates are created, etc. It’s the email step that’s broken and unusable. The workaround is to a) ensure that the certificate or whatever has actually been created and is in the expected location then b) Quit Certificate Assistant. A normal Quit works fine; no need to force quit. If you need to email, manually create an outgoing email message, with whatever is supposed to have been sent by Certificate Assistant attached to your email message. For any steps where something essential never happens because of this bug, start that process over and use the Save to Disk option rather than the email option.
I am so sick of Apple ignoring my bugs, i haven’t bothered filing one for this major problem. Be my guest, and good luck to you.
I have to wonder what happens when a Mac user has their OS X set up to use a Mail User Agent (MUA, a.k.a. email client software) other than Apple’s Mail (e.g. Thunderbird, Eudora, Lookout! Excess [Outlook Express] etc. etc.): will their Certificate Assistant successfully create outbound email messages in the alternate program? I’d hope so, but i’m not curious enough to actually set up this scenario and test it (i like Mail). Be wary of this point if you’re not using Mail.
 To be precise, the X509Anchors keychain no longer exists in the user interface, due to being deprecated. I saw one still present in /System/Library/Keychains on 10.8.3 Mountain Lion. This series of articles is only concerned with the user experience and the GUI.