Encrypted Email Cookbook
Pages: 1, 2
Further Customizations to Your Certificate
Until now, we've been depending on the
CA.pl script to create
and manage our certificates. Keep in mind that it is only a front end to the
OpenSSL certificate programs. You can achieve better control by manipulating
the configuration file openssl.cnf, and even the
CA.pl script itself.
Some of the possibilities are:
Making and converting certificates between DSA, RSA, and, to some extent, PGP.
Changing the certificate lifespan from the default configuration of one year. For example, look at the two ways of creating the certificate request:
$ CA.pl -newreq $ openssl req -config /etc/openssl.cnf -new -keyout newreq.pem \ -out newreq.pem -days 365
These both perform the same action, but by using
openssldirectly, you can change the certificate name, where it will be saved, the configuration file to be used, and how long the certificate will remain valid.
Creating new default certificate variables such as company name, section names, and departments.
$ openssl x509 -in newcert.pem -noout -text
$ openssl -revoke newcert.pem
$ openssl ca -config /etc/openssl.cnf -policy policy_anything \ -out newcert.pem -infiles newreq.pem \ -startdate [now] -enddate [previous enddate+365days]
Implementing Your Certificate
Once you've created a certificate, using it is a piece of cake. All
examples below are command-line-based. Why should we concern ourselves with the
command line? Because GUIs break and can be resource-intensive, you might be
controlling your machine remotely, or you may need to carry out a set of
actions using a script. All of the examples below assume that you are in the
directory in which you originally invoked
Signing Files with Your Certificate
You will be asked to enter your PEM pass phrase.
$ openssl smime \ -in myMessage.txt \ -sign \ -signer newcert.pem \ -inkey newreq.pem \ -out mySignedMessage.txt
Signing an Email and Piping It Through Sendmail
It is important to add the
text switch, as this option adds
plain text (
text/plain) MIME headers to the supplied message when
encrypting or signing.
$ openssl smime \ -in myMessage.txt \ -text \ -sign \ -signer newcert.pem \ -inkey newreq.pem \ -to firstname.lastname@example.org \ -from email@example.com \ -subject "visit next week" \ | /usr/sbin/sendmail firstname.lastname@example.org
Encrypting a File
$ openssl smime \ -encrypt \ -text \ -in myMessage.txt \ -out myMessage.ecrypted.txt \ newcert.pem
Encrypting an Email and Piping It Through Sendmail
Your private key, newcert.pem, is used to encrypt the email.
$ openssl smime \ -encrypt \ -text \ -in myMessage.txt \ -from email@example.com \ -to firstname.lastname@example.org \ -subject "Encrypted message" \ newcert.pem \ | /usr/sbin/sendmail email@example.com
Verifying an Email That Has Been Signed
Running this command with the
-out switch will save it to the
named file, and the
-signer switch saves the certificate to a named
file upon successful verification.
$ openssl smime \ -verify \ -in mySignedMessage.txt \ -signer friend.cert.pem \ -CAfile myRoot.crt \ -out message.verified.txt
Decrypting a Message
The message is checked against two certificates: newcert.pem, the certificate from the sender, and newcert.pem, the CA's certificate. The code below will send the decrypted message to standard output.
openssl smime \ -decrypt \ -in myMessage.ecrypted.txt \ -recip newcert.pem \ -inkey newreq.pem
Getting Signed and Encrypted Email from the Console
The easiest way to get signed and/or encrypted messages is to use the old
pine, the message will end up as garbage.
Getting Encrypted Attachments from the Console
On the other hand, unless you're a
mutt. You can then use OpenSSL in a manner
similar to the above.
Other Methods of Getting and Sending Encrypted Email from the Console, Using PKI
There are several ongoing projects for console-based email clients that
incorporate the OpenSSL libraries directly.
mutt is one of them.
Mozilla is a GUI option — what can I say, it's just a click away!
The pros of OpenSSL are many:
- A superb mechanism for sysadmins who want to transmit sensitive information over insecure networks.
- The certificate will work with any mainstream email client such as Netscape, Mozilla, Outlook, Outlook Express, or others.
- Excellent for in-house corporate use.
- Great solution among friends, since you can all get your certificates signed by the Root Certificate that you've already created.
- An inexpensive solution that doesn't require the services of a commercial CA.
There are cons, however:
- Not good for strangers to receive your email, since the browser will say not to trust it!
- Upon receipt of a signed email, you will get naughty messages from your email client that the certificate is not recognized, and unless you either import the certificate authority into your email client or the sender's certificate has been signed a CA that has been already included in your browser, you will not be able to return an email addressed to the sender.
- There is an irritation factor to put up with. For example, the email client will spit at you because of trust issues, which you can deal with by setting the preferences yourself.
If you want to save yourself a bit of grief in Mozilla as you experiment, use the profile manager to create two separate accounts. Generate one root and two client certificates. Be advised that you will have problems if you attach a certificate with an email address that is different from your email configuration.
Pretty Good Privacy (PGP) is a pretty good solution. Among other clients, there
is support for
Eudora, and there is a plug-in that will allow it to work with Mozilla, too.
- SSL How-To
- A list of CAs on Red Hat Linux is found at /usr/share/ssl/certs/ca-bundle.crt
- Creating Your Own CA
- Distributing Your CA to Client Browsers
Robert Bernier is the PostgreSQL business intelligence analyst for SRA America, a subsidiary of Software Research America (SRA).
Return to the Linux DevCenter.