OpenSSL

OpenSSL is a cryptography toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) network protocols and related required cryptography standards. OpenSSL can be used to make certificates that follow the Public Key Infrastructure (PKI).

Only the most basic definitions regarding public key encryption and digital signing are explained in this article. Please refer to the suggested articles and sites for further readings on this topic.

A Certification Authority (CA) is an organization, either commercial or nonprofit, that is capable of validating a certificate. The best-known CAs are VeriSign and Thawte. Open your security preferences in your browser and you should find a list of certificates from multiple CAs already defined there.

A digital certificate is mathematically generated data that is almost impossible to duplicate and therefore can be considered unique and non-reproducible. It is useful as a mechanism that demonstrates that an email does indeed come from a particular organization or individual and that it has neither been tampered nor forged.

Encryption is the translation of data into a secret code. Encryption is the most effective way to achieve data security. To read an encrypted file, you must have access to a secret key or password that enables you to decrypt it. Unencrypted data is called plain text; encrypted data is referred to as cipher text.

The use of combined public and private keys is known as asymmetric cryptography. A public key is a value provided by some designated authority, such as a commercial Certification Authority, as an encryption key. A private key is secretly derived from the public key and is controlled by the person who wishes to sign email or receive encrypted messages by others who encrypt their messages using their public keys.

A Public Key Infrastructure (PKI) consists of three parts:

1. A Certification Authority (CA) that issues and verifies digital certificates. A certificate includes the public key and information about the public key.
2. A Registration Authority (RA) that acts as the verifier for the certificate authority before a digital certificate is issued to a requestor.
3. A location on the computer where the certificates and public keys are stored.

Creating and Signing Your Own CA Certificates

Create a Root Certification Authority Certificate

Creating a self-signed certificate is simple. Just navigate on a text console to a location in your directory where the files and directories will be created and type the correct path to the Perl script CA.pl:

$ /usr/share/ssl/misc/CA.pl -newca

Figure 1. Running CA.pl

You will now be prompted to answer a number of questions:

Figure 2. CA questions

After successfully answering all the questions, you should have a directory called demoCA with a number of files and directories in it. Keep in mind that if you forget the PEM passphrase, you will have rendered the certificate useless and will have to start all over again.

The Root Certification Authority Certificate authenticates all certificates that the browser accepts through normal email correspondence that is signed with this certificate. It is with this certificate that all subsequent certificates that you create and sign against can be verified as legitimate. Installing this certificate on a company web site allows the employees to incorporate this into their browsers and further secure their company communications as they sign and encrypt their messages. Take demoCA/cacert.pem and copy it as cacert.crt to your web server. You can then pick up the Root Certification Authority Certificate from the web server via the browser.

Create Your Personal Certificate

To create your public and private keys, generate a certificate request by typing the following in the same directory as you did with the previous command:

$ /usr/share/ssl/misc/CA.pl -newreq

As with the Root CA script, this script will guide you through series of questions and requests that you must answer before the private key in newreq.pem and the certificate newcert.pem are created and signed with the file cacert.pem, which is your Root Authority certificate.

Beware of your newreq.pem file, as it contains not only a certificate request, but also your private key. The -PRIVATE KEY- section is not required when you sign it. So if you request that someone else sign your certificate request, ensure that you have removed the -PRIVATE KEY- section from the file. If you sign a certificate request for someone else, ask him for his -CERTIFICATE REQUEST- section and not the private key section.

Sign the Certificate Request

Proceed by typing the following command:

$ /usr/share/ssl/misc/CA.pl -sign

The certificate that you have created will now be signed with the Root Certificate's private key at demoCA/private/cakey.pem. A new file called newcert.pem has now been created. This file is your certificate signed with the Root CA certificate.

Create newcert.p12 from newcert.pem

We're almost done! A PKCS#12 file contains the user's certificate, his private key, and the CA certificate. The CA.pl script uses the user certificate and private key in the file newcert.pem and the CA certificate in the file demoCA/cacert.pem. The PKCS#12 file can be imported directly into a browser. In addition, a user-specific name can be added as an additional argument on the command line for the certificate.

$ /usr/share/ssl/misc/CA.pl -pkcs12

You will be asked for the PEM password and then asked to a create an export password. You now have a file called newcert.p12 that will be compatible with Mozilla, Netscape, Outlook, and Outlook Express for signing and encrypting email.

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