6

Alice would like to send a secure (S/MIME encrypted) email to Bob. Both of them use macs and Mail app. They are both creating self-signed certificates and are able to exchange signed mails, but there seems to be no way to activate the padlock icon.

Could somebody instruct her?


Gory details of failed attempt ensue:

Alice googles, discovers she must create a self-signed certificate in KeyChain.App which she does via the wizard (Keychain access -> certificate assistant -> create certificate), taking care to:

  • select "S/MIME Email"
  • check the "let me override defaults" checkbox.
  • in "key usage extension", make sure 'signature' and 'certificate signing' are checked, as well as 'key encipherment' and 'data encipherment'
  • in "extended key usage extension", 'email protection' is already checked, but check 'any' also just in case

It may be worth noting that Alice's email appears as me@alice.com whereas the actual email address is on Gmail: alice@gmail.com. Alice has discovered the hard way that she must use alice@gmail.com in the wizard.

She restarts mail app. Actually after reading step 3 here she restarts the machine.

She then composes an email to Bob who has done the same.

In the subject field she notices two new icons: a padlock (encrypted Y/N) and a tick (signed Y/N).

The tick is blue. So the message she sends will be signed. However the padlock is greyed out.

Now the documentation says that if:

  1. Mail detects her certificate (which it clearly has) and
  2. Mail also finds a certificate in her keychain for Bob (which there is, because Bob has just sent her a signed email and Mail has been smart enough to automatically add his public key to the keychain -- she can see it there)

... then she should be able to click on the padlock to encrypt her email to Bob.

But this doesn't seem to be happening.

https://www.macobserver.com/tips/quick-tip/macos-using-email-encryption-apples-mail/ ^ Step 5 says that the first time she attempts to send a signed email, she should get that dialog. But she didn't.

Alice is at this point starting to contemplate landscape gardening as a possible career move.

PS possibly useful link:


  • Sorry for the "non answer" where I try to convince you there is no easy way to encrypt mail since we've been trying since 1988 and PGP and there are just too many mail clients and no central repository of keys that make this a viable solution for anyone but a well trained in operational security full time professional that can use encrypted mail effectively. – bmike Dec 2 '17 at 12:49
  • Did Bob send Alice a signed, encrypted reply after he received her signed, non-encrypted email? – zerohedge Dec 2 '17 at 12:54
  • Did Alice explicitly trust Bob's self-signed certificate? With self-signed certificates, this is a required step. Does Bob's certificate display as "trusted" in Alice's keychain? Also, there might be problem with the certificates. Please add to your question if you had set the certificate extensions to critical yes or no? Finally, did you add the e-mail address to the alternative name section (as an rfc822name)? – not2savvy Dec 2 '17 at 21:57
  • It may be helpful, if you could post the contents of the certificates you have created. To get them in a human readable format, export the certificate from your keychain in .cer format. Then, in the terminal, use openssl to display the exported certificate data like so: openssl x509 -inform DER -in alice.cer -text – not2savvy Dec 2 '17 at 22:11
  • @zerohedge after Alice receives a signed non-encrypted email from Bob, she inspects her keychain and finds that it contains Bob's certificate which is trusted. She thinks she should be able to send a signed encrypted email to Bob. Mail thinks otherwise. – P i Dec 3 '17 at 2:20
2

This is how it works here, with the help of a self-signed root certificate:

Step 1: Alice creates a self-signed root certificate

  • In the Keychain app, select Keychain Access > Certificate Assistent > Create a Certificate Authority
  • Select
    • Identity Type: Self Signed Root CA
    • User Certificate: S/MIME (Email)
    • Let me override defaults: yes
    • Email from: Enter an email address for the root CA (could be Alice's)
    • On the next dialog, select Sign your invitation: no - optionally create a CA web site
    • On the next dialog, enter whatever CA data you want
    • On the next two dialogs, leave Key Pair Information as is
    • On the next dialog Key Usage Extension
  • Include Key Usage Extension: yes
  • This extension is critical: no
  • Select: Signature, Certificate Signing (optionally more, but not required for a root certificate)
  • On the next dialog, leave Key Usage Extension for the user's certificate as is
  • On the next dialog, optionally set Include Extended Key Usage Extension = yes, if you want to use the root CA for more than just email certificates - but always leave This extension is critical = no
  • On the next dialog, leave Use Basic Constraints Extension = Use this certificate as a certificate authority
  • On the remaining dialogs, leave selections as they are
  • On the last dialog Specify a Location For The Certificate, you can select System, and also select On this machine, trust certificates signed by this CA = yes

Step 2: Alice and Bob trust the the root CA

  • If Alice hasn't already trusted the CA certificate during the previous step, she now selects the new root CA certificate in her Keychain app and explicitly trusts the CA certificate
  • Alice exports the public CA certificate in .cer format and publishes it to Bob
  • Bob imports the public certificate and explicitly trusts this CA

Since Alice and Bob have explicitly trusted the CA, all certificates signed by this CA will be automatically trusted on their computers.

Step 3: Alice creates an email certificate for herself.

  • In the Keychain app, select Keychain Access > Certificate Assistent > Create a Certificate
  • Enter Alice's name, then select
    • Identity Type: Leaf
    • User Certificate: S/MIME (Email)
    • Let me override defaults: yes
  • Leave next dialog (serial no. etc.) as is
  • On the next dialog, for Email Address, enter Alice's email address this certificate is intended for, optionally fill out remaining fields as desired
  • On the next dialog Choose An Issuer, select the CA created in step 1
  • On the next dialog, keep Key Pair Information as is
  • On the next dialog Key Usage Extension
  • Include Key Usage Extension: yes
  • This extension is critical: yes
  • Select: Signature, Key Encipherment (optionally, adding Data Encipherment seems to be possible, but do not add more!)
    • On the next dialog, leave Key Usage Extension for the user's certificate as is
  • On the next dialog, optionally set Include Extended Key Usage Extension = yes, but set This extension is critical = no
    • Select "Email Protection*, add more if you want to use the same certificate for other purposes
  • On the next dialog, leave Include Basic Constraints Extension = no
  • On the next dialog, select Include Subject Alternate Name Extension = yes
    • Leave This extension is critical = no
    • Enter the email address (again) in the rfc822Name field. Optionally add more email addresses, separated by space, which you may want to use the certificate for
  • On the last dialog Specify a Location For The Certificate, you can select Login

Step 4: Alice creates a certificate for Bob

Now Alice repeats step 3 to create a certificate for Bob, then exports his certificate in .p12 format, gives it to him, and Bob imports it into his keychain.

Note: This is the easiest way to create Bob's certificate, yet not the recommended way. This is because Alice creates Bob's private key, so Bob has to trust Alice. Actually Bob would use the Certificate Assistent on his computer to Request a Certificate From a Certificate Authority.

Step 5: Alice and Bob send each other signed messages

Alice sends a signed email message to Bob, and Bob sends a signed email message to Alice. If all went well, the signatures will display as trusted because both trust the CA certificate.

Step 6: Alice and Bob can exchange encrypted email messages

Both can reply to the signed message using encryption with the reply message.

  • Gosh, thanks for the level of detail! This has doubly persuaded me to use Signal. – P i Dec 5 '17 at 5:20
  • It is actually easier than it looks, because once you have created the self-signed CA and distributed its public certificate, any subsequent certificate will work instantly. – not2savvy Dec 5 '17 at 6:26
1

This is not going to be easy. Depending on why you want to use encrypted email, it might be far easier to look over the threat model and say - get an app like Signal that handles the encryption decisions and you know you are sending encrypted information only using that app.

Messages is also a viable encryption option for many people but I chose Signal since it has windows / linux / android clients and mail is typically chosen when you need to have as wide a client OS profile as possible.

Unless your users of encryption are more trained than the EFF link above requires you to be to use Signal - jumping to secure email seems a far more lofty goal and not something you could drop in a "three paragraph here's how to secure email on macOS and the mail app" answer could do justice.

Now, if mail really is needed, here is a service that has a bridge App to ease the workload of getting PGP to mail apps easily.

  • While this might be a valid opinion under certain circumstances, it does not answer the question at all. – not2savvy Dec 4 '17 at 10:48
  • 1
    Actually it answers the question behind the question, so +1. I have ended up using Signal, works a charm! – P i Dec 5 '17 at 5:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .