SUMMARY
Create, sign and apply certificates on a Unitrends systems' user interface
RESOLUTION
Use an SSH client such as PuTTY to access the Unitrends system at the command line level. Note: Ensure you have the OS password to access the Unitrends system’s command line. The OS password may differ from the password used to access the User Interface.
Creating an RSA Key and a Certificate Signing Request
- The creation of a new RSA key may or may not be necessary depending on whether the user wishes to generate a new key because they want a new key or they desire a more secure key (i.e. more bits). Since Unitrends shipped with a 1024 bit private key and this key has been proven to be not as secure, this example will start with the creation of a new 2048 bit private key. To create the RSA key, from the command line, via putty, run the following series of commands: ***If you receive errors related to an unknown option, try typing the command out opposed to copying and pasting***
# mkdir /tmp/keys # cd /tmp/keys # openssl req -newkey rsa:2048 -nodes -keyout <hostname>.key -out <hostname>.csr
This will create a key named <hostname>.key and a certificate signing request named <hostname>.csr in the /tmp/keys directory. - If the existing private key is to be used, one simply generates the certificate signing request (CSR) with the following command:
openssl req -new -sha256 -key /etc/pki/tls/private/localhost.key -out <hostname>.csr
During the generation of the CSR using either Step 1 or 2, a series of questions will be posed.
Answer them logically. For example, replacing “MyCountry” with US, GB, FR, DE, etc.
On some questions, the default answer is blank; however, most CA servers will require the hostname of the appliance be accurately entered when that question is presented (though the default answer is blank). If there is no “hostname” available, enter the IP address of the system as the Common Name (CN).
# openssl req -newkey rsa:2048 –sha256 -nodes -keyout <hostname>.key -out <hostname>.csr Generating a 2048 bit RSA private key .+++ ......+++ writing new private key to '<hostname>.key' ----- 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) [GB]:MyCountry State or Province Name (full name) [Berkshire]:MyState Locality Name (eg, city) [Newbury]:MyCity Organization Name (eg, company) [My Company Ltd]:MyCompany Organizational Unit Name (eg, section) []: MyOrgUnit Common Name (eg, your name or your server's hostname) []:<hostname> OR <*.MyDomain.com (if wildcard)> Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Creating a Certificate Signing Request (.csr) containing multiple <hostname> entries
Since many systems may have several hostname and/or IP addresses assigned to various interfaces on different subnets, it is sometimes desirable that the certificate reflect the various names and addresses by which this host is known. The signing request requires the specification of a Version 3 extension (subjectjAltName field) that explicitly names the host names and IP addresses that should be incorporated into the signed certificate.
But first, the V3 request extensions must be enabled in the /etc/pki/tls/openssl.cnf file.
- Edit the /etc/pki/tls/openssl.cnf and locate the following line:
# req_extensions = v3_req # extensions to add to a certificate request
and remove the leading #.
Next locate the [ v3_req ] section and add the subjectAltName line.
[ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_name [ alt_name ] DNS.1=localhost DNS.2=MyHostname1 DNS.3=MyHostname1.Mydomain.com DNS.4=*.Mydomain.com IP.1=127.0.0.1 IP.2=10.10.10.1 IP.3=x.x.x.x
- And finally, the openssl req command needs to specify the additional extension section to include via the –reqexts parameter. The tag, “v3_req” matches the [v3_req] section in the openssl.cnf file that was modified in the earlier step to include the subjectAltName parameter.
# openssl req -newkey rsa:2048 –sha256 -nodes -keyout <hostname>.key -out <hostname>.csr –reqexts v3_req
- After answering the questions as explained in the prior section, you may check the data in the certificate request with the following command. If the previous steps were performed correctly, there should be an “X509v3 Subject Alternative Name” section followed by the list of aliases.
# openssl req –text –noout –in <hostname>.csr
The output should look like this:
Certificate Request: Data: Version: 0 (0x0) Subject: C=MyCountry, ST=MyState, L=MyCity, O=MyCompany, OU=MyOrgUnit, CN=<hostname>/emailAddress=me@myemail.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: <2048 bit Key Dump delete> Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Subject Alternative Name: DNS:hostname1.domain, DNS:hostname2.domain, IP Address:1.1.1.1, IP Address:10.10.10.10 Signature Algorithm: sha256WithRSAEncryption <SHA256 Signature deleted>
Request Certificate from CA Server
----- The following instructions may vary depending on how the user’s specific certificate authority worksIt is also assumed that the Certificate Authorities Trusted Root Certificates are installed on the clients that
will be accessing the DPU ----
You may be fortunate enough to be able to upload the entire <hostname>.csr file to your certificate authority. However, if not, the user may be required to extract the “BEGIN…END” portions and submit this to the CA as per the following commands:
- Run vi <hostname>.csr
- Highlight the text on the screen, including the Begin Certificate Request and End Certificate Request lines. This will copy the text from the putty window.
- Open a browser window.
- Enter https://<CA_host>/certsrv in the address bar where <CA_host> is replaced by the hostname of the certificate server.
- A Login window should open. Enter an Enterprise Admin account username and password and hit enter.
- Paste the text of the <hostname>.csr file, including the “BEGIN” and “END” lines into the window.
It is important that the “BEGIN CERTIFICATE REQUEST” and “END CERTIFICATE REQUEST” lines are included in the copied and pasted text.
- Switch the certificate template to web server and select Submit.
Download Certificate and Chain File to Appliance
You will be presented the new certificate and certificate chain file in the browser window.
- Download these files to the PC, placing them in an empty temporary directory.
- Open a Windows command prompt.
- Type cd \ and hit enter
- Type cd program files and hit enter
- Type cd putty and hit enter
- Type pscp c:\<tmp folder>\*.* root@<dpu_hostname>:/tmp/keys
The destination directory for the copy should be the same as that from Step 1.
- Respond yes if asked to update cache key
- Enter DPU root password
The files will be copied to the appliance /tmp/keys directory. cd /tmp/keys
- Return to appliance command line via your putty connection.
- Type:
cd /tmp/keys
---The following step is only necessary if a new key was created in step 1 OR 4.
Ignore if you used Step 2.---
Ignore if you used Step 2.---
cp *.key /etc/pki/tls/certs/
# Convert the .p7b chain file format to a .cer format that Apache can understand
openssl pkcs7 -print_certs -in <chain_file_name>.p7b -out <chain_file_name>.cer
# Copy the certificate and chain files
cp *.cer /etc/pki/tls/certs/ (or cp *.crt /etc/pki/tls/certs/)
# Save the existing ssl.conf file
cp /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.orig
- Edit /etc/httpd/conf.d/ssl.conf
vi /etc/httpd/conf.d/ssl.conf
In the file, search for and edit the following lines:
Change “SSLCertificateFile /etc/pki/tls/certs/localhost.crt” to read:
SSLCertificateFile /etc/pki/tls/certs/<name of new certificate file> (.crt or .cer extension)
This step is optional if Step 3a (use existing key) was used.
Change “SSLCertificateKeyFile /etc/pki/tls/private/localhost.key” to read:
SSLCertificateKeyFile /etc/pki/tls/certs/<name of new key file> (.key – generated in Step 1 or 4)
Change “SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt” to read:
SSLCertificateChainFile /etc/pki/tls/certs/<chain_file_name> (.cer extension)
- Hit ESC and type :wq and hit enter to write and quit
- cd /etc/pki/tls/certs/ and move any localhost.orig and/or localhost.old file to /root. You should see localhost.crt and localhost.key. The rest should be moved to /root.
- Test the changes with the following command:
apachectl configtest (look for a message “Syntax OK”)
- Restart the apache daemon using the following command:
apachectl restart
Note: A good discussion of SSL/TLS certificate file types can be found here:
http://blogs.msdn.com/b/kaushal/archive/2010/11/05/ssl-certificates.asp