This site requires JavaScript to be enabled
Welcome Guest|
Recent searches
IE BUMPER
KB0018090

Requesting and Installing an SSL Certificate on a Linux Host

Number of views : 11
Article Number : KB0018090
Published on : 2020-06-05
Last modified : 2020-06-05 21:53:37
Knowledge Base : ESM External

Requesting and Installing an SSL Certificate on a Linux Host

 

You may use the following set of procedures to request and install an SSL certificate for use with either Apache or other applications that can utilize SSL certificates saved as files on a Linux host.  SSL certificate installations are unique to the applications that use them as such please amend these instructions accordingly.

 

Creating the Certificate Signing Request (CSR)

 

The following script can be used to generate an SSL Certificate Signing Request (text in red should be replaced with appropriate values):

#!/bin/sh

 

# To Run: "generate-csr.sh <FQDN> [<OpenSSL Config>]"

# Example 1: "generate-csr.sh servername.austin.utexas.edu"

# Example 2: "generate-csr.sh servername.austin.utexas.edu openssl_san.cnf"

 

# To view the contents of the CSR: "openssl req -text -noout -in <CSR file>"

 

if [ $# -eq 0 ] || [ $# -gt 2 ]; then

  echo "Invalid number of arguments"

  exit 1

fi

 

if [ $# -eq 1 ]; then

  openssl req -newkey rsa:2048 -sha512 -nodes \

    -subj "/C=US/ST=Texas/L=Austin/O=The University of Texas at Austin/OU=UT Austin/CN=$1/emailAddress=distribution_list_of_service_owners" \

    -keyout $1.key \

    -out $1.csr

else

  openssl req -newkey rsa:2048 -sha512 -nodes \

    -keyout $1.key \

    -out $1.csr \

    -config $2

fi

 

When specifying a single parameter (as in Example 1), it must be the FQDN of the server that will receive the SSL certificate. The script will generate a key and CSR using the following default settings (replace the email address with a group address of service owners/admins):

 

Country = US

State = Texas

Locality = Austin

Organization = The University of Texas at Austin

Organizational Unit = UT Austin

Common Name = FQDN

Email Address = Group Email Address

 

When specifying two parameters, the first must be the FQDN of the server that will receive the SSL certificate and the second is an SSL configuration file (openssl_san.cnf). The configuration file can be used to provide different settings from the above defaults or if you want to specify Subject Alternative Names.

 

An example configuration file is given below. In this example, there are two Subject Alternative Names specified by the subjectAltName variable. These need to be changed based on what SANs you want. You will also need to change the CN to be the FQDN of the server receiving the SSL certificate and emailAddress to the service owner's group email address if available.

 

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
 
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS: FQDN1, DNS: FQDN2
 
[ req_distinguished_name ]
C               = US
ST              = Texas
L               = Austin
O               = The University of Texas at Austin
OU              = UT Austin
CN              = server FQDN
emailAddress    = Group Email Address

 

It is a good idea to verify the contents of your CSR (including any SANs desired) before submitting it by using the following command:

 

openssl req -text -noout -in <CSR file>

 

 

  

Submitting the Certificate Signing Request (CSR)

 

ITS Managed DNS Domains

For ITS managed DNS domains (its.utexas.edu, austin.utexas.edu, and a few special cases) requests for certificates can be made directly in ServiceNow.

    1. Create a CSR using the steps above.

 

  1. Place the CSR file with the following information in an email:
    • The requested duration of the certificate (options are 1 or 2 years).
    • The server type (Apache, F5, IIS, Tomcat, etc.) of the system that will use the certificate.
    • A contact email address for the certificate (i.e. the group email/distribution list used above when creating the CSR). Using an individual for the contact email is insufficient.
    • Any Subject Alternative Names (SANs) that are desired OR the presence of SANs in the CSR file.
  2. Place the CSR file with the following information in an email: Send the email to cert-requests@austin.utexas.edu.
  3. Wait approximately 1-2 business days for the certificate handlers to respond with the requested certificates.

 

Externally Managed DNS Domains

For externally managed DNS domains (engr.utexas.edu, iq.utexas.edu, etc) requests for certificates must be made through the managers of the certificate’s DNS domain:

 

  1. Create a CSR using the steps above.
  2. Place the CSR file with the following information in an email:
    • The requested duration of the certificate (options are 1 or 2 years).
    • The server type (Apache, F5, IIS, Tomcat, etc.) of the system that will use the certificate.
    • A contact email address for the certificate (i.e. the group email/distribution list used above when creating the CSR). Using an individual for the contact email is insufficient.
    • Any Subject Alternative Names (SANs) that are desired OR the presence of SANs in the CSR file.
  3. Send the email to the managers of the DNS domain. If the managers are not known, send the email to security@utexas.edu and ask the UT ISO to direct you to the domain’s managers.

 

Notes

  • When you receive the email providing you with links to download your certificate, there will be several formats available for download. You will need to download the correct version of your certificate depending on the application that will use it; See application documentation for your specific requirements. The first certificate listed in the email (labelled “Format(s) most suitable for your server software”) will generally be what you need.
  • Requests for certificates that are not using a *.utexas.edu domain name may incur a delay of up to 5 business days. This is due to a lengthy registration process handled by Comodo on behalf of the InCommon Federation.
  • The root and intermediate certificates for the InCommon-issued certificates may need to be imported or trusted by the server software. The e-mail confirmation message from InCommon provides download links for the appropriate root and intermediate certs for the certificate in question.

 

 

 

 

 

Verifying and Installing the Certificate

 

 

Once the new certificate is issued, it is a good idea to verify it to ensure that you have what you need before installing it on your server. You can do this using the following commands:

 

Certificate

Verify your completed certificate has the requested SANs (if any) with:

openssl x509 -text -noout -in <Cert file>

 

Key

Verify your Key and Certificate correspond to each other by running both of the following commands (the outputs should be the same):

openssl x509 -noout -modulus -in <Cert file> | openssl md5
openssl rsa -noout -modulus -in <Key file> | openssl md5

 

 

 

When you are satisfied with your certificate, follow the steps below to install it:

  1. Place the certificate and key files on the server in their default locations (usually /etc/pki/tls/certs and /etc/pki/tls/private respectively) or follow any provided documentation if they need to be placed in a non-default location.
  2. Ensure that the certificate and key are owned by root:root and that the certificate’s permissions are set to 644 and the key’s permissions are set to 400.
  3. For consistency and as a best practice, name the certificate and key using the first 2 parts of the FQDN of the server. For example, if the server is named portfolio.austin.utexas.edu, the first two parts are portfolio and austin. In general, use the following naming convention:

    Certificate for a Single URL

    <hostname>.[its | austin | utexas].<request year>.[crt | key]

      

    Certificate with Subject Alternate Names (SAN) or Extended Validation (EV)

    <hostname>.[its | austin | utexas].<request year>.[san | ev].[crt | key]

      

    Intermediate Certificate

    <hostname>.[its | austin | utexas].<request year>.interm.crt

      

    Key

    <hostname>.[its | austin | utexas].<request year>.key

     

    For example, a certificate/key pair for portfolio.austin.utexas.edu requested in 2020 would be named portfolio.austin.2020.crt and portfolio.austin.2020.key respectively.

  4. Create softlinks to the desired certificate/key. Use the softlinks in the Apache (or other application) configuration file(s). The softlinks will allow you to easily change out future certificates/keys without having to modify any configuration files in your applications. Use the following naming convention as a best practice:

    Certificate Softlink

    <hostname>.[its | austin | utexas].crt

      

    Intermediate Certificate Softlink

    <hostname>.[its | austin | utexas].interm.crt

      

    Key Softlink

    <hostname>.[its | austin | utexas].key

     

  5. Restart the Apache service (or other application) to begin using the new certificate. NOTE: This will take your service offline momentarily.

 

 

 

Updating a Certificate

 

If the above steps have been followed to initially set up the certificate, when it comes time to update the certificate, just follow the steps above again to request the new certificate, then repoint the Softlink to the new files and restart the Apache service (or other application using the certificate). NOTE: This will take your service offline momentarily.

 

For example, if installing an SSL certificate for Apache on a RHEL 6 host:

ln -f -s [new cert/key file] [cert/key Softlink name]

service httpd restart

 

Thank You! Your feedback has been submitted.

Feedback