Chapter 2. Managing Certificates
Chapter 2. Managing Certificates Abstract TLS authentication uses X.509 certificates-a common, secure and reliable method of authenticating your application objects. You can create X.509 certificates that identify your Red Hat Fuse applications. 2.1. What is an X.509 Certificate? Role of certificates An X.509 certificate binds a name to a public key value. The role of the certificate is to associate a public key with the identity contained in the X.509 certificate. Integrity of the public key Authentication of a secure application depends on the integrity of the public key value in the application's certificate. If an impostor replaces the public key with its own public key, it can impersonate the true application and gain access to secure data. To prevent this type of attack, all certificates must be signed by a certification authority (CA). A CA is a trusted node that confirms the integrity of the public key value in a certificate. Digital signatures A CA signs a certificate by adding its digital signature to the certificate. A digital signature is a message encoded with the CA's private key. The CA's public key is made available to applications by distributing a certificate for the CA. Applications verify that certificates are validly signed by decoding the CA's digital signature with the CA's public key. Warning The supplied demonstration certificates are self-signed certificates. These certificates are insecure because anyone can access their private key. To secure your system, you must create new certificates signed by a trusted CA. Contents of an X.509 certificate An X.509 certificate contains information about the certificate subject and the certificate issuer (the CA that issued the certificate). A certificate is encoded in Abstract Syntax Notation One (ASN.1), a standard syntax for describing messages that can be sent or received on a network. The role of a certificate is to associate an identity with a public key value. In more detail, a certificate includes: A subject distinguished name (DN) that identifies the certificate owner. The public key associated with the subject. X.509 version information. A serial number that uniquely identifies the certificate. An issuer DN that identifies the CA that issued the certificate. The digital signature of the issuer. Information about the algorithm used to sign the certificate. Some optional X.509 v.3 extensions; for example, an extension exists that distinguishes between CA certificates and end-entity certificates. Distinguished names A DN is a general purpose X.500 identifier that is often used in the context of security. See Appendix A, ASN.1 and Distinguished Names for more details about DNs. 2.2. Certification Authorities 2.2.1. Introduction to Certificate Authorities A CA consists of a set of tools for generating and managing certificates and a database that contains all of the generated certificates. When setting up a system, it is important to choose a suitable CA that is sufficiently secure for your requirements. There are two types of CA you can use: commercial CAs are companies that sign certificates for many systems. private CAs are trusted nodes that you set up and use to sign certificates for your system only. 2.2.2. Commercial Certification Authorities Signing certificates There are several commercial CAs available. The mechanism for signing a certificate using a commercial CA depends on which CA you choose. Advantages of commercial CAs An advantage of commercial CAs is that they are often trusted by a large number of people. If your applications are designed to be available to systems external to your organization, use a commercial CA to sign your certificates. If your applications are for use within an internal network, a private CA might be appropriate. Criteria for choosing a CA Before choosing a commercial CA, consider the following criteria: What are the certificate-signing policies of the commercial CAs? Are your applications designed to be available on an internal network only? What are the potential costs of setting up a private CA compared to the costs of subscribing to a commercial CA? 2.2.3. Private Certification Authorities Choosing a CA software package If you want to take responsibility for signing certificates for your system, set up a private CA. To set up a private CA, you require access to a software package that provides utilities for creating and signing certificates. Several packages of this type are available. OpenSSL software package One software package that allows you to set up a private CA is OpenSSL, http://www.openssl.org . The OpenSSL package includes basic command line utilities for generating and signing certificates. Complete documentation for the OpenSSL command line utilities is available at http://www.openssl.org/docs . Setting up a private CA using OpenSSL To set up a private CA, see the instructions in Section 2.5, "Creating Your Own Certificates" . Choosing a host for a private certification authority Choosing a host is an important step in setting up a private CA. The level of security associated with the CA host determines the level of trust associated with certificates signed by the CA. If you are setting up a CA for use in the development and testing of Red Hat Fuse applications, use any host that the application developers can access. However, when you create the CA certificate and private key, do not make the CA private key available on any hosts where security-critical applications run. Security precautions If you are setting up a CA to sign certificates for applications that you are going to deploy, make the CA host as secure as possible. For example, take the following precautions to secure your CA: Do not connect the CA to a network. Restrict all access to the CA to a limited set of trusted users. Use an RF-shield to protect the CA from radio-frequency surveillance. 2.3. Certificate Chaining Certificate chain A certificate chain is a sequence of certificates, where each certificate in the chain is signed by the subsequent certificate. Figure 2.1, "A Certificate Chain of Depth 2" shows an example of a simple certificate chain. Figure 2.1. A Certificate Chain of Depth 2 Self-signed certificate The last certificate in the chain is normally a self-signed certificate -a certificate that signs itself. Chain of trust The purpose of a certificate chain is to establish a chain of trust from a peer certificate to a trusted CA certificate. The CA vouches for the identity in the peer certificate by signing it. If the CA is one that you trust (indicated by the presence of a copy of the CA certificate in your root certificate directory), this implies you can trust the signed peer certificate as well. Certificates signed by multiple CAs A CA certificate can be signed by another CA. For example, an application certificate could be signed by the CA for the finance department of Progress Software, which in turn is signed by a self-signed commercial CA. Figure 2.2, "A Certificate Chain of Depth 3" shows what this certificate chain looks like. Figure 2.2. A Certificate Chain of Depth 3 Trusted CAs An application can accept a peer certificate, provided it trusts at least one of the CA certificates in the signing chain. 2.4. Special Requirements on HTTPS Certificates Overview The HTTPS specification mandates that HTTPS clients must be capable of verifying the identity of the server. This can potentially affect how you generate your X.509 certificates. The mechanism for verifying the server identity depends on the type of client. Some clients might verify the server identity by accepting only those server certificates signed by a particular trusted CA. In addition, clients can inspect the contents of a server certificate and accept only the certificates that satisfy specific constraints. In the absence of an application-specific mechanism, the HTTPS specification defines a generic mechanism, known as the HTTPS URL integrity check , for verifying the server identity. This is the standard mechanism used by Web browsers. HTTPS URL integrity check The basic idea of the URL integrity check is that the server certificate's identity must match the server host name. This integrity check has an important impact on how you generate X.509 certificates for HTTPS: the certificate identity (usually the certificate subject DN's common name) must match the host name on which the HTTPS server is deployed . The URL integrity check is designed to prevent man-in-the-middle attacks. Reference The HTTPS URL integrity check is specified by RFC 2818, published by the Internet Engineering Task Force (IETF) at http://www.ietf.org/rfc/rfc2818.txt . How to specify the certificate identity The certificate identity used in the URL integrity check can be specified in one of the following ways: Using commonName Using subectAltName Using commonName The usual way to specify the certificate identity (for the purpose of the URL integrity check) is through the Common Name (CN) in the subject DN of the certificate. For example, if a server supports secure TLS connections at the following URL: The corresponding server certificate would have the following subject DN: Where the CN has been set to the host name, www.redhat.com . For details of how to set the subject DN in a new certificate, see Section 2.5, "Creating Your Own Certificates" . Using subjectAltName (multi-homed hosts) Using the subject DN's Common Name for the certificate identity has the disadvantage that only one host name can be specified at a time. If you deploy a certificate on a multi-homed host, however, you might find it is practical to allow the certificate to be used with any of the multi-homed host names. In this case, it is necessary to define a certificate with multiple, alternative identities, and this is only possible using the subjectAltName certificate extension. For example, if you have a multi-homed host that supports connections to either of the following host names: Then you can define a subjectAltName that explicitly lists both of these DNS host names. If you generate your certificates using the openssl utility, edit the relevant line of your openssl.cnf configuration file to specify the value of the subjectAltName extension, as follows: Where the HTTPS protocol matches the server host name against either of the DNS host names listed in the subjectAltName (the subjectAltName takes precedence over the Common Name). The HTTPS protocol also supports the wildcard character, \* , in host names. For example, you can define the subjectAltName as follows: This certificate identity matches any three-component host name in the domain jboss.org . Warning You must never use the wildcard character in the domain name (and you must take care never to do this accidentally by forgetting to type the dot, . , delimiter in front of the domain name). For example, if you specified *jboss.org , your certificate could be used on *any* domain that ends in the letters jboss . 2.5. Creating Your Own Certificates 2.5.1. Prerequisites OpenSSL utilities The steps described in this section are based on the OpenSSL command-line utilities from the OpenSSL project. Further documentation of the OpenSSL command-line utilities can be obtained at http://www.openssl.org/docs/ . Sample CA directory structure For the purposes of illustration, the CA database is assumed to have the following directory structure: X509CA /ca X509CA /certs X509CA /newcerts X509CA /crl Where X509CA is the parent directory of the CA database. 2.5.2. Set Up Your Own CA Substeps to perform This section describes how to set up your own private CA. Before setting up a CA for a real deployment, read the additional notes in Section 2.2.3, "Private Certification Authorities" . To set up your own CA, perform the following steps: the section called "Add the bin directory to your PATH" the section called "Create the CA directory hierarchy" the section called "Copy and edit the openssl.cnf file" the section called "Initialize the CA database" the section called "Create a self-signed CA certificate and private key" Add the bin directory to your PATH On the secure CA host, add the OpenSSL bin directory to your path: Windows UNIX This step makes the openssl utility available from the command line. Create the CA directory hierarchy Create a new directory, X509CA , to hold the new CA. This directory is used to hold all of the files associated with the CA. Under the X509CA directory, create the following hierarchy of directories: X509CA /ca X509CA /certs X509CA /newcerts X509CA /crl Copy and edit the openssl.cnf file Copy the sample openssl.cnf from your OpenSSL installation to the X509CA directory. Edit the openssl.cnf to reflect the directory structure of the X509CA directory, and to identify the files used by the new CA. Edit the [CA_default] section of the openssl.cnf file to look like the following: You might decide to edit other details of the OpenSSL configuration at this point-for more details, see http://www.openssl.org/docs/ . Initialize the CA database In the X509CA directory, initialize two files, serial and index.txt . Windows To initialize the serial file in Windows, enter the following command: To create an empty file, index.txt , in Windows start Windows Notepad at the command line in the X509CA directory, as follows: In response to the dialog box with the text, Cannot find the text.txt file. Do you want to create a new file? , click Yes , and close Notepad. UNIX To initialize the serial file and the index.txt file in UNIX, enter the following command: These files are used by the CA to maintain its database of certificate files. Note The index.txt file must initially be completely empty, not even containing white space. Create a self-signed CA certificate and private key Create a new self-signed CA certificate and private key with the following command: The command prompts you for a pass phrase for the CA private key and details of the CA distinguished name. For example: 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, new_ca.pem and new_ca_pk.pem , are the same as the values specified in openssl.cnf (see the preceding step). You are now ready to sign certificates with your CA. 2.5.3. Use the CA to Create Signed Certificates in a Java Keystore Substeps to perform To create and sign a certificate in a Java keystore (JKS), CertName .jks , perform the following substeps: the section called "Add the Java bin directory to your PATH" the section called "Generate a certificate and private key pair" the section called "Create a certificate signing request" the section called "Sign the CSR" the section called "Convert to PEM format" the section called "Concatenate the files" the section called "Update keystore with the full certificate chain" the section called "Repeat steps as required" Add the Java bin directory to your PATH If you have not already done so, add the Java bin directory to your path: Windows UNIX This step makes the keytool utility available from the command line. Generate a certificate and private key pair Open a command prompt and change directory to the directory where you store your keystore files, KeystoreDir . Enter the following command: This keytool command, invoked with the -genkey option, generates an X.509 certificate and a matching private key. The certificate and the key are both placed in a key entry in a newly created keystore, CertName .jks . Because the specified keystore, CertName .jks , did not exist prior to issuing the command, keytool implicitly creates a new keystore. The -dname and -validity flags define the contents of the newly created X.509 certificate, specifying the subject DN and the days before expiration respectively. For more details about DN format, see Appendix A, ASN.1 and Distinguished Names . Some parts of the subject DN must match the values in the CA certificate (specified in the CA Policy section of the openssl.cnf file). The default openssl.cnf file requires the following entries to match: Country Name (C) State or Province Name (ST) Organization Name (O) Note If you do not observe the constraints, the OpenSSL CA will refuse to sign the certificate (see the section called "Sign the CSR" ). Create a certificate signing request Create a new certificate signing request (CSR) for the CertName .jks certificate, as follows: This command exports a CSR to the file, CertName _csr.pem . Sign the CSR Sign the CSR using your CA, as follows: To sign the certificate successfully, you must enter the CA private key pass phrase (see Section 2.5.2, "Set Up Your Own CA" ). Note If you want to sign the CSR using a CA certificate other than the default CA, use the -cert and -keyfile options to specify the CA certificate and its private key file, respectively. Convert to PEM format Convert the signed certificate, CertName .pem , to PEM only format, as follows: Concatenate the files Concatenate the CA certificate file and CertName .pem certificate file, as follows: Windows UNIX Update keystore with the full certificate chain Update the keystore, CertName .jks , by importing the full certificate chain for the certificate, as follows: Repeat steps as required Repeat steps 2 through 7, to create a complete set of certificates for your system. 2.5.4. Use the CA to Create Signed PKCS#12 Certificates Substeps to perform If you have set up a private CA, as described in Section 2.5.2, "Set Up Your Own CA" , you are now ready to create and sign your own certificates. To create and sign a certificate in PKCS#12 format, CertName .p12 , perform the following substeps: the section called "Add the bin directory to your PATH" . the section called "Configure the subjectAltName extension (Optional)" . the section called "Create a certificate signing request" . the section called "Sign the CSR" . the section called "Concatenate the files" . the section called "Create a PKCS#12 file" . the section called "Repeat steps as required" . the section called "(Optional) Clear the subjectAltName extension" . Add the bin directory to your PATH If you have not already done so, add the OpenSSL bin directory to your path, as follows: Windows UNIX This step makes the openssl utility available from the command line. Configure the subjectAltName extension (Optional) Perform this step, if the certificate is intended for a HTTPS server whose clients enforce URL integrity check, and if you plan to deploy the server on a multi-homed host or a host with several DNS name aliases (for example, if you are deploying the certificate on a multi-homed Web server). In this case, the certificate identity must match multiple host names and this can be done only by adding a subjectAltName certificate extension (see Section 2.4, "Special Requirements on HTTPS Certificates" ). To configure the subjectAltName extension, edit your CA's openssl.cnf file as follows: Add the following req_extensions setting to the [req] section (if not already present in your openssl.cnf file): Add the [v3_req] section header (if not already present in your openssl.cnf file). Under the [v3_req] section, add or modify the subjectAltName setting, setting it to the list of your DNS host names. For example, if the server host supports the alternative DNS names, www.redhat.com and jboss.org , set the subjectAltName as follows: Add a copy_extensions setting to the appropriate CA configuration section. The CA configuration section used for signing certificates is one of the following: The section specified by the -name option of the openssl ca command, The section specified by the default_ca setting under the [ca] section (usually [CA_default] ). For example, if the appropriate CA configuration section is [CA_default] , set the copy_extensions property as follows: This setting ensures that certificate extensions present in the certificate signing request are copied into the signed certificate. Create a certificate signing request Create a new certificate signing request (CSR) for the CertName .p12 certificate, as shown: This command prompts you for a pass phrase for the certificate's private key, and for information about the certificate's distinguished name. Some of the entries in the CSR distinguished name must match the values in the CA certificate (specified in the CA Policy section of the openssl.cnf file). The default openssl.cnf file requires that the following entries match: Country Name State or Province Name Organization Name The certificate subject DN's Common Name is the field that is usually used to represent the certificate owner's identity. The Common Name must comply with the following conditions: The Common Name must be distinct for every certificate generated by the OpenSSL certificate authority. If your HTTPS clients implement the URL integrity check, you must ensure that the Common Name is identical to the DNS name of the host where the certificate is to be deployed (see Section 2.4, "Special Requirements on HTTPS Certificates" ). Note For the purpose of the HTTPS URL integrity check, the subjectAltName extension takes precedence over the Common Name. Sign the CSR Sign the CSR using your CA, as follows: This command requires the pass phrase for the private key associated with the new_ca.pem CA certificate. For example: To sign the certificate successfully, you must enter the CA private key pass phrase (see Section 2.5.2, "Set Up Your Own CA" ). Note If you did not set copy_extensions=copy under the [CA_default] section in the openssl.cnf file, the signed certificate will not include any of the certificate extensions that were in the original CSR. Concatenate the files Concatenate the CA certificate file, CertName .pem certificate file, and CertName _pk.pem private key file as follows: Windows UNIX Create a PKCS#12 file Create a PKCS#12 file from the CertName _list.pem file as follows: You are prompted to enter a password to encrypt the PKCS#12 certificate. Usually this password is the same as the CSR password (this is required by many certificate repositories). Repeat steps as required Repeat steps 3 through 6, to create a complete set of certificates for your system. (Optional) Clear the subjectAltName extension After generating certificates for a particular host machine, it is advisable to clear the subjectAltName setting in the openssl.cnf file to avoid accidentally assigning the wrong DNS names to another set of certificates. In the openssl.cnf file, comment out the subjectAltName setting (by adding a # character at the start of the line), and also comment out the copy_extensions setting.
https://www.redhat.com/secure C=IE,ST=Co. Dublin,L=Dublin,O=RedHat, OU=System,CN=www.redhat.com www.redhat.com www.jboss.org subjectAltName=DNS:www.redhat.com,DNS:www.jboss.org subjectAltName=DNS:*.jboss.org > set PATH= OpenSSLDir \bin;%PATH% % PATH= OpenSSLDir /bin:USDPATH; export PATH ############################################################# [ CA_default ] dir = X509CA # Where CA files are kept certs = USDdir/certs # Where issued certs are kept crl_dir = USDdir/crl # Where the issued crl are kept database = USDdir/index.txt # Database index file new_certs_dir = USDdir/newcerts # Default place for new certs certificate = USDdir/ca/new_ca.pem # The CA certificate serial = USDdir/serial # The current serial number crl = USDdir/crl.pem # The current CRL private_key = USDdir/ca/new_ca_pk.pem # The private key RANDFILE = USDdir/ca/.rand Private random number file x509_extensions = usr_cert # The extensions to add to the cert > echo 01 > serial > notepad index.txt % echo "01" > serial % touch index.txt openssl req -x509 -new -config X509CA/openssl.cnf -days 365 -out X509CA/ca/new_ca.pem -keyout X509CA/ca/new_ca_pk.pem Using configuration from X509CA /openssl.cnf Generating a 512 bit RSA private key ....++ .++ writing new private key to 'new_ca_pk.pem' Enter PEM pass phrase: Verifying password - 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) []:IE State or Province Name (full name) []:Co. Dublin Locality Name (eg, city) []:Dublin Organization Name (eg, company) []:Red Hat Organizational Unit Name (eg, section) []:Finance Common Name (eg, YOUR name) []:Gordon Brown Email Address []:gbrown@redhat.com > set PATH= JAVA_HOME \bin;%PATH% % PATH= JAVA_HOME /bin:USDPATH; export PATH keytool -genkey -dname "CN=Alice, OU=Engineering, O=Progress, ST=Co. Dublin, C=IE" -validity 365 -alias CertAlias -keypass CertPassword -keystore CertName .jks -storepass CertPassword keytool -certreq -alias CertAlias -file CertName _csr.pem -keypass CertPassword -keystore CertName .jks -storepass CertPassword openssl ca -config X509CA /openssl.cnf -days 365 -in CertName _csr.pem -out CertName .pem openssl x509 -in CertName .pem -out CertName .pem -outform PEM copy CertName .pem + X509CA \ca\new_ca.pem CertName .chain cat CertName .pem X509CA /ca/new_ca.pem> CertName .chain keytool -import -file CertName .chain -keypass CertPassword -keystore CertName .jks -storepass CertPassword > set PATH= OpenSSLDir \bin;%PATH% % PATH= OpenSSLDir /bin:USDPATH; export PATH openssl Configuration File [req] req_extensions=v3_req openssl Configuration File [v3_req] subjectAltName=DNS:www.redhat.com,DNS:jboss.org openssl Configuration File [CA_default] copy_extensions=copy openssl req -new -config X509CA /openssl.cnf -days 365 -out X509CA /certs/ CertName _csr.pem -keyout X509CA /certs/ CertName _pk.pem Using configuration from X509CA /openssl.cnf Generating a 512 bit RSA private key .++ .++ writing new private key to ' X509CA /certs/ CertName _pk.pem' Enter PEM pass phrase: Verifying password - 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) []:IE State or Province Name (full name) []:Co. Dublin Locality Name (eg, city) []:Dublin Organization Name (eg, company) []:Red Hat Organizational Unit Name (eg, section) []:Systems Common Name (eg, YOUR name) []:Artix Email Address []:info@redhat.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:password An optional company name []:Red Hat openssl ca -config X509CA /openssl.cnf -days 365 -in X509CA /certs/ CertName _csr.pem -out X509CA /certs/ CertName .pem Using configuration from X509CA /openssl.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'IE' stateOrProvinceName :PRINTABLE:'Co. Dublin' localityName :PRINTABLE:'Dublin' organizationName :PRINTABLE:'Red Hat' organizationalUnitName:PRINTABLE:'Systems' commonName :PRINTABLE:'Bank Server Certificate' emailAddress :IA5STRING:' info@redhat.com ' Certificate is to be certified until May 24 13:06:57 2000 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated copy X509CA \ca\new_ca.pem + X509CA \certspass:quotes[_CertName_].pem + X509CA \certspass:quotes[_CertName_]_pk.pem X509CA \certspass:quotes[_CertName_]_list.pem cat X509CA /ca/new_ca.pem X509CA /certs/ CertName .pem X509CA /certs/ CertName _pk.pem > X509CA /certs/ CertName _list.pem openssl pkcs12 -export -in X509CA /certs/ CertName _list.pem -out X509CA /certs/ CertName .p12 -name "New cert"