GroupWise 8 Security

From CoolSolutionsWiki

GroupWise 8 Best Practices

GroupWise 8 Security

Contents


Introduction

Security can be a broad subject but for GroupWise we're basically talking SSL. System hardening topics bleed into this section as well, but if you're looking for info on using SSL connectivity for your GroupWise system you've landed on the right page.



System Preferences


A GroupWise system does not require any of the users to have access to the file structure that is hosting the Post Offices, Domains or any other element (restore area excepted in some designs).

The only area that the help desk administrators require access to is a/the domain database (WPDOMAIN.DB) To manage the help desk administrators it can be worth creating a dedicated administration domain to which they have access rights rather than allow them to connect to any domain database.

For system administrators access to the domains is required for a number of tasks, however there should be one exception. One of the principle areas of GroupWise security is managed through restricting access to the Primary Domain: This setting is found in ConsoleOne

Tools | GroupWise System Operations | System Preferences - Under the Admin Lockout Settings Tab. 
Restrict System Operations to Primary Domain

By setting this option changes that would alter the whole system can ONLY be made when connected to the Primary Domain. When set and ConsoleOne is connected to other (secondary) domains the options that would effect the whole system are displayed as greyed-out.


Secure Communications


It may sound silly and obvious, but it really is a good idea to encrypt your data transmissions. Back when GroupWise 5 was released 56/64bit encryption was considered a big thing... Today we almost call that obfuscation rather than encryption.

There are a lot of different transmissions in a GroupWise system


Source Destination Encryption Possible?
MTA POA Native GW by default, SSL Optional.
MTA GWIA Native GW by default, SSL Optional.
MTA WebAccess Agent Native GW by default, SSL Optional.
MTA MTA Native GW by default, SSL Optional.
POA Client Native GW by default, SSL Optional.
POA IMAP4 SSL Optional.
GWIA POA (for IMAP4) Native GW by default, SSL Optional.
GWIA POA (For POP3) Native GW by default, SSL Optional.
GWIA POP3 SSL Optional. Enabled/Required
GWIA IMAP4 SSL Optional. Enabled/Required
GWIA SMTP SSL Optional. Enabled/Required (1), (2)
WebAccess Agent POA Native GW by default, SSL Optional.
GWIA POA Native GW by default, SSL Optional.
GWIA POA Native GW by default, SSL Optional.
All Agents HTTP Interface SSL Optional.
All Agents SOAP Interface SSL Optional.

Notes:

(1) SMTP is sent between servers in clear. The SSL option is between a client and server and should be used when authentication between the client and the server is required (with POP3 or IMAP4 clients)
(2) SMTP and SSL encryption can be tricky - best to use a dedicated GWIA to do the required SMTL + SSL that will therefore NEVER talk in clear.

When GroupWise 8 shipped there were a couple of changes on the SSL side that change what goes on: First it tries to enable SSL on the client server communications by default and secondly the default access for the HTTP interfaces also uses SSL.


Anti-Virus


This is referenced in the Design section

Using Third Party SSL certificates for GroupWise Agents


Using the native "gwcsrgen" utility is an easy way to generate SSL Certificate Signing Request (certificate.csr) files and private key files (certificate.key) files. Usually we submit .csr files to our eDirectory Certificate Authorities (CA) using ConsoleOne and create SSL certificates for our GroupWise agents. These certificates are used to secure inter-agent and client to agent communications.

Up to version 7 GroupWise agents or clients did not bark or refuse a certificate because it was signed by an unknown CA like the one for your tree. However, with the GroupWise 8 clients SSL certificates signed by your eDirectory CA are handled in the same fashion they would be by your Internet browser. By telling you of this "untrusted" condition and asking you to make the decision to trust it. This is the typical way of handling a certificate signed by a "non-published" or "unknown CA". Basically a CA your browser or application is not hard coded to trust. This is an operational nuance that the leadership and management in many IT departments as of late have opted to dislike. So providing third party SSL certificates signed by known CAs for Post Office Agents (POA) in GroupWise 8 systems to avoid the user facing aspect of this behavior is becoming popular.

So, is there actually a problem to solve here? For the most part no. Installing SSL certificates from published CAs is very similar to the normal and familiar procedure. You submit your .csr file created by the gwcsrgen utility to a published SSL certificate vendor like Verisign or GoDaddy and have a .pem (usually the default for SSL vendors) formatted SSL certificate file provided for your agent. There is no need to send them your private key file and you shouldn't. The returned SSL certificate should be a text file you can open that has a section that starts with:

-----BEGIN CERTIFICATE-----

and ends with:

-----END CERTIFICATE-----


The actual certificate data content is omitted for brevity


This text can be copied to a new text file saved with a .crt extension (my favorite but not required) and placed in the same location as your .key file. This location of course must be available to the agent and is referenced in your POA configuration.

However, here's the onion. Some published SSL certificate vendors require you to install Intermediate CA and Root CA certificates as well. These are SSL infrastructure components that build the trust relationships between SSL certificates and applications. Basically it works like this. You can trust me because he said you could and you can trust him because this guy said you should. This is called a "certificate signing chain" and it is a standard. Some vendors have Intermediate and Root CA certificates available over the internet for reference and some reference them locally.


Recent Thawte SSL certificates are a good example:

Thawte rolled over to new 2048bit CA root servers in July 2010. This means any Thawte certificate issued after June 26th 2010 will require new root and intermediate certificates to be installed as well.


So, if you purchase a SSL certificate for your GroupWise agent that must refer to local CA certificates there are additional steps to complete. After all, how to you tell your GroupWise agent to use a specific set of CAs for it's signing chain when there is no configuration option to do so.

Fortunately GroupWise 8 agents can use "chained certificates" if the pem formatted files for the certificate and it's chain of CA certificates are concatenated in the same file. So it's simply a bit of an expansion of the previous procedure.

You'll need to obtain copies of the pem formatted Intermediate and Root CA certificates from your SSL vendor. These should be an easily accessible free download.

Then combine them in a single file in the following format using a text editor on the target platform:

-----BEGIN CERTIFICATE-----
server certificate text 
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
intermediate certificate text
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
intermediate certificate text
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
trusted root text
-----END CERTIFICATE-----


Again the actual certificate data content is omitted for brevity


Then you can simply configure the certificate in the agent SSL configuration normally

Using OpenSSL for GroupWise Agent SSL certificates and .csr files


Using OpenSSL to create SSL Certificates for GroupWise agents

Using the GroupWise Certificate Generation Utility is the default tool for creating Certificate Signing Requests (CSR) and SSL key files for GroupWise agents. The utility is called gwcsrgen.exe for the NetWare and Windows platform and gwcsrgen on the Linux platform. ConsoleOne, with the appropriate eDirectory Certificate Server snapins installed can then be used to consume the agent CSR files and produce the Base64 encoded certificate the GroupWise agent(s) require. It is important to note that the certificate is required to be encoded using the Base 64 format but the “.b64” extension is not required.

Alternatively, the OpenSSL application can be used to perform all of these tasks and more. The advantages of using OpenSSL are that it is available on all platforms supported by GroupWise, it provides additional flexibility, and reduces the applications required to create GroupWise agent certificates. One particular task it can be used for that the gwcsrgen utility cannot perform is to create and sign SSL certificates that include multiple domain names or “alternative names”.

Requirements:

  • Have a configured Certificate Authority (or its public certificate and key file) available on the same server as the OpenSSL application
  • Know the name of your CA and the path and names of the CA public certificate and key files, and certificate serial number file
  • GroupWise still has 8.3 file name restrictions for certificate and key file names


For SSL certificates using a single domain name


Issue the following console commands to generate the CSR and key file:

mkdir /temp/certs
openssl req -new -newkey rsa:1024 -keyout /temp/certs/<your_key>.key -passout pass:<your_password>
-out /temp/certs/<your_csr>.csr


Be sure to answer the subsequent questions accurately according to your organisation's standards:

Country Name (2 letter code) [AU]:

State or Province Name (full name) [Some-State]:

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (eg, YOUR name) []:

Email Address []:

A challenge password []:

An optional company name []:


(These defaults can be pre-populated by entering them in the openssl.cnf file for your OpenSSL instance)


This generates a CSR with a 1024 bit encryption, a key file encoded with the provided password, in the /temp/certs directory


You can validate the information in your new CSR file with the following command:

openssl req -in /temp/certs/<your_csr>.csr -noout -text


You can validate the password used for the generated key file with the following command:

openssl rsa -in /temp/certs/<your_key>.key -text -noout


This should prompt you for and accept the new password to display the key information


Have the local CA produce and sign a properly serialised certificate using the provided CSR file and make it valid for five (5) years using the following command:

openssl x509 -req -days 1825 -in /temp/certs/<your_csr>.csr -CA /var/lib/CAM/<YOUR_CA_NAME>_CA/cacert.pem 
-CAkey /var/lib/CAM/<YOUR_CA_NAME>_CA/cacert.key -CAserial /var/lib/CAM/YOUR_CA_NAME>_CA/serial 
-out /temp/certs/<your_certificate>.crt


(This example uses the path to Certificate Authority certificates and files common to most Linux distributions)

NOTE:There is a growing security specialist movement that insist that certificates should only last for 2 years, this is so that they HAVE to be renewed and will therefore take advantage of new technology as soon as it is available. YMMV


To change the .key file password use the following command:

openssl rsa -des3 -passin pass:<old_key_password> -in /temp/certs/<your_old_key>.key 
-passout pass:<new_key_password> -out /temp/certs/<your_new_key>.key


You can also validate CSR, key, and certificate files at SSL Shopper

For SSL certificates using a multiple domain names


Performing this task requires some additional configuration tasks. It is recommended that you copy your existing “/etc/ssl/openssl.cnf” file to another name such as “/etc/ssl/multissl.cnf” for use with multi-domain name certificates.


Make the following changes to your new multissl.cnf file to support the version 3 extensions required for creating a certificate signing request (CSR) that is valid for multiple host names.

Note that these settings will apply for all CSR’s generated by any OpenSSL application instances that use this configuration file.

Modify the existing sections:

[ ca ]
<YOUR_CA_NAME_CA> = CA_default
[ req ] req_extensions = v3_req
[ v3_req ] # Extensions to add to a certificate request subjectAltName = @alt_names

Create the following section:

[ alt_names ]
DNS.1 = <SAME_DNS_PRIMARY_NAME> (Included for best practice reasons) 
DNS.2 = host.name.2
DNS.3 = host.name.3

The CSR file containing the alternate subject names is created successfully using this configuration. However due to a bug in the OpenSSL software the self signed certificates produced and signed by the CA will not contain them. A bug in the version 3 extension facility seems to be at fault.


To resolve this condition create an additional configuration file named “multiext.cnf” is created to facilitate the import of the version 3 extensions into the signed certificate. In this case the “subjectAltName” and “issuerAltName” extensions. The OpenSSL configuration file name and the new extension file name are open ended but cannot contain white space between text.


For example the file “multiext.cnf” contains the following additional section:

[ multissl ]
subjectAltName=DNS:<SAME_DNS_PRIMARY_NAME>,DNS:host.name.2,DNS:host.name.3
issuerAltName=issuer:copy


This file and the named section containing the version 3 extension values will be used when generating the self signed certificate.


Issue the following console commands to generate the CSR and key file:

mkdir /temp/certs
openssl req -config /etc/ssl/multissl.csr -new -newkey rsa:1024 -keyout /temp/certs/<your_key>.key 
-passout pass:<your_password> -out /temp/certs/<your_csr>.csr


Follow the same steps in the previous section to validate your CSR and key files.

Have the local CA produce and sign a properly serialised certificate using the provided CSR file for multiple hosts and make it valid for five (5) years using the following command:

openssl x509 -req -days 1825 -config /etc/ssl/multissl.cnf -extfile /etc/ssl/multiext.cnf 
-extensions multissl -in /temp/certs/<your_csr>.csr -CA /var/lib/CAM/<YOUR_CA_NAME>_CA/cacert.pem 
-CAkey /var/lib/CAM/<YOUR_CA_NAME>_CA/cacert.key -CAserial /var/lib/CAM/YOUR_CA_NAME>_CA/serial 
-out /temp/certs/<your_certificate>.crt


(This example uses the path to Certificate Authority certificates and files common to most Linux distributions)

NOTE:There is a growing security specialist movement that insist that certificates should only last for 2 years, this is so that they HAVE to be renewed and will therefore take advantage of new technology as soon as it is available. YMMV

To change the .key file password use the following command:

openssl rsa -des3 -passin pass:<old_key_password> -in /temp/certs/<your_old_key>.key 
-passout pass:<new_key_password> -out /temp/certs/<your_new_key>.key


You can also validate CSR, key, and certificate files at SSL Shopper

Apache


Enable and secure Apache with SSL on SLES10


Create SSL


The certificate used in the an Apache web server should be a certificate that does not contain a password - this differs slightly from the section above.


Create the CSR and key File

Best done in /etc/ssl/servercerts but can be done in /home

  • openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr

where server is the name of your server.

  • This begins the process of generating two files: the Private-Key file for the decryption of your SSL Certificate, and a certificate signing request (CSR) file (used to apply for your SSL Certificate) with apache openssl.


(The process for generating the CSR file for Apache is slightly different than that for GroupWise agents as Apache requires a key file with no password)


When you are prompted for the Common Name (domain name), enter the fully qualified domain name for the site you are securing. If you are generating an Apache CSR for a Wildcard SSL Certificate your common name should start with an asterisk (such as *.example.com).


You will then be prompted for your organizational information, beginning with geographic information. There may be default information set already.


Please enter the following 'extra' attributes to be sent with your certificate request

A challenge password []:

DO NOT USE.

An optional company name []:

DO NOT USE.

This will then create your openssl .csr file. Paste CSR into Certificate generation system (eDirectory and ConsoleOne/iManager/entrust/thawte/etc)

Await your cert


Turning on SSL in Apache


We need to edit the APACHE_MODULES and APACHE_SERVER_FLAGS sections in the /etc/sysconfig/apache2 file – either with VI or we can use the following SuSE trick lines

  • a2enmod ssl
  • a2enflag ssl

The reason why the flag SSL is also needed is because all SSL configuration is enclosed in <IfDefine> statements. This way it can be dormant until the necessary prerequisites are present and you want to use it at all. In addition, it can be useful to be able to start apache unattended at boot time even if you use encrypted keys that need a passphrase otherwise.


Install SSL certificate on Server


Copy .crt and key (and other chain/ca files) to server /etc/ssl/servercerts

To enable SSL Create vhosts entry for GW

  • cd /etc/apache2/vhosts.d
  • cp vhost-ssl.template gwssl.conf
  • Edit gwssl.conf
  • Edit SSLCertificatefile to point to certificate copied above
  • Edit SSLCertificatekeyfile to point to key copied above
  • Edit SSLCipherSuite HIGH:+MEDIUM:!SSLv2:!EXP:!ADH:!aNULL:!eNULL:!NULL
  • Edit SSLCertificateChainFile to point to key copied above (if required)
  • Edit SSLCACertificateFile to point to key copied above (if required)


Add the following rewrite element to a new file rewrite.conf in conf.d

:<IfModule !mod_rewrite.c>
:  LoadModule rewrite_module /usr/lib/apache2-prefork/mod_rewrite.so
:</IfModule>
:<VirtualHost _default_:80>
:  RewriteEngine On
:  RewriteCond %{REQUEST_URI} ^\/gw\/webacc
:  RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [L,R]
:  RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
:  RewriteRule .* - [F]
:</VirtualHost>