How to import a VeriSign Certificate into SUSE Enterprise Server 9 not running eDirectory

(Last modified: 01Feb2005)

This document (10096437) is provided subject to the disclaimer at the end of this document.

goal

fact

VeriSign Certificate

OpenSSL - mod_ssl

SUSE LINUX Enterprise Server 9

fix

These steps document how to import a production VeriSign external certificate into SLES 9 not running eDirectory to enable SSL on Apache services. If this server is running eDirectory please see How to import a Production VeriSign External Certificate into eDirectory 8.7.3 . These steps below are based on the mod_ssl implementation of Linux.

Overview:
1. First a keypair, public and private key, must be created as well as the CSR. Then the passphrase will be removed from the private key. The CSR (Certificate Signing Request) must be created with the appropriate key information. We will then send VeriSign this newly created CSR which they will sign and send back to us. It is actually our public key which they will append to. This will be our Signed Certificate.

2. Remove the passphrase from the private key and submit the CSR.

3. To complete the certificate, the signed certificate received from VeriSign must be saved into the public key.

4. Services need to be configured to use the new certificates.

Together these items create the certificate with the proper certificate chain and allow for services to use the certificate for SSL enabled communications.

Steps:

A.   Creating the CSR and private key files.
1. Open a terminal window and create the directory that will contain the completed certificates.
For our example we will create a directory called /etc/ssl/cert then make this directory only viewable by root: chmod 777 directoryname

2. Now run the command to create the public\private keys and CSR:  openssl req -new -out server.csr

NOTE: You will be prompted for the subject name, city, state, organization and organizational unit for this certificate. This part is VERY IMPORTANT! These settings are permanent. The most important of these is subject name. It should reflect the name or URL that will be used to access this server. If your community will access secure services on this server using the URL www .domain.com then that will be the "cn" part of the subject name. The organzational unit and organization can be anything you like and are not tied to any eDirectory contexts. In our example the complete identifier will be cn=www. testnovell.com.ou=finance1.o=headquarters.L=provo.S=utah.C=us

For Verisign you will need to make sure and include the L, S and C (Location, State, Country) or else you will get an error requesting the certificate in a later step.   VeriSign will drop the OU as they do not support this in the subject name.  The critical part is the cn=_____. As stated earlier, it must match the name that will be used to access the service that will be using the certificate. If the names do not match, you will always get a Security Alert warning each time the certificate is accessed. See TID 10081133 - What causes the security alert when using https and Internet Explorer?

3. Lastly, remove the passphrase from the private key so we do not have to type it in everytime Apache starts: openssl rsa -in privkey.pem -out server.key
We now have three files: privkey.pem (private key with passphrase), server.csr (our CSR file to be given to VeriSign) and server.key (private key with passphrase removed).

B. Submit the CSR
1. On Verisign's website navagate to where you are prompted to paste the CSR.

2. Open the server.csr file into vi and copy into memory. Make sure to include both the beginning and ending lines as well as all dashes ensuring there are no preceding nor trailing spaces. (Whatever edit is used it should be one that does not include any hidden lines or control characters.)

3. Paste the result into the CSR dialog. Since in this example we are installing the certificate for Apache we will select this as our application and web server as type of server. Then submit the information.

C. Copy the Signed Certificate into the directory previously created

Once you have received your email from VeriSign containing the Signed Certificate you are ready to save this information into the public certificte file created during the CSR creation (Step A above). Simply save all lines of the returned signed certificate in the email ,including the begin and add sections and all dashes, to /etc/ssl/crt/public.crt. Once done copy the private key, server.key to /etc/ssl/crt/private.key. You may now delete privkey.pem and server.csr.

If you are instructed to also install an Intermediate Authority you will need to copy this from the Verisign site to /etc/ssl/crt/intermedate.crt.

D. Enabling the application to use the new certificate

Which Apache conf file to modify and its location can depend on the version installed as well as what vendor installed it. Normally this file is httpd.conf.

In the example below Apache was installed via Novell's Open Enterprise Server.

Edit the /etc/apache2/vhosts.d/vhost-ssl.conf file.

In the Virtual Hosts section modify the following lines to reflect the name and path of the server's private and public (and intermediate if applicable) keys:

SSLCertificateFile /etc/ssl/crt/public.crt
SSLCertificateKeyFile /etc/ssl/crt/private.key

Also the following if using an intermediate:

SSLCertificateChainFile /etc/ssl/crt/intermediate.crt

For the httpd.conf

In the Virtual Hosts section add the following lines:

SSLCertificateFile /etc/ssl/crt/public.crt
SSLCertificateKeyFile /etc/ssl/crt/private.key

Also the following if using an intermediate:

SSLCertificateChainFile /etc/ssl/crt/intermediate.crt

D. Restarting the enabled services

Once the conf files have been modified Apache services need to be restarted: /etc/init.d/apache2 restart

document

Document Title:	How to import a VeriSign Certificate into SUSE Enterprise Server 9 not running eDirectory
Document ID:	10096437
Solution ID:	NOVL100814
Creation Date:	31Jan2005
Modified Date:	01Feb2005
Novell Product Class:	novell directory services

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.