PKCS12, Personal Information Exchange Syntax Standard, certificates can be used for things such as email signing and file signing. They are different from other certificates in that rather than being only the public or private certificate, they are a combination of both plus the root certificate. This means the person they are made for only has to worry with one file.

Note: The author of this page, and owner of this web site, is not to be held liable for any damage or trouble arising from following these directions. You are responsible for your own security, use, and creation of certificates.

See http://www.drh-consultancy.demon.co.uk/pkcs12faq.html and http://www.openssl.org/docs/apps/pkcs12.html for more information.

This http://www.ripe.net/ripencc/pub-services/db/mail_client_tests.html and http://www.rsasecurity.com/rsalabs/node.asp?id=2138 may also be of interest.

Quick steps:

1. Setup and create root certificate.
2. For each person create a key and signing request.
3. Sign each request.
4. Create the PKCS12 file.
5. Distribute the file(s).

The following covers the command-line way of doing it on Linux using OpenSSL. If you are using a GUI, it should be fairly simple to follow along.

1) Setup and create root certificate

See Setting up OpenSSL to Create Certificates

Note: If all you are going to be creating is certificates to sign files and/or emails, and have an old box around I highly recommend loading it up with Apache, PHP, OpenSSL. Install PHPki and use it to create and manage your certificates. However, make sure this computer is not accessible over the internet.

2) For each person create a key and signing request

Assuming you have your root certificate created and you are in the 'sslcert' directory you can start creating certificates for each person in your company, or at least each one you want to be able to digitally sign drawings (or email or anything else certificates can be used for).

Type (all one line):
openssl req -new -nodes -out name-req.pem -keyout private/name-key.pem -days 365 -config ./openssl.cnf

Note the number of days. For employee certificates I like to keep this fairly short, but a year may be too short. For a newly hired person you might want to do it for the length of their probation period and then reissue it for longer after that.

You will be prompted for information, much like when creating the root certificate. I put "Employee" for the Organizational Unit, make sure to use their correct internet email address for Email Address, and use their full name for Common Name.

Once you are done with the input, two files will be created:
name-req.pem - the request
name-key.pem - the private key in the private directory

3) Sign each request

This will generate the certificate.

Type:
openssl ca -out name-cert.pem -days 365 -config ./openssl.cnf -infiles name-req.pem

You will be prompted for the password used when creating the root certificate. Then you will be given a chance to review the information before signing. If anything is incorrect, now is the time to stop and redo things.

Two files are created:
name-cert.pem - which is the certificate
<number>.pem - a copy of it in the certs directory.

4) Create the PKCS12 file

This file combines the person's public key, private key, and root certificate into one file.

Type (all one line):
openssl pkcs12 -export -in name-cert.pem -inkey private/name-key.pem -certfile cacert.pem -name "[friendly name]" -out name-cert.p12

[friendly name] can be what you want, but I use the person's full name (note: do not enclose any part of this with quotes, such as a nick name). You will be prompted for an "export password". This is what the user will use when they import the file and if they lose this file and need to export it from a storage "service" for use elsewhere. I let my people come over and type their own, since it is unchangeable once created.

Before you transfer them, note that the p12 format is binary and the pems are text. (This matters with FTP and a few other situations.) Also remember that the name-key.pem is the private key and should be guarded, whereas the name-cert.pem is the public certificate. While name-cert.p12 is encrypted with the password, it does contain the private key so I wouldn't leave it laying out for just anyone to get to.

5) Distribute the file(s)

The name-cert.p12 file is the one to give the person. They will need to know the export password used when creating the file. You can also give them their name-cert.pem and name-key.pem if you want. However, stress that if the name-cert.p12 file or the name-key.pem is compromised, ie lost or misplaced, that they must tell you immediately. Then you must revoke their existing one and issue a new one.

How the users import them depends on the application.