Ce contenu n'est pas disponible dans la langue sélectionnée.
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
Installing OpenSSL on RHEL and Fedora platforms
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
Source code distribution
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
Overview
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
To set up your own private Certificate Authority:
- Create the directory structure for the CA, as follows:
X509CA/demoCA X509CA/demoCA/private X509CA/demoCA/certs X509CA/demoCA/newcerts X509CA/demoCA/crl
- 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
ImportantThe precedingopenssl.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. - Initialize the
demoCA/serial
file, which must have the initial contents01
(zero one). Enter the following command:echo 01 > demoCA/serial
- Initialize the
demoCA/index.txt
, which must initially be completely empty. Enter the following command:touch demoCA/index.txt
- 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
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
NoteThe 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
andcakey.pem
, are the same as the values specified inopenssl.cfg
.
A.5.3. Create a CA Trust Store File
Overview
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
To add one of more CA certificates to a trust store file:
- 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.
- 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
Wheretruststore.ts
is a keystore file containing CA certificates. If this file does not already exist, the keytool command creates it. TheCAAlias
is a convenient identifier for the imported CA certificate andStorePass
is the password required to access the keystore file. - Repeat the previous step to add all of the CA certificates to the trust store.
A.5.4. Generate and Sign a New Certificate
Overview
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
To generate and sign a new certificate, using your own private CA, perform the following steps:
- 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
Because the specified keystore,alice.ks
, did not exist prior to issuing the command implicitly creates a new keystore and sets its password toStorePass
.The-dname
and-validity
flags define the contents of the newly created X.509 certificate.NoteWhen specifying the certificate's Distinguished Name (through the-dname
parameter), you must be sure to observe any policy constraints specified in theopenssl.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).NoteIt 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, thekeytool
utility uses an SHA-2 algorithm instead. - 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 thealice_csr.pem
file, as follows:keytool -certreq -alias alice -file alice_csr.pem -keypass KeyPass -keystore alice.ks -storepass StorePass
- 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
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#. - Convert the signed certificate to PEM only format using the openssl x509 command with the
-outform
option set toPEM
. Enter the following command:openssl x509 -in alice_signed.pem -out alice_signed.pem -outform PEM
- 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
- 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