LinuxDevCenter.com

oreilly.comSafari Books Online.Conferences.

We've expanded our Linux news coverage and improved our search! Search for all things Linux across O'Reilly!

Search
Search Tips

advertisement

Listen Print Discuss Subscribe to Linux Subscribe to Newsletters

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 openssl directly, 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.

  • Certificate Display:

    $ openssl x509 -in newcert.pem -noout
    -text

    Certificate Revocation:

    $ openssl -revoke newcert.pem

    Certificate Renewal:

    $ 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 CA.pl newca.

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 robert.bernier5@sympatico.ca \
	-from robert.bernier5@sympatico.ca \
	-subject "visit next week" \
	| /usr/sbin/sendmail robert.bernier5@sympatico.ca

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 robert.bernier5@sympatico.ca \
	-to robert.bernier5@sympatico.ca \
	-subject "Encrypted message" \
	newcert.pem \
	| /usr/sbin/sendmail wolven@sympatico.ca

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 standby mail and save the message directly to the hard drive. Why? Because mail will save all of the headers, which is necessary for decrypting the message. If you use something like mutt or pine, the message will end up as garbage.

Related Reading

Linux Security Cookbook
By Daniel J. Barrett, Richard E. Silverman, Robert G. Byrnes

Getting Encrypted Attachments from the Console

On the other hand, unless you're a mail wizard, saving an encrypted attachment to the hard drive is best done with utilities such as pine or 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!

Conclusion

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.

Tips

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 pine, mutt, kmail, and Eudora, and there is a plug-in that will allow it to work with Mozilla, too.

References

  • SSL How-To
  • man pages: CA.pl, openssl, smime, config
  • 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.


Have a question for Robert? Ask him here.
You must be logged in to the O'Reilly Network to post a talkback.
Post Comment
Full Threads Oldest First

Showing messages 1 through 4 of 4.

  • an easier answer that works
    2003-09-16 22:18:36  anonymous2 [Reply | View]

    mozilla + enigmail + gpg. works on linux/....bsd and windows. in fact, on windows for whatever reason it is slightly easier to set up than on ..ix.

    The article was excellent at describing how to do this stuff using ssl, but as it points out, for practical purposes, the certificate authority is unsatisfactory, and actually paying one of those commercial ventures is anathema to those of us who abhor the notion that the internet is simply a means of making us pay some corporation or another for everything we do. The FSF or some similar entity should provide some kind of root certificate. Then i'd buy it. And funding for them too.
  • What you've written in this article...
    2003-09-05 03:39:54  anonymous2 [Reply | View]

    convinced me that

    ``The "official" solution was to send all important communications in a password-encrypted Microsoft Word document — not quite the solution expected of an IT organization.''

    was the right solution!

    And that before people are going to start using encryption, we need to make it a lot easier!
    • Described techniques likely beyond most
      2003-09-05 19:43:23  anonymous2 [Reply | View]

      Dear Mr. Bernier,

      Many thanks for your contribution to this topic. It is an indirect reminder of how desperately email needs an easier-to-use encryption capability.

      I would dearly love to regularly use encrypted mail, and think I might just manage to get my Windows head around the Linux techniques you detail. However, I fear few of my correspondants would be so lucky.

      Market opportunity for the Open Source Community: simpler GUI access to encrypted email. If I appear to seek "burger flipping" solution to a "rocket science" problem, guilty as charged.

      Links to such projects, FAQ and HOWTO welcome.

      Best regards,

      Russell
      • Described techniques likely beyond most
        2003-09-06 10:47:42  _augie [Reply | View]

        The solution I use is:

        Mozilla-Mail: http://www.mozilla.org/
        Enigmail-plugin: http://enigmail.mozdev.org/
        GnuPG: http://www.gnupg.org/

        These tools make sending and receiving encrypted and digitally signed email messages easy.

        What Mr. Bernier details in this article would probably be best implemented by an IT staff for a corporations in house use. Most email clients have the ability to sign and encrypt using SSL certificates. Once the IT staff created the certificates there would be little configuration for the user. And then all correspondence would have a good degree of security; as opposed to having to create a bloated word document, and using a weaker encryption to send a simple message.


Tagged Articles

Be the first to post this article to del.icio.us

Sponsored Resources

  • Inside Lightroom
Advertisement

Sponsored by:

O'Reilly Media

©2009, O'Reilly Media, Inc.
(707) 827-7000 / (800) 998-9938
All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.
About O'Reilly
Academic Solutions
Authors
Contacts
Customer Service
Jobs
Newsletters
O'Reilly Labs
Press Room
Privacy Policy
RSS Feeds
Terms of Service
User Groups
Writing for O'Reilly
Content Archive
Business Technology
Computer Technology
Google
Microsoft
Mobile
Network
Operating System
Digital Photography
Programming
Software
Web
Web Design
More O'Reilly Sites
O'Reilly Radar
Ignite
Tools of Change for Publishing
Digital Media
Inside iPhone
O'Reilly FYI
makezine.com
craftzine.com
hackszine.com
perl.com
xml.com

Partner Sites
InsideRIA
java.net
O'Reilly Insights on Forbes.com