Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

A.5. Creating Your Own Certificates

Abstract

This chapter describes the techniques and procedures to set up your own private Certificate Authority (CA) and to use this CA to generate and sign your own certificates.
Warning
Creating and managing your own certificates requires an expert knowledge of security. While the procedures described in this chapter can be convenient for generating your own certificates for demonstration and testing environments, it is not recommended to use these certificates in a production environment.

A.5.1. Install the OpenSSL Utilities
Copy link

Installing OpenSSL on RHEL and Fedora platforms
Copy link

On Red Hat Enterprise Linux (RHEL) 5 and 6 and Fedora platforms, are made available as an RPM package. To install OpenSSL, enter the following command (executed with administrator privileges): 
yum install openssl
Copy to Clipboard Toggle word wrap

Source code distribution
Copy link

The source distribution of OpenSSL is available from http://www.openssl.org/docs. The OpenSSL project provides source code distributions only. You cannot download a binary install of the OpenSSL utilities from the OpenSSL Web site.

A.5.2. Set Up a Private Certificate Authority
Copy link

Overview
Copy link

If you choose to use a private CA you need to generate your own certificates for your applications to use. The OpenSSL project provides free command-line utilities for setting up a private CA, creating signed certificates, and adding the CA to your Java keystore.
Warning
Setting up a private CA for a production environment requires a high level of expertise and extra care must be taken to protect the certificate store from external threats.

Steps to set up a private Certificate Authority
Copy link

To set up your own private Certificate Authority:
  1. Create the directory structure for the CA, as follows: 
    X509CA/demoCA
X509CA/demoCA/private
X509CA/demoCA/certs
X509CA/demoCA/newcerts
X509CA/demoCA/crl
    Copy to Clipboard Toggle word wrap
  2. Using a text editor, create the file, X509CA/openssl.cfg, and add the following contents to this file:

    Example A.1. OpenSSL Configuration

    #
# SSLeay example configuration file.
# This is mostly being used for generation of certificate requests.
#

RANDFILE            = ./.rnd

####################################################################
[ req ]
default_bits        = 2048
default_keyfile     = keySS.pem
distinguished_name  = req_distinguished_name
encrypt_rsa_key     = yes
default_md          = sha1

[ req_distinguished_name ]
countryName         = Country Name (2 letter code)

organizationName    = Organization Name (eg, company)

commonName          = Common Name (eg, YOUR name)

####################################################################
[ ca ]
default_ca         = CA_default        # The default ca section

####################################################################
[ CA_default ]

dir                = ./demoCA              # Where everything is kept
certs              = $dir/certs            # Where the issued certs are kept
crl_dir            = $dir/crl              # Where the issued crl are kept
database           = $dir/index.txt        # database index file.
#unique_subject    = no                    # Set to 'no' to allow creation of
                                           # several certificates with same subject.
new_certs_dir      = $dir/newcerts         # default place for new certs.

certificate        = $dir/cacert.pem       # The CA certificate
serial             = $dir/serial           # The current serial number
crl                = $dir/crl.pem          # The current CRL
private_key        = $dir/private/cakey.pem# The private key
RANDFILE           = $dir/private/.rand    # private random number file

name_opt           = ca_default            # Subject Name options
cert_opt           = ca_default            # Certificate field options

default_days       = 365                   # how long to certify for
default_crl_days   = 30                    # how long before next CRL
default_md         = md5                   # which md to use.
preserve           = no                    # keep passed DN ordering

policy             = policy_anything

[ policy_anything ]
countryName            = optional
stateOrProvinceName    = optional
localityName           = optional
organizationName       = optional
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional
    Copy to Clipboard Toggle word wrap
    Important
    The preceding openssl.cfg configuration file is provided as a demonstration only. In a production environment, this configuration file would need to be carefully elaborated by an engineer with a high level of security expertise, and actively maintained to protect against evolving security threats.
  3. Initialize the demoCA/serial file, which must have the initial contents 01 (zero one). Enter the following command: 
    echo 01 > demoCA/serial
    Copy to Clipboard Toggle word wrap
  4. Initialize the demoCA/index.txt, which must initially be completely empty. Enter the following command: 
    touch demoCA/index.txt
    Copy to Clipboard Toggle word wrap
  5. Create a new self-signed CA certificate and private key with the command: 
    openssl req -x509 -new -config openssl.cfg -days 365 -out demoCA/cacert.pem -keyout demoCA/private/cakey.pem
    Copy to Clipboard Toggle word wrap
    You are prompted for a pass phrase for the CA private key and details of the CA distinguished name as shown in Example A.2, “Creating a CA Certificate”.

    Example A.2. Creating a CA Certificate

    Generating a 2048 bit RSA private key
...........................................................................+++
.................+++
writing new private key to 'demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:DE
Organization Name (eg, company) []:Red Hat
Common Name (eg, YOUR name) []:Scooby Doo
    Copy to Clipboard Toggle word wrap
    Note
    The security of the CA depends on the security of the private key file and the private key pass phrase used in this step.
    You must ensure that the file names and location of the CA certificate and private key, cacert.pem and cakey.pem, are the same as the values specified in openssl.cfg.

A.5.3. Create a CA Trust Store File
Copy link

Overview
Copy link

A trust store file is commonly required on the client side of an SSL/TLS connection, in order to verify a server's identity. A trust store file can also be used to check digital signatures (for example, to check that a signature was made using the private key corresponding to one of the trusted certificates in the trust store file).

Steps to create a CA trust store
Copy link

To add one of more CA certificates to a trust store file:
  1. Assemble the collection of trusted CA certificates that you want to deploy.
    The trusted CA certificates can be obtained from public CAs or private CAs. The trusted CA certificates can be in any format that is compatible with the Java keystore utility; for example, PEM format. All you need are the certificates themselves—the private keys and passwords are not required.
  2. Add a CA certificate to the trust store using the keytool -import command.
    Enter the following command to add the CA certificate, cacert.pem, in PEM format, to a JKS trust store. 
    keytool -import -file cacert.pem -alias CAAlias -keystore truststore.ts -storepass StorePass
    Copy to Clipboard Toggle word wrap
    Where truststore.ts is a keystore file containing CA certificates. If this file does not already exist, the keytool command creates it. The CAAlias is a convenient identifier for the imported CA certificate and StorePass is the password required to access the keystore file.
  3. Repeat the previous step to add all of the CA certificates to the trust store.

A.5.4. Generate and Sign a New Certificate
Copy link

Overview
Copy link

In order for a certificate to be useful in the real world, it must be signed by a CA, which vouches for the authenticity of the certificate. This facilitates a scalable solution for certificate verification, because it means that a single CA certificate can be used to verify a large collection of certificates.

Steps to generate and sign a new certificate
Copy link

To generate and sign a new certificate, using your own private CA, perform the following steps:
  1. Generate a certificate and private key pair using the keytool -genkeypair command, as follows: 
    keytool -genkeypair -keyalg RSA -dname "CN=Alice, OU=Engineering, O=Red Hat, ST=Dublin, C=IE" -validity 365 -alias alice -keypass KeyPass -keystore alice.ks -storepass StorePass
    Copy to Clipboard Toggle word wrap
    Because the specified keystore, alice.ks, did not exist prior to issuing the command implicitly creates a new keystore and sets its password to StorePass.
    The -dname and -validity flags define the contents of the newly created X.509 certificate.
    Note
    When specifying the certificate's Distinguished Name (through the -dname parameter), you must be sure to observe any policy constraints specified in the openssl.cfg file. If those policy constraints are not heeded, you will not be able to sign the certificate using the CA (in the next steps).
    Note
    It is essential to generate the key pair with the -keyalg RSA option (or a key algorithm of similar strength). The default key algorithm uses a combination of DSA encryption and SHA-1 signature. But the SHA-1 algorithm is no longer regarded as sufficiently secure and modern Web browsers will reject certificates signed using SHA-1. When you select the RSA key algorithm, the keytool utility uses an SHA-2 algorithm instead.
  2. Create a certificate signing request using the keystore -certreq command.
    Create a new certificate signing request for the alice.ks certificate and export it to the alice_csr.pem file, as follows: 
    keytool -certreq -alias alice -file alice_csr.pem -keypass KeyPass -keystore alice.ks -storepass StorePass
    Copy to Clipboard Toggle word wrap
  3. Sign the CSR using the openssl ca command.
    Sign the CSR for the Alice certificate, using your private CA, as follows: 
    openssl ca -config openssl.cfg -days 365 -in alice_csr.pem -out alice_signed.pem
    Copy to Clipboard Toggle word wrap
    You will prompted to enter the CA private key pass phrase you used when creating the CA (in Step 5).
    For more details about the openssl ca command see http://www.openssl.org/docs/apps/ca.html#.
  4. Convert the signed certificate to PEM only format using the openssl x509 command with the -outform option set to PEM. Enter the following command: 
    openssl x509 -in alice_signed.pem -out alice_signed.pem -outform PEM
    Copy to Clipboard Toggle word wrap
  5. Concatenate the CA certificate file and the converted, signed certificate file to form a certificate chain. For example, on Linux and UNIX platforms, you can concatenate the CA certificate file and the signed Alice certificate, alice_signed.pem, as follows: 
    cat demoCA/cacert.pem alice_signed.pem > alice.chain
    Copy to Clipboard Toggle word wrap
  6. Import the new certificate's full certificate chain into the Java keystore using the keytool -import command. Enter the following command: 
    keytool -import -file alice.chain -keypass KeyPass -keystore alice.ks -storepass StorePass
    Copy to Clipboard Toggle word wrap
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat