Novell GROUPWISE 8 Security Administration

XVI

Security Administration

 Chapter 74, “GroupWise Passwords,” on page 1151

 Chapter 75, “Encryption and Certificates,” on page 1159

 Chapter 76, “LDAP Directories,” on page 1169

 Chapter 77, “Message Security,” on page 1173

 Chapter 78, “Address Book Security,” on page 1175

 Chapter 79, “GroupWise Administrator Rights,” on page 1177

 Chapter 80, “GroupWise Agent Rights,” on page 1191

 Chapter 81, “GroupWise User Rights,” on page 1193

 Chapter 82, “Spam Protection,” on page 1199

 Chapter 83, “Virus Protection,” on page 1201

See also Part XVII, “Security Policies,” on page 1203.

novdocx (en) 22 June 2009

XVI

Security Administration

1149

novdocx (en) 22 June 2009

1150 GroupWise 8 Administration Guide

74

GroupWise Passwords

novdocx (en) 22 June 2009

74

Access to GroupWise® mailboxes is protected by post office security settings or GroupWise
passwords. Agent passwords grant access to remote servers and to Novell
protect access to GroupWise agent status information.

 Section 74.1, “Mailbox Passwords,” on page 1151

 Section 74.2, “Agent Passwords,” on page 1155

See also Part XVII, “Security Policies,” on page 1203.

®

eDirectoryTM, and

74.1 Mailbox Passwords

When you are setting up a new GroupWise system, you need to determine what kind of password
protection you want to have on users’ GroupWise mailboxes before users start running GroupWise.
In ConsoleOne
GroupWise and you can set defaults under Client Options to enforce your choices. You and
GroupWise client users should keep in mind that GroupWise passwords are case sensitive.

 Section 74.1.1, “Using Post Office Security Instead of GroupWise Passwords,” on page 1151

 Section 74.1.2, “Requiring GroupWise Passwords,” on page 1152

 Section 74.1.3, “Managing GroupWise Passwords,” on page 1152

 Section 74.1.4, “Using LDAP Passwords Instead of GroupWise Passwords,” on page 1154

 Section 74.1.5, “Bypassing Mailbox Passwords to Respond to Corporate Mandates,” on

page 1155

®

, you can choose where password information is obtained when users log in to

74.1.1 Using Post Office Security Instead of GroupWise Passwords

When you create a new post office, you must select a security level for it.

If you select Low Security for the post office, users are not required to set passwords on their
GroupWise mailboxes. However, passwordless mailboxes are completely unprotected from other
users who know how to use the @u-user_ID startup switch.

If you select High Security for the post office, users are still not required to set passwords on their
GroupWise mailboxes, but they are required to be successfully logged in to a network before they
can access their own passwordless mailboxes. Users cannot access other users’ passwordless
mailboxes.

After you select High Security, you can further enhance post office security by requiring specific
types of authentication before users can access their passwordless GroupWise mailboxes. You can
require eDirectory authentication so that users must be logged in to eDirectory before they can
access their passwordless GroupWise mailboxes.

GroupWise Passwords

1151

In spite of these passwordless solutions to GroupWise mailbox security, users are always free to set
their own GroupWise passwords on their mailboxes. When they do, the post office security settings
no longer apply (except for LDAP authentication as discussed below) and users are regularly faced
with both logins unless some additional password options are selected for them, as described in the
following sections.

74.1.2 Requiring GroupWise Passwords

Users are required to set passwords on their GroupWise mailboxes if they want to access their
GroupWise mailboxes in any of the following ways:

 Using Caching mode or Remote mode in the GroupWise Windows client

 Using Caching mode in the GroupWise Linux/Mac client

 Using their Web browsers and the GroupWise WebAccess client

 Using an IMAP e-mail client

 Accessing a GroupWise mailbox as an external entity rather than as an eDirectory user

novdocx (en) 22 June 2009

74.1.3 Managing GroupWise Passwords

When GroupWise passwords are in use in addition to network passwords, there are a variety of
things you can do to make GroupWise password management easier for you and to make the
additional GroupWise password essentially transparent for your GroupWise users.

 “Establishing a Default GroupWise Password for New Accounts” on page 1152

 “Accepting eDirectory Authentication Instead of GroupWise Passwords” on page 1153

 “Using Novell SecureLogin to Handle GroupWise Passwords” on page 1153

 “Allowing Windows to Cache GroupWise Passwords” on page 1153

 “Using Intruder Detection” on page 1153

 “Resetting GroupWise Passwords” on page 1154

 “Synchronizing GroupWise Passwords and LDAP Passwords” on page 1154

NOTE: A GroupWise password can contain as many as 64 characters and can contain any typeable
characters.

Establishing a Default GroupWise Password for New Accounts

If you want to require users to have GroupWise passwords on their mailboxes, you can establish the
initial passwords when you create the GroupWise accounts. In ConsoleOne, you can establish a
default mailbox password to use automatically on all new GroupWise accounts, as described in

Section 13.1, “Establishing a Default Password for All New GroupWise Accounts,” on page 213. Or

you can set the password on each new GroupWise account as you create it.

Keep in mind that some situations require users to have passwords on their GroupWise mailboxes,
as listed in Section 74.1.2, “Requiring GroupWise Passwords,” on page 1152.

1152 GroupWise 8 Administration Guide

Accepting eDirectory Authentication Instead of GroupWise Passwords

When you create users in eDirectory, you typically assign them network passwords, which users
must provide when they log in to the network. If you want to make it easy for client users to access
their GroupWise mailbox, you can select Allow eDirectory Authentication Instead of Password
(ConsoleOne > Tools > GroupWise Utilities > Client Options > Security > Password). This allows
GroupWise users to select No Password Required with eDirectory (Windows client > Tool s >
Options > Security > Password).

NOTE: This option is not available in the Linux/Mac client or the WebAccess client.

As long as users who select this option are logged into eDirectory as part of their network login, they
are not prompted by GroupWise for a password when they access their GroupWise mailboxes. If
they are not logged in to eDirectory, they must provide their GroupWise passwords in order to
access their GroupWise mailboxes.

Using Novell SecureLogin to Handle GroupWise Passwords

If users have Novell SecureLogin installed on their workstations, you can select Enable single sign­on (ConsoleOne > Tools > GroupWise Utilities > Client Options > Security > Password). This
allows GroupWise users to select Use Single Sign-On (Windows client > Tools > Options > Security
> Password). Users need to provide their GroupWise mailbox password only once and thereafter

SecureLogin provides it for them as long as they are logged in to eDirectory.

novdocx (en) 22 June 2009

NOTE: This option is not available in the Linux/Mac client or the WebAccess client.

Allowing Windows to Cache GroupWise Passwords

If you want to allow password information to be stored on Windows workstations, you can select

Allow password caching (ConsoleOne > Tools > GroupWise Utilities > Client Options > Security >
Password). This allows GroupWise users to select Remember My Password (Windows client > To ol s
> Options > Security > Password). Users need to provide their GroupWise mailbox passwords only

once and thereafter Windows provides them automatically.

This option applies only to older GroupWise clients running on older Windows versions, such as
Windows 2000 and earlier, which are not supported for the GroupWise 8 Windows client.

NOTE: This option is not available in the Linux/Mac client or the WebAccess client.

Using Intruder Detection

Intruder detection identifies system break-in attempts in the form of repeated unsuccessful logins. If
someone cannot provide a valid username and password combination within a reasonable time, then
that person probably does not belong in your GroupWise system.

Intruder detection for the GroupWise Windows client and Linux/Mac client is performed by the
POA and is configurable. You can set the number of failed login attempts before lockout, the length
of the lockout, and so on. If a user is locked out, you can re-enable his or her account in ConsoleOne.
See Section 36.3.5, “Enabling Intruder Detection,” on page 519.

GroupWise Passwords 1153

Intruder detection for the GroupWise WebAccess client is built in and is not configurable. After five
failed login attempts, the user is locked out for 10 minutes. If a user is locked out, the user must wait
for the lockout period to end (unless you want to restart the WebAccess Agent).

Resetting GroupWise Passwords

In ConsoleOne, you can remove a user’s password from his or her mailbox if the password has been
forgotten and needs to be reset (User object > Tools > GroupWise Utilities > Client Options >
Security > Password). If necessary, you can remove the passwords from all mailboxes in a post
office (Post Office object > Tools > GroupWise Utilities > Mailbox/Library Maintenance > Reset
Client Options) This resets all or users’ client options settings, not just the passwords.

It is easy for GroupWise users to reset their own passwords (Windows or Linux/Mac client > Tool s >
Options > Security > Password). However, if this method is used when users are in Caching or
Remote mode, this changes the password on the local Caching or Remote mailboxes, but does not
change the password on the Online mailboxes. To change the Online mailbox password while in
Caching or Remote mode, users must use a method they might not be familiar with (Windows client
> Accounts > Account Options > Novell GroupWise Account > Properties > Advanced > Online
Mailbox Password).

novdocx (en) 22 June 2009

It is also easy for WebAccess users to reset their own passwords (WebAccess client > Options >
Password). However, you might not want users to be able to reset their GroupWise passwords from

Web browsers. In ConsoleOne, you can prevent WebAccess client users from resetting their
GroupWise passwords (ConsoleOne > GroupWiseWebAccess object > Properties > Application >
Settings). Windows and Linux/Mac client users cannot be prevented from changing their GroupWise
passwords.

Synchronizing GroupWise Passwords and LDAP Passwords

There is no automatic procedure for synchronizing GroupWise passwords and eDirectory
passwords. However, if you use LDAP authentication, synchronization becomes a moot point
because GroupWise users are authenticated through an LDAP directory (such as eDirectory) rather
than by using GroupWise passwords. See Section 74.1.4, “Using LDAP Passwords Instead of

GroupWise Passwords,” on page 1154.

74.1.4 Using LDAP Passwords Instead of GroupWise Passwords

Instead of using GroupWise passwords, users’ password information can be validated using an
LDAP directory. In order for users to use their LDAP passwords to access their GroupWise
mailboxes, you must define one or more LDAP servers in your GroupWise system and configure the
POA for each post office to perform LDAP authentication, as described in Section 36.3.4,

“Providing LDAP Authentication for GroupWise Users,” on page 514.

When LDAP authentication is enabled, you can control whether users can use the GroupWise client
to change their LDAP passwords (ConsoleOne > Post Office object > Properties > GroupWise >
Security). If you allow them to, GroupWise users can change their passwords through the Security
Options dialog box (Windows and Linux/Mac client > Tools > Options > Security) or on the
Passwords page (GroupWise WebAccess client > Options > Password). If you do not allow them to
change their LDAP passwords in the GroupWise client, users must use a different application in
order to change their LDAP passwords.

1154 GroupWise 8 Administration Guide

You and users can use some of the same methods to bypass LDAP passwords as you can use for
bypassing GroupWise passwords. See “Accepting eDirectory Authentication Instead of GroupWise

Passwords” on page 1153 and “Allowing Windows to Cache GroupWise Passwords” on page 1153.

For more information about LDAP passwords, see Section 76.3, “Authenticating to GroupWise with

Passwords Stored in an LDAP Directory,” on page 1169.

74.1.5 Bypassing Mailbox Passwords to Respond to Corporate Mandates

Sometimes it is necessary to access user mailboxes to meet corporate mandates such as virus
scanning, content filtering, or e-mail auditing that might be required during litigation. These types of
mailbox access are obtain using trusted applications, third-party programs that can log into Post
Office Agents (POAs) in order to access GroupWise mailboxes. For more information about using
trusted application to bypass mailbox passwords, see Section 4.12, “Trusted Applications,” on

page 74

74.2 Agent Passwords

novdocx (en) 22 June 2009

Agent passwords facilitate access to remote servers where domains, post office, and document
storage areas are located and access to eDirectory for synchronization of user information between
GroupWise and eDirectory. They also protect GroupWise Monitor and the agent Web consoles from
unauthorized access.

 Section 74.2.1, “Facilitating Access to Remote Servers,” on page 1155

 Section 74.2.2, “Facilitating Access to eDirectory,” on page 1156

 Section 74.2.3, “Protecting the Agent Web Consoles,” on page 1156

 Section 74.2.4, “Protecting the GroupWise Monitor Web Console,” on page 1157

74.2.1 Facilitating Access to Remote Servers

If the NetWare® POA runs on a server other than where the post office database and directory
structure are located, it needs to log in to that remote server using an existing username and
password. There are several ways to provide this information:

 Fill in the Remote User Name and Remote Password fields on the Post Office Settings page of

the Post Office object in ConsoleOne

 Add the /dn startup switch to the POA startup file to provide the fully distinguished name of the

NetWare POA object

 Add the /user and /password startup switches to the POA startup file to provide a username and

password

The Windows POA also needs username and password information if it needs to access a document
storage area on a server other than the one where the post office database and directory structure are
located. The three methods listed above can be used for this situation as well. The Windows POA
does not need username and password information in order to access the post office directory
because it should already have a drive mapped to that location.

GroupWise Passwords 1155

If the NetWare MTA, Internet Agent, or WebAccess Agent runs on a server other than where the
domain database and directory structure are located, it needs to log in to that remote server using an
existing username and password. All three of these agents support the /user and /password switches
for this purpose. The MTA also supports the /dn switch parallel to the POA. You cannot currently
use ConsoleOne to specify username and password information for these agents.

Providing passwords in clear text in a startup file might seem like a security risk. However, the
servers where the agents run should be kept physically secure. If an unauthorized person did gain
physical access, they would not be doing so for the purpose of obtaining these particular passwords.
And the passwords are encrypted as they pass over the wire between servers, so the security risk is
minimal.

74.2.2 Facilitating Access to eDirectory

If you have enabled eDirectory user synchronization, the MTA must be able to log in to eDirectory
in order to obtain the updated user information. An eDirectory-enabled MTA should be installed on
a server where a local eDirectory replica is located.

If the eDirectory-enabled NetWare MTA is running on a different server from where the domain is
located, you must add the /user and /password switches, or the /dn switch, to the MTA startup file so
that the MTA can authenticate to eDirectory. The /dn switch is preferable, so that username and
password information is not exposed in the MTA startup file. If the NetWare MTA is running on the
same server where the domain is located, the MTA can look up the distinguished name in the
domain database.

novdocx (en) 22 June 2009

For the eDirectory-enabled Windows MTA, you must add the /user and /password switches to the
MTA startup file in order to specify the network user account that the MTA should use to
authenticate to eDirectory.

For more information, see Section 41.4.1, “Using eDirectory User Synchronization,” on page 653.

74.2.3 Protecting the Agent Web Consoles

When you install the POA and the MTA, they are automatically configured with an agent Web
console and no password protection is provided. When you install the Internet Agent and the
WebAccess Agent, you can choose whether to enable the agent Web console during installation. If
you do, you can provide password protection at that time.

If you do not want agent Web console status information available to anyone who knows the agent
network address and port number, you should set passwords on your agent Web console, as
described in the following sections:

 Section 37.2, “Using the POA Web Console,” on page 544

 Section 42.2, “Using the MTA Web Console,” on page 673

 Section 49.2, “Using the Internet Agent Web Console,” on page 805

 Section 56.1.2, “Using the WebAccess Agent Web Console,” on page 949

If you plan to access the agent Web consoles from GroupWise Monitor, it is most convenient if you
use the same password on all agent Web consoles. That way, you can provide the agent Web console
password once in GroupWise Monitor, rather than having to provide various passwords as you view

1156 GroupWise 8 Administration Guide

the Web consoles for various agents. For information about providing the agent Web console
password in GroupWise Monitor, see Section 63.4, “Configuring Polling of Monitored Agents,” on

page 1017.

74.2.4 Protecting the GroupWise Monitor Web Console

Along with the agent Web consoles, you can also provide password protection for the Monitor Web
console itself, from which all the agent Web consoles can be accessed. For instructions, see

Section 63.8, “Configuring Authentication and Intruder Lockout for the Monitor Web Console,” on
page 1023.

novdocx (en) 22 June 2009

GroupWise Passwords 1157

novdocx (en) 22 June 2009

1158 GroupWise 8 Administration Guide

75

Encryption and Certificates

Although GroupWise® native encryption is employed throughout your GroupWise system,
additional security measures should be utilized to secure your GroupWise data.

 Section 75.1, “Personal Digital Certificates, Digital Signatures, and S/MIME Encryption,” on

page 1159

 Section 75.2, “Server Certificates and SSL Encryption,” on page 1161

 Section 75.3, “Trusted Root Certificates and LDAP Authentication,” on page 1167

See also Part XVII, “Security Policies,” on page 1203.

75.1 Personal Digital Certificates, Digital Signatures, and S/MIME Encryption

If desired, you can implement S/MIME encryption for GroupWise client users by installing various
security providers on users’ workstations, including:

novdocx (en) 22 June 2009

75

 Entrust* 4.0 or later (http://www.entrust.com)

 Microsoft Base Cryptographic Provider 1.0 or later (included with Internet Explorer 4.0 or

later)

 Microsoft Enhanced Cryptographic Provider 1.0 or later (http://www.microsoft.com/windows/

ie/downloads/recommended/128bit/default.asp)

 Microsoft Strong Cryptographic Provider (http://www.siliconprairiesc.com/spsckb/EncryptAll/

strong_cryptographic_provider.htm)

 Gemplus GemSAFE Card CSP 1.0 or later (http://www.gemplus.com)

 Schlumberger Cryptographic Provider (http://www.slb.com)

For additional providers, consult the Novell Partner Product Guide (http://www.novell.com/

partnerguide).

These products enable users to digitally sign and/or encrypt their messages using S/MIME
encryption. When a sender digitally signs a message, the recipient is able to verify that the item was
not modified en route and that it originated from the sender specified. When a sender encrypts a
message, the sender ensures that the intended recipient is the only one who can read it. Digitally
signed and/or encrypted messages are protected as they travel across the Internet, whereas native
GroupWise encryption is removed as messages leave your GroupWise system.

After users have installed the S/MIME security providers on their workstations, you can configure
default functionality for it in ConsoleOne
GroupWise Utilities > Client Options > Send > Security > Secure Item Options). You can specify a
URL from which you want users to obtain their S/MIME certificates. You can require the use of
digital signatures and/or encryption, rather than letting users decide when to use them. You can even
select the encryption algorithm and encryption key size if necessary. For more information, see

Section 69.2.2, “Modifying Send Options,” on page 1107.

®

(Domain, Post Office, or User object > Too ls >

Encryption and Certificates

1159

After you have configured S/MIME functionality in ConsoleOne, GroupWise users must select the
security provider (Windows client > Tools > Options > Security > Send Options) and then obtain a
personal digital certificate. Unless you installed Entrust, users can request certificates (Windows
client > Tools > Options > Certificates > Get Certificate). If you provided a URL, users are taken to
the Certificate Authority of your choice. Otherwise, certificates for use with GroupWise can be
obtained from various certificate providers, including:

 Novell, Inc. (if you have installed Novell

®

Certificate ServerTM 2 or later (http://

www.novell.com/products/certserver))

 VeriSign*, Inc. (http://www.verisign.com)

 Thawte* Certification (http://www.thawte.com)

 GlobalSign* (http://www.globalsign.com)

NOTE: Some certificate providers charge a fee for certificates and some do not.

After users have selected the appropriate security provider and obtained a personal digital
certificate, they can protect their messages with S/MIME encryption by digitally signing them
(Windows client > Actions > Sign Digitally) and/or encrypting them (Windows client > Actions >
Encrypt). Buttons are added to the GroupWise toolbar for convenient use on individual messages, or
users can configure GroupWise to always use digital signatures and/or encryption (Windows client
> Tools > Options > Security > Send Options). The messages they send with digital signatures and/
or encryption can be read by recipients using any other S/MIME-enabled e-mail product.

novdocx (en) 22 June 2009

GroupWise Windows client users are responsible for managing their personal digital certificates.
Users can have multiple personal digital certificates. In the GroupWise client, users can view their
own certificates, view the certificates they have received from their contacts, access recipient
certificates from LDAP directories (see Section 76.4, “Accessing S/MIME Certificates in an LDAP

Directory,” on page 1170 for details), change the trust level on certificates, import and export

certificates, and so on.

The certificates are stored in the local certificate store on the user’s workstation. They are not stored
in GroupWise. Therefore, if a user moves to a different workstation, he or she must import the
personal digital certificate into the certificate store on the new workstation, even though the same
GroupWise account is being accessed.

If your system includes smart card readers on users’ workstations, certificates can be retrieved from
this source as well, so that after composing a message, users can sign them by inserting their smart
cards into their card readers. The GroupWise client picks up the digital signature and adds it to the
message.

The GroupWise Windows client verifies the user certificate to ensure that it has not been revoked. It
also verifies the Certificate Authority. If a certificate has expired, the GroupWise user receives a
warning message.

For complete details about using S/MIME encryption in the GroupWise Windows client, see
“Sending S/MIME Secure Messages” in “E-Mail” in the GroupWise 8 Windows Client User Guide.

NOTE: S/MIME encryption is not available in the Linux/Mac client or the WebAccess client.

Any messages that are not digitally signed or encrypted are still protected by native GroupWise
encryption as long as they are within your GroupWise system.

1160 GroupWise 8 Administration Guide

75.2 Server Certificates and SSL Encryption

You should strengthen native GroupWise encryption with Secure Sockets Layer (SSL)
communication between servers where GroupWise agents are installed. If you have not already set
up SSL on your system, you must complete the following tasks:

 Section 75.2.1, “Generating a Certificate Signing Request,” on page 1161

 Section 75.2.2, “Using a GWCSRGEN Configuration File,” on page 1163

 Section 75.2.3, “Submitting the Certificate Signing Request to a Certificate Authority,” on

page 1163

 Section 75.2.4, “Creating Your Own Certificate,” on page 1163

 Section 75.2.5, “Installing the Certificate on the Server,” on page 1166

 Section 75.2.6, “Configuring the Agents to Use SSL,” on page 1166

If you have already set up SSL on your system and are using it with other applications besides
GroupWise, skip to Section 75.2.6, “Configuring the Agents to Use SSL,” on page 1166.

novdocx (en) 22 June 2009

75.2.1 Generating a Certificate Signing Request

Before the GroupWise 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 GroupWise agents to use
SSL. However, all GroupWise agents running on the same server can all use 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.

One way to create a CSR is to use the GWCSRGEN utility. This utility takes the information you

.csr

provide and creates a

1 Start the GroupWise Generate CSR utility.

Linux: The utility (

directory. You must be logged in as root to start the utility.

Windows: The utility (

directory either on the GroupWise 8 DVD or downloaded GroupWise 8 image, or in
the GroupWise software distribution directory.

file from which a public certificate file can be generated.

gwcsrgen

gwcsrgen.exe

) is installed to the

) is located in the

/opt/novell/groupwise/agents/bin

\admin\utility\gwcsrgen

Encryption and Certificates 1161

2 Fill in the fields in the Private Key box. The private key information is used to create both the

Private Key file and the Certificate Signing Request file.

Key Filename: Specify a name for the Private Key file (for example, server1.key). If you don’t
want the file stored in the same directory as the GWCSRGEN utility, specify a full path with
the filename (for example,

server1.key

NetWare: Filenames can consist of up to 8 characters, with extensions of up to 3 characters.

Linux: Use only lowercase characters.

Windows: No limitations

). The directory where you want to create the

c:\certs\server1.key

or

/opt/novell/groupwise/certs/

.key

file must already exist.

Key Length: The key length can be 1024, 2048, or 4096. The default is 1024.

Key Password: Specify the password for the private key. The password can be up to 256

characters (single-byte environments).

Verify Password: Specify the password again.

3 Fill in the fields in the Certificate Signing Request box.

novdocx (en) 22 June 2009

CSR Filename: Specify a name for the Certificate Signing Request file (for example,

server1.csr

utility, specify a full path with the filename (for example,

novell/groupwise/certs/server1.csr

). If you don’t want the file created in the same directory as the GWCSRGEN

c:\certs\server1.csr

or

/opt/

). The directory where you want to create the

file must already exist.

NetWare: Filenames can consist of up to 8 characters, with extensions of up to 3 characters.

Linux: Use only lowercase characters.

Windows: No limitations

4 Fill in the fields in the Required Information box. This information is used to create the

Certificate Signing Request file. You must fill in all fields to generate a valid CSR file.

Country: Specify the two-letter abbreviation for your country (for example, US).

State/Province: Specify the name of your state or province (for example, Utah). Use the full

name. Do not abbreviate it.

City: Specify the name of your city (for example, Provo).

Organization: Specify the name of your organization (for example, Novell, Inc.).

Division: Specify your organization’s division that this certificate is being issued to (for

example, Novell Product Development).

Hostname of Server: Specify the DNS hostname of the server where the server certificate will
be used (for example, dev.provo.novell.com).

5 Click Create to generate the CSR file and Private Key file.

.csr

The CSR and Private Key files are created with the names and in the locations you specified in
the Key Filename and CSR Filename fields.

1162 GroupWise 8 Administration Guide

75.2.2 Using a GWCSRGEN Configuration File

For convenience, if you need to generate multiple certificates, you can record the information for the
above fields in a configuration file so that the information is automatically provided whenever you
run the Generate CSR utility. The configuration file must have the following format:

[Private Key]
Location =
Extension = key

[CSR]
Location =
Extension = csr

[Required Information]
Country =
State =
City =
Organization =
Division =
Hostname =

novdocx (en) 22 June 2009

If you do not want to provide a default for a certain field, insert a comment character (#) in front of
that line. Name the file

gwcsrgen.cnf

. Save the file in the same directory where the utility is

installed:

Linux:

Windows:

/opt/novell/groupwise/agents/bin

\grpwise\software\admin\utility\gwcsrgen

75.2.3 Submitting the Certificate Signing Request to a Certificate Authority

To obtain a server certificate, you can submit the Certificate Signing Request (
file) to a Certificate Authority. If you have not previously used a Certificate Authority, you can use
the keywords “Certificate Authority” to search the Web for Certificate Authority companies. The
Certificate Authority must be able to provide the certificate in Base64/PEM or PFX format.

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

server_name.csr

75.2.4 Creating Your Own Certificate

 “Using ConsoleOne on Windows or Linux” on page 1163

 “Using YaST on Linux” on page 1165

Using ConsoleOne on Windows or Linux

The Novell Certificate Server, which runs on a NetWare

®

server with Novell eDirectoryTM, enables
you to establish your own Certificate Authority and issue server certificates for yourself. For
complete information, see the Novell Certificate Server Web site (http://www.novell.com/products/

certserver).

Encryption and Certificates 1163

To quickly create your own public certificate in ConsoleOne:

1 Click Help > About Snapins 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 (http://

download.novell.com). 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 below.

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

3 Click Tools > Issue Certificate, then in the Filename field, browse to and select the CSR file

created by GWCSRGEN in Section 75.2.1, “Generating a Certificate Signing Request,” on

page 1161.

novdocx (en) 22 June 2009

4 Click Next.

By default, your own organizational certificate authority signs the request.

5 Click Next.

6 In the Type box, select Custom.

7 In the Key Usage box, select all three usage options.

1164 GroupWise 8 Administration Guide

8 Click Next.

9 In the Validity Period field, select the length of time you want the certificate to be valid.

You might want to change the setting to a longer period of time to best meet the needs of your
organization.

10 Click Next, view the summary information, then click Finish.

11 Select File in Base64 Format.

12 Specify the path and filename for the certificate.

novdocx (en) 22 June 2009

NetWare: Filenames can consist of up to 8 characters, with extensions of up to 3 characters.

Linux: Use only lowercase characters.

Windows: No limitations

.b64

You can retain the

extension or use the more general

.crt

extension.

13 Click Save.

Using YaST on Linux

root

1 On the Linux server desktop, click Computer > YaST, then enter the

password.

2 Click Security and Users > CA Management.

3 If you did not create the

YaST_Default_CA

during the installation of Linux on the server:

3a Click Import CA, specify the name and location of an existing CA, click OK, then skip to

Step 4.

or

Click Create Root CA, then continue with Step 3b.

3b Fill in the following fields:

CA Name: Specify the name of the CA certificate.

Common Name: Specify the name of the Certificate Authority.

Organization: Specify the name of your organization (for example, Novell, Inc.).

Organizational Unit: Specify your organization’s division that this certificate is being

issued to (for example, Novell Product Development).

Locality: Specify the name of your city or other regional division (for example, Provo).

State: Specify the name of your state (for example, Utah). Use the full name. Do not

abbreviate it.

Country: Select the name of your country (for example, USA).

Encryption and Certificates 1165