Generating a Certificate - SSL/TLS

  • 7019523
  • 25-May-2017
  • 18-Jul-2018


GWAVA 4 / 5 / 6
Secure Messaging Gateway


How do I generate a Certificate Signing Request (CSR) and Private Key


Before the GWAVA agents can use SSL, you must create a Certificate Signing Request (CSR) and obtain a public certificate file. The CSR includes the hostname of the server where the agents run. Therefore, you must create a CSR for every server where you want the GWAVA agents to use SSL. However, the GWAVA agents running on the same server can all share the same resulting certificate, so you do not need separate CSRs for different agents. The CSR also includes your choice of name and password for the private key file that must be used with each certificate. This information is needed when configuring the agents to use SSL.

1. Generate a Private Key and CSR file. 

GWAVA requires a private key to enable SSL or TLS. This key can be created manually from a command prompt on the server, or you can use Exchange, or other utilities to create these files. To create your own key manually follow the instructions at the end of this article: Creating Your Own Certificates using OpenSSL. 

TIP: If you already have configured GroupWise to use SSL on this server, you may use the same key and certificate files for GWAVA as well.

Generate a Private Key and CSR File (Older Versions of GroupWise)

One way to create a CSR is to use the GWCSRGEN utility. This utility takes the information you provide and creates a .csr file from which a public certificate file can be generated.

NOTE: The GroupWise documentation at provides even more detailed information, including how to create multiple CSRs at once

Start the GroupWise Generate CSR utility. On Linux, gwcsrgen is installed by default to the /opt/novell/groupwise/agents/bin directory. You must be logged in as root to start the utility. On Windows, the utility is located in the <SDD>\admin\utility\gwcsrgen directory where you installed the SDD (Software Distribution Directory) or on the GroupWise CD.

  • Fill in the Private Key and Certificate Signing Request information. (The filenames can vary, but we'll use these filenames in the rest of this page). Specify the password for the private key. The password can be up to 256 characters. Do not forget this password. Store it safely somewhere.
  • Fill in the fields in the Required Information box. You must fill in all fields to generate a valid CSR file. For the Country field, use the ISO two-letter abbreviation for your country (example: US). Do not abbreviate the name of your state or province. The name of your Organization should match your organizational name. Division is fairly arbitrary, but needs to be filled in. Under Hostname of Server, specify the DNS hostname of the server where the server certificate will be used (for example, It is because of this last parameter that unique certificates must be minted per server.

NOTE: You can specify an IP Address instead of Hostname, but this is not recommended, as the certificate will generate errors if the IP address ever changes, if someone accesses the server via its friendly DNS name or the public and private ip addresses vary.

  • Now click Create to generate the CSR file and Private Key file.The CSR and Private Key files are created with the names you specified as the CSR filename and KEY filename, in the same directory as the gwcsrgen utility.
  • Finally, create a subdirectory off the GWAVA product root called certs. For example, on Linux, you'd create /opt/beginfinite/gwava/certs. Move the mykey.key and myreq.csr files to this directory. (The certificate files can be anywhere, but tucking them under the GWAVA product root will make them easy to find, and easy to share in a cluster).

2. Creating a Certificate from a Certificate Signing Request (CSR)

To obtain a server certificate, you can submit the Certificate Signing Request (myreq.csr file) to a Certificate Authority (CA). You may either use a public Certificate Authority, or mint the certificate yourself using your own Certificate Authority (see below). There are advantages and disadvantages to both approaches

On the one hand, minting a certificate yourself with your own CA costs no money, and allows you to maintain certificates yourself. There are limitations, however, in using self-signed certifcates. Some of these limitations include: 

1. These self-signed certificates may not not be trusted, and may not be able to authenticate. 

2. Life-time of the certifcates are usually only 1 year. 

3. Self-signed certificates use a lower security cipher, and may not fulfill the requirements of the companies Security policies. 

4. No support for advanced PKI (Public Key Infrastructure) functions.

For security it is best to use a public Certificate Authority, especially for the QMS, which is often accessed by end-users. The web browser the user uses checks to see if the SSL certificate was signed by a "well-known" public Certificate Authority such as Verisign or Thawte. (This list of well-known CAs is embedded in the browser by the browser manufacturer.) If it was signed by a well-known CA, the user is allowed to make the SSL connection without complaint.

If you use your organizational CA to sign the certificate, every connection will be preceded by a warning that the certificate may be invalid and ask for the end user t accept or reject the certificate. This can frighten end-users and lead to unnecessary calls. This can be avoided if your end user imports your CA as trusted authority into their web browser, but that's not always feasible.

The process of submitting the CSR to a public CA varies from company to company. Most provide online submission of the request. Please follow their instructions for submitting the request.

Exporting Private Key from CRT File

If the CSR file was created, especially on Exchange, but the .key (or .pem) file is did not get created, you will need to export that from the .pfx file that was downloaded from Micrsoft Exchange. To do that, go into a command prompt, and type in: 

openssl pkcs12 -in filename.pfx -nocerts -out gwava.key

Note: The GWAVA Appliance already contains openSSL. If running on another server, be sure to install openSSL. 

It will prompt to create a passphrase, which you will need to remember when using for GWAVA. 

Copy the .key file to the /opt/beginfinite/gwava/certs directory,. 

Creating Your Certificate using ConsoleOne

To quickly create your own public certificate in ConsoleOne, and sign it with your organizational CA, follow these instructions.

Click Help > About Snap-ins to see if the Certificate Server snap-in to ConsoleOne is installed.If it is not installed, you can obtain it from Novell Product Downloads. If you are using eDirectory on Linux, the Certificate Server snap-in is installed by default.

NOTE: You can create a server certificate in Novell iManager, as well as in ConsoleOne, using steps similar to those provided

Browse to and select the container where your Server object is located.

Click Tools > Issue Certificate

Browse to and select the CSR (myreq.csr) file created by GWCSRGEN (in /opt/beginfinite/certs), and click Next.

Allow your Organization CA to sign the certificate, and click Next again.

Select Custom, and make sure all 3 checkboxes are selected as shown above.

Set the validity period above according to your organization needs. When the certificate expires, it will need to be reissued.

Click Next, view the summary information, Finish

Make sure you save the file in Base64 format. We recommend you save the certificate as mycert.crt in /opt/beginfinite/gwava/certs

Creating Your Own Certificates using OpenSSL

These instructions assume you already have OpenSSL installed on your system.

From a command line,

  1. Type cat /dev/random > /tmp/random
  2. Now type random characters for a bit. Then hit CTRL-C.
  3. Type openssl genrsa -des3 -out /tmp/mykey.key -rand /tmp/random 1024. You'll be asked for a password. Don't lose it
  4. Type openssl req -new -x509 -days 365 -key /tmp/mykey.key -out /tmp/mycert.crt. You'll be asked to input information like your Common Name (should be the hostname of this server, eg, your country (two character ISO code), (the "-days" option can be set to a desired value) etc. See the GWCSRGEN section above for hints.
  5. Create a certs directory off your product route (mkdir /opt/beginfinite/gwava/certs), and move the files to this directory (mv /tmp/mycert.crt /opt/beginfinite/gwava/certs,mv /tmp/mykey.key /opt/beginfinite/gwava/certs)

Configuring GWAVAMAN and QMS to use SSL

Once you have your KEY and CERTIFICATE files in /opt/beginfinite/gwava/certs, configuring GWAVA to use these files is simple.

Additional Information

This article was originally published in the GWAVA knowledgebase as article ID 476.