Setting Up TLS/SSL with Other Tools

3 Setting Up TLS/SSL with Other Tools

This chapter describes some other tools available for setting up TLS/SSL that you may consider.

There are various reasons to choose one tool over another. For example, some tools are more light weight than others, or some are targeted to specific environments, such as the keytool for Java. Some not only cover certificates infrastructure management but also include other features, APIs, and libraries for developing applications that enable various other secure network protocols and security standards. Although this book does not provide details about such features, you can find more information about them in corresponding manual pages and documentation from opensource projects.

GnuTLS

This chapter describes the certtool GnuTLS certificate tool that is available in Oracle Linux and how to use it to create certificate signing requests, self-signed certificates, and privately owned CA certificates. GnuTLS is a library implementing the SSL, TLS and DTLS protocols and technologies around them for the purpose of securing communications. It includes an application programming interface (API) written in C language to access the secure communications protocols and additional APIs to parse and write structures such as X.509, PKCS #12, and OpenPGP.

To use certtool, install the gnutls-utils package avaiable from the Application Stream repository.

sudo dnf install gnutls-utils

Note:

If you are using Oracle Linux 7, you can install the package from the ol7_latest yum repository by using yum instead of dnf.

The following examples show how to use the certtool command to create certificate signing requests, self-signed certificates, and privately owned CA certificates.

To generate a private key, do the following.
```
sudo certtool --generate-privkey --outfile private_key_file
```
In the previous example, private_key_file is the name of the private key file.
To generate a CSR, do the following:
```
sudo certtool --generate-request --load-privkey private_key_file --outfile csr_file
```
In the previous example, csr_file is the name of the CSR file.

To generate a self-signed certificate, do the following:

sudo certtool --generate-self-signed --load-privkey private_key_file --outfile self_signed_certificate_file

For more information, see the certtool(1) manual page and the GnuTLS open source project at https://www.gnutls.org/.

NSS

This chapter describes the certutil Network Security Service (NSS) certificate tool that is available in Oracle Linux and how to use it to create Certificate Signing Requests (CSRs), self-signed certificates, and privately owned CA certificates with NSS database files which store certificates and private keys for applications.

NSS is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards.

Before you can use certutil to manage certificates, CSRs, and keys, you must have access to the NSS database files. You can use the legacy security databases files (cert8.db for certificates, key3.db for keys, and secmod.db for PKCS #11 module information) or the new SQLite databases files (cert9.db for certificates, key4.db for keys, and pkcs11.txt for PKCS #11 modules). This section provides examples from the new database files.

You can also use the related pk12util command to export and import certificates and keys from a PKCS #12 file to an NSS database or the reverse.

To use certutil and pk12util, install the nss-tools package avaiable from the Application Stream repository.

sudo dnf install nss-tools

Note:

If you are using Oracle Linux 7, you can install the package from the ol7_latest yum repository by using yum instead of dnf.

The following examples show how to use the certutil and and pk12util commands.

To create an NSS database, do the following:
```
certutil -N -d database_directory
```
In the previous example, database_directory is the home directory where you want to create the the cert9.db, key4.db, and pkcs11.txt NSS database files. For example the following creates the database in a folder called nssdb in the home directory of the terminal's user account:
```
certutil -N -d ~/nssdb
```
To generate a self-signed certificate, do the following:
```
certutil -d database_directory -S -s subject -n nickname -x -t trust_args -o file
```
In the previous example,
- -S Indicates that you want to create an individual certificate and add it to a certificate database.
- -s Indicates that you want to specify a distinguished name where subject uses the distinguished name format defined in https://www.rfc-editor.org/rfc/rfc1485.html.
- -n Indicates that you want to specify a nickname where nickname is the nickname for the entity you are creating.
- -x Indicates you want to generate the signature for a certificate being created or added to a database, rather than obtaining a signature from a separate CA.
- -t Indicates you want to add trust arguments where trust_args are the trust attributes that you want to apply to the certificate. There are three available trust categories for each certificate, expressed in the order SSL, email, object signing for each trust setting. In each category position, use none, any, or all of the attribute codes. Valid codes are:
  - p - Valid peer
  - P - Trusted peer (includes p)
  - c - Valid CA
  - C - Trusted CA (includes c)
  - T - Trusted CA for client authentication (ssl server only)
For example, the following creates a self-signed certificate for the www1.example.com common name with the example_test nickname. The trust attributes are C (Trusted CA) for each category.
```
certutil -d ~/nssdb/ -S -s 'CN=www1.example.com, O=Example Organization, L=Ottawa, C=CA' -n example_test -x -t C,C,C
```
To add existing certificates or certificates generated elsewhere, do the following:
```
certutil -A -n nickname -t trust_args -d database_directory -i input-file
```
In the previous example,
- -A Indicates that you want to add a certificate to a certificate database.
- -i Indicates that you want to provide an input file, such as a certificate file, for example, a PEM file.
For example,
```
certutil -A -n "CN=My SSL Certificate" -t C,C,C -d ~/nssdb/ -i ~/tls-ca-bundle.pem
```

To get list of all certificates, do the following:

certutil -L -d database_directory

For example,

certutil -L -d ~/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

example_test                                                 Cu,Cu,Cu
CN=My SSL Certificate                                        C,C,C

When listing certificates, the trust tags may include the u flag indicating that a private key is associated with the certificate.

To delete a certificate from your database, do the following:
```
certutil -D -d database_directory -n nickname
```
In the previous example, -D indicates that you want to delete a specific certificate from your database.

To get a list of all keys, do the following:

certutil certutil -K -d database_directory

For example,

certutil -K -d ~/nssdb/
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa      35f4555f329c1490b3570c9d36e1ec56f2329f08   NSS Certificate DB:example_test
< 1> rsa      303936d20b3522e9293b75db3dc48f77c1871767   NSS Certificate DB:example_test2

To show a public key in PEM format, do the following:

certutil -L -d database_directory -a -n nickname

For example,

certutil -L -d ~/nssdb/ -a -n example_test
-----BEGIN CERTIFICATE-----
...[certificate text]
-----END CERTIFICATE-----

To export a certificate and key into a single PKCS #12 file, do the following:
```
pk12util -o certs.p12 -n example_test -d sql:database_directory
```
To modify a certificate, use the -M option. For example, the following changes the trust arguments from C, C, C, to P,P,P for the example_test certificate:
```
$ certutil -d database_directory -M -t "P,P,P" -n example_test
```

For more information, see the certutil(1) and pk12util(1) manual pages and the NSS open source project at https://firefox-source-docs.mozilla.org/security/nss/index.html.

Java

Most Java applications use the keystore that's supplied with JDK to store cryptographic keys, X.509 certificate chain information, and trusted certificates. The default JDK keystore in Oracle Linux is the /etc/pki/java/cacerts file. You can use the keytool command to generate, install and manage certificates in the Java keystore.

The following examples show how you might use the keytool command.

List the contents of the keystore, /etc/pki/java/cacerts:
```
sudo keytool -list [-v] -keystore /etc/pki/java/cacerts
```
The default keystore password is changeit. Oracle strongly recommends that you change the password as soon as possible. If specified, the verbose option -v displays detailed information.
Change the password for a keystore, for example, /etc/pki/java/cacerts:
```
sudo keytool -storepasswd -keystore /etc/pki/java/cacerts
```
Create a keystore (keystore.jks) to achieve the following:
- Manage public and private key pairs and certificates from entities that you trust.
- Generate a public and private key pair by using the RSA algorithm and a key length of 3072 bits.
- Create a self-signed certificate that includes the public key and the specified distinguished name information.
```
sudo keytool -genkeypair -alias mycert -keyalg RSA -keysize 3072 \
-dname "CN=www.unserdom.com, OU=Eng, O=Unser Dom Corp, C=US, ST=Ca, L=Sunnydale" \
-alias engineering -keypass pkpassword -keystore keystore.jks \
-storepass storepassword -validity 100
```
In the command, pkpassword is the private key password and storepassword is the keystore password. In this example, the certificate is valid for 100 days and is associated with the private key in a keystore entry that has the alias engineering.
Print the contents of a certificate file in a human-readable form:
```
sudo keytool -printcert [-v] -file cert.cer
```
If specified, the verbose option -v displays detailed information.
Generate a CSR in the file carequest.csr for submission to a CA:
```
sudo keytool -certreq -file carequest.csr
```
The CA signs and returns a certificate or a certificate chain that authenticates your public key.
Import the root certificate or certificate chain for the CA from the ACME.cer file into the keystore.jks keystore and assign it the alias acmeca:
```
sudo keytool -importcert -alias acmeca [-trustcacerts] -file ACME.cer \
-keystore keystore.jks -storepass storepassword
```
If specified, the -trustcacerts option instructs keytool to add the certificate only if it can validate the chain of trust against the existing root CA certificates in the cacerts keystore. Alternatively, you can use the keytool -printcert command to check that the certificate's fingerprint matches the fingerprint that the CA publishes.
Import the signed certificate for the organization after you have received it from the CA:
```
sudo keytool -importcert -v -trustcacerts -alias acmeca -file ACMEdom.cer \
-keystore keystore.jks -storepass storepassword
```
In this example, the file containing the certificate is ACMEdom.cer. The -alias option specifies the entry for the first entity in the CA's root certificate chain. The signed certificate is added to the front of the chain and becomes the entity that's addressed by the alias name.

Delete the certificate with the alias aliasname from the keystore.jks keystore:

sudo keytool -delete -alias aliasname -keystore keystore.jks -storepass storepassword

Export the certificate with the alias aliasname as a binary PKCS7 format file, which includes the supporting certificate chain as well as the issued certificate:
```
sudo keytool -exportcert -noprompt -alias aliasname -file output.p7b \
-keystore keystore.jks -storepass storepassword
```
Export the certificate with the alias aliasname as a base64 encoded text file (also referred to as PEM or RFC 1421).
```
sudo keytool -exportcert -noprompt -rfc -alias aliasname -file output.pem \
-keystore keystore.jks -storepass storepassword
```
For a certificate chain, the file includes only the first certificate in the chain, which authenticates the public key of the aliased entity.

For more information, see the keytool(1) manual page.