Digital Signatures and Encryption in Yosemite Mail

After upgrading to Yosemite, I am having difficulty using the Mac Mail app to send digitally signed and encrypted email.


Before the upgrade to Yosemite, I was able to send signed and encrypted emails using certificate/keys in my keychain using both the Mac Mail app and Microsoft Outlook 2011 for Mac.


After upgrading, I am still able to send signed and encrypted message in Outlook, but the Mac Mail app gives the following error when I attempt to send a signed email:


'You don’t have a trusted certificate in your keychain that matches the email address “XXXX@XXXX”. Without a certificate, you can’t sign messages sent from this address.' (Actual name replaced)


When I look at my certificates in my keychain, a certificate is available with "Usage: Digital Signature" that has the email address from the error message "XXXX@XXXX" with exact case in the RFC 822 Name.


----


Another interesting piece of data that might help track this down is that when I first launch the Mac Mail application, the Mac Mail application is able to successfully decrypt emails that have been previously sent encrypted to me. HOWEVER, after I attempt to send an email and get the "You don’t have a trusted certificate..." error message, these emails are no longer able to be decrypted. I get the "Unable to decrypt message" header above the message and the content of the message is just a "smime.p7m". If I close the mail application and restart it, these encrypted message are once again decrypt-able until I attempt to send a message.

It almost seems like things are working until mail tries to access the keychain.


----


I have attempted to delete my certificate and keys from my keychain and then adding those items again.

I have attempted to close the mail application and reopen it.

I have attempted to reboot my computer.

MacBook Pro with Retina display, OS X Yosemite (10.10)

Posted on Oct 20, 2014 3:33 PM

Reply
29 replies

Nov 4, 2014 5:21 PM in response to puglas

I have the exact same problem in Yosemite 10.10.0 (looking forward to that point 1 release). Puglas, good job noticing the change in behavior with decryption - this clearly shows that it is an Apple bug because clearly the certificate is read correctly when Mail first starts and then gets into a bad state after you try to send.


My co-workers is not having this problem and can successfully use s/mime certs in yosemite. I'm not sure why his works and mine doesn't.


I have tried:

  • re-importing my s/mime certificate
  • deleting and importing the s/mime from the source
  • running first-aid on the keychain

Nov 4, 2014 5:47 PM in response to The Snake in Eden

I also have an additional problem where if I attempt to sign an email and fail as described above, I can no longer close the composition window. If I cmd+w the window I get the normal modal dialogue "Save this message as a draft?" When I select "Don't Save" the modal dialogue goes away, but the composition window will not close. The only way I can close the composition window and discard the draft is if I close mail.app entirely, re-open it, and then I'm able to close/discard the composition (Upon re-opening, the signature/encryption buttons are noticably missing).

Nov 5, 2014 12:34 PM in response to puglas

Same problem for me. This is a Yosemite Mail.app bug.


Another way to troubleshoot your S/MIME certificate trust chain is to open Contacts and doubleclick on the "verified" icon next to your email. This will show your cert with its chain of trust. For me, this shows my valid cert with the correct and case-specific RFC 822 name, a valid Intermediate CA, and a trusted Root CA. Yet Yosemite Mail.app says -- for old emails signed with this cert under Mavericks -- that this Intermediate CA is invalid, and hence believes my cert is invalid.


Mail.app trust is out-of-sync with Contacts.app and Keychain Access.app. I also see the bug of the Mail.app composition window not closing.


I've tried completely blowing away my login keychain and starting from scratch, and also playing around with application-specific (Mail, Keychain Access) Access Control for the private keys of my S/MIME signing and encryption certificates..


I don't see a fix except to hope that Apple addresses this enterprise bug in 10.10.1.

Nov 18, 2014 5:52 AM in response to arthurvisser

1. I want to confirm that this is still an issue for me in 10.10.1 and mail Version 8.1 (1993)


2. I have another data point.


At my office I have wired networking and wireless networking available. Primarily I utilize the wired networking for access to network drives, etc.


When using the wired networking, I experience all the problems that have been catalogued in this thread. Can't sign, can't encrypt, can't close the compose window after the mail program fails to find my certificate.


However, when I switch to wireless networking before starting the mail application, digital signatures and encryption seem to work! This is pretty weird behavior. Make sure to restart mail if you were previously wired.


Here are some theories:


Something to do with OCSP? When I am wired vs wireless I am on different ip subnets and subject to different firewall rule sets. Perhaps OCSP is trying to determine the status of the certificate and failing?


Here are some things I have tested:

  • I switched to a different official apple brand thunderbolt to ethernet adapter with no change in behavior
  • I disabled wireless and disconnected my wired network. So no network access at all. Signatures and encryption work! The message obviously does not send, but it appears in my outbox and I don't get the signature error. When I reconnect my wired cable, the message sends successfully and appears as encrypted in my sent folder!
  • I have attempted to disable OCSP by using "Keychain Access --> Preferences --> Certificates Tab --> OCSP (OFF) and CRL (OFF)" but this hasn't made a difference in the behavior of wired networking.
  • Ran a TCPDUMP on traffic to the OCSP service but didn't see any traffic when I attempted to send a message and received the signature error


I am pretty stumped on this. This is very odd behavior


Does anyone else experience this behavior?

Nov 18, 2014 8:11 AM in response to puglas

@Puglas I can confirm being able to send a digitally signed message when before starting Mail all network is turned off. The signed message is put in the Outbox and sent after quiting Mail, connecting network and starting Mail.

I cannot confirm the Wifi part since our Wifi is bridged so we have the same network settings. I tried anyway because on Ethernet I have a fixed IP and on Wifi through DHCP but no.

I did notice that switching from my iCloud mailaccount (where the signature setting is greyed out) to the account for which the certificate is valid it would still be grey. I had to quit Mail and start with my mailaccount to have te signature badge icon functional (black) again. Also, the stuck message windows, after trying to 'Don't Save' them don't really disappear after a restart of Mail but are put in the Drafts folder.

Nov 19, 2014 6:53 AM in response to puglas

Update. I hadn't yet installed a certificate at the home MBPro. In this computer I use what started 7 months ago as a Carbon Copy Clone of my work HD, did the same upgrades etc. since. Ths MBP had already Mail 8.1 (OS X 10.10.1) but no personal mail certificate. So I imported my certificate in Keychain Access and everything just works. I'm on a Wifi network at home. I will try when connected on ethernet tomorrow.


Btw I couldn't install the certificate by doubleclicking the downloaded .p7s certificate file as I could at work, then using Mavericks. I did get a window asking if I wanted to add the certificate(s) to a keychain, but when I clicked 'Add' nothing happened. What worked was in Keychain Access to choose Import Files… and point to the certificate (SMIME.p12).

Btw2 At work under Mavericks signing worked fine but the lock to encrypt was greyed out. Sometimes black for a short while just after starting Mail. I ment to sort that out later. Now when using Mail at home both signature and encryption work.

Dec 4, 2014 6:53 AM in response to puglas

Here's how to decrypt S/MIME messages by hand until Apple fixes the bugs in Yosemite Mail.app:


  1. Mail.app>File>Save As...> Save the smime.p7m message as a .eml file.
  2. Keychain Access>Login/My Certificates> Locate your private key for your encryption certificate, the corresp[onding certificate should have the "Key Encipherment" usage as a critical extension. Highlight the private key only, right-click, and Export the key to the secure file smime_key.p12.
  3. Run the following openssl commands, which will create an insecure file of your smime private key, decrypt the message, then clean up:


openssl pkcs12 -in smime_key.p12 -out smime_key.key.pem -nocerts -nodes

openssl smime -decrypt -in smime_email.eml -inkey smime_key.key.pem > decrypted_mail.eml


Make sure you securely delete your decrypted private key:


srm smime_key.key.pem decrypted_mail.eml

rm smime_key.p12 smime_email.eml

Apple needs to slow down with the updates if they can't reliably release a version .0 that forces you to decrypt email by hand. A lot of time wasted chasing workarounds for OS X 10.10 and iOS 8 bugs...

Dec 21, 2014 10:53 AM in response to jamesborr

I and others in my group where we use encrypted email have been having similar decryption problems with emails encrypted from Mail (8.1 (1993)) in Yosemite (now 10.10.1) but only when the email includes attachments!? We've tried similar "fixes" to 'puglas' with the same lack of success. We've halted further upgrades from Mavericks to Yosemite in the group but wish Apple would have some way to roll back OS upgrades until THEY SORT OUT THE INCREASING NUMBER OF BUGS in their new systems!

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Digital Signatures and Encryption in Yosemite Mail

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.