Todo: More review and refactoring required.
Created Thursday 13/7/2006
The OpenSSL framework comes with a variety of tools, such as x509(1), genrsa(1), ca(1), and many more. The openssl(1) tool is provided as a means of seamless access to the programs in the Open SSL toolsuite (e.g., x509(1), genrsa(1), ca(1) and so on) and can be used to create, sign, import, export and generally manage a variety of certificates and a variety of certifcate stores.
Fedora Core Openssl documentation is available in /usr/share/doc. The 0.9.8b openssl.txt is worth reading.
Todo: More review and refactoring required.
Using a self-signed certificate is sufficient for most (testing) purposes, but ideally, such a certificate should not be used for secure/production purposes. In these cases, a certificate signed by a trusted authority is the go.
The following openssl command creates a self-signed certificate in PEM format and a certificate signing request (CSR). Fill out the information that the Open SSL command req(1) asks for. Make sure that the host name is entered for the Common Name (also called the CN attribute). The challenge password can be left blank. Openssl will generate a key that is passphrase protected, which cannot be less than 4 characters long.
bash $ openssl req -new -text -out server.csr
Note: The above req command creates a private key, written to privkey.pem, and a CSR is, which is written to server.csr
Removing the certificate passphrase might be required if the certificate is used for services that are using SSL and are configured for unattended startup (see, for example, Postgres in SSL mode). A certificate's passphrase can be removed with the following (the original passphrase must be known):
bash $ openssl rsa -in privkey.pem -out server.key bash $ rm privkey.pem
Note: In this example, the RSA certificate is written to server.key and is created from privkey.pem, an x509 certificate)
Using a self-signed certificate is sufficient for most (testing) purposes, but ideally, self-signed certificate should not be used for secure purposes (or in a production environment). In these cases, a certificate signed by a trusted authority is a better option. To turn a certificate into a self-signed certificate, run the following:
bash $ openssl req -x509 -in server.req -text -key server.key -out server.crt bash $ chmod og-rwx server.key
When creating a private key, it is sensible to specify a fairly large key size (at the very least, 1024-bit keys should be used). If the private key is to be used as input to create a Certificate Signing Request (CSR), then the larger the keysize the better (consider 2048-bit keys in this case). The following Open SSL command uses the genrsa(1) program to create a 2048-bit RSA key, which is written to the file bar.key:
bash $ openssl genrsa -out bar.key 2048
Tip: Use a large key size (2048-bit or greater) if using the private key for a CSR
The Open SSL req(1) is used to create a Certificate Signing Request (CSR), whichj are typically in PKCS#10 format. The CSR is used to define information such as the Country Name (ISO 2-letter code), State or Province Name (full name), Organizational Name, Email Address and so on. The CSR is then used by a Certificate Authority to create a (authoritively) signed certificate. The CSR should be sent to a certificate authority in order to apply for a digital identity certificate.
bash $ openssl req -new -key bar.key -out bar.csr
The above example uses the default openssl.cnf file is used. It's possible to modify the Country Name and related settings, either in the default openssl configuration file or in a separate config file. To use a different config file, specify the -config option, passing the pathname to the new configuration file as an argument.
Note: A CSR is not required for a self-signed certificate. However, a CSR is required for a trusted root certificate, self-signed or not.
CACert is a certificate signing authority that can issue certificates free of charge. See www.cacert.org
The Open SSL req(1) program can also be used to create a root (or trusted) certificate instead of a signing request. When creating a trusted root certificate, use the -x509 option to req(1):
bash $ openssl req -x509 -new -key bar.key -out barroot.crt
The previous invocation of req(1) creates the trusted root certificate from a previously created private key (see #x). The root certificate is written to the file barroot.crt
Both the CSR and the RSA private key are needed to make an x509 certificate. An x509 certificate is created using Open SSL's x509(1) program.
The following creates an x509 certificate, valid for 1 year (specified by the -days option with argument 365). The data within the certificate is the same as is attached to the certificate signing request bar.csr (see #6)
bash $ openssl x509 -req -days 365 -in bar.csr -signkey bar.key -out bar.crt
Note: A CSR is not required for an RSA certificate (see #2)
A trusted certificate is an ordinary certificate which has several additional pieces of information attached to it such as the permitted and prohibited uses of the certificate and an alias.
Normally when a certificate is being verified at least one certificate must be "trusted". By default a trusted certificate must be stored locally and must be a root CA: any certificate chain ending in this CA is then usable for any purpose.
Trust settings currently are only used with a root CA. They allow a finer control over the purposes the root CA can be used for. For example a CA may be trusted for SSL client but not SSL server use.
Note: See the description of the verify utility for more information on the meaning of trust settings.
The verify option is used to check the validity of a certificate against the root certicate. Clearly, the root certificate is required. In the following example the certificate bar.crt is verified against the root certificate bar-ca.root
bash $ openssl verify -CAfile bar-ca.crt bar.crt
OpenSSL can be used to create a number of different format-type certificate stores, such as PKCS#12 (called .p12 for .pfx files) as well as PKCX#7 (deprecated) and PKCS#8 (netscape). If the cerificate and private key are together in the same file, then the -inkey option in the following can be ommitted. Otherwise, execute the following openssl command to create a PKCS#12 from an existing PEM formatted certificate file and PEM format private key:
bash $ openssl pkcs12 -export -in localhost.cert -inkey localhost.key -out mycerts.p12
Warning: See 9A for existing certificates tores
To add more certificates to an existing PKCS#12 certificate store, specify the -certfile option in addition to the -export option to Open SSL's pkcs12(1) program:
bash $ openssl pkcs12 -export -in file.pem -out mycerts.p12 -name "My Certificate" -certfile othercerts.pem
To extract the certificates from a PKCS#12 certificate store, use the -in and -out options of openssl's pkcs12 command. In the following example, the -nodes option tells openssl not to encrypt the resulting PEM formatted certificate (with private key):
bash $ openssl pkcs12 -in mycerts.p12 -out localhost.pem -nodes
To write only the client certificates to a file:
bash $ openssl pkcs12 -in mycerts.p12 -clcerts -out file.pem
Some information about the certificate store, such as the MAC verification, data encryption type, and iteration can be extracted from an existing certificate store with:
bash $ openssl pkcs12 -in mycerts.p12 -info -noout
The x509(1) application of the openssl suite provides the -text option for extracting out certificate attributes in human readable form. The format of the certificate file to operate on must be specified with the -inform option, which takes an argument of either PEM, for PEM text encoded certificates or DER for DER binary encoded certificates.
The following example display certificates attributes for a DER encoded x509 certificate:
bash $ openssl x509 -inform DER -text -in bar.crt
Tip: To view attributes of a PEM text encoded x509 certificate, simply change the DER argument to PEM.
Openssl has a heap of options for each of its supported applications (like rsa, x509, pkcs12 and the list goes on). These options and applications can be a little overwhelming and the user of a simple front end over openssl makes like a lot easier.
This is a simple QT app that can be used to create certificates, private keys, CSRs and similar. The certificates (and etc) are created by filling out forms, which are then send to openssl to generate the actual certificate (and etc) files. The XCA certificate files are kept in a database, typically with an .xca extenion.
Todo: Url and home page. Configuration, installation (rpm, yum). Add Some images showing the UI.
The TinyCA is a gui and front end suited to creating Certificate Authority files.
Todo: Url and home page. Configuration, installation (rpm, yum). Add Some images showing the UI.
There is a heap of documentation for SSL certificates and openssl(1) , the following urls may be of interest:
Stuart Moorfoot © 13 July 2006 foo@bund.com.au