The backup/restore feature lets you take a snapshot of all the configuration files and save them to a separate system for safe keeping. If a ClarkConnect system needs to be restored, you can re-install the ClarkConnect system and then restore all the configuration settings from the backup.

If you did not select this module to be included during the installation process, you must first install the module.

The backup/restore tool saves all the configuration information available through the web-based interface:

• Usernames and passwords (4.0 or higher)
• Network configuration
• Firewall configuration
• Software configuration (for example, content filter)

The backup/restore settings tool does not save user data, logs or mailboxes. Use the LAN/Backup and Recovery tool for backing up data.

If you have installed third party applications on your system, you will need to take extra steps to save configuration data.

During the restore procedure, the original network settings will be restored, but not activated. Consider this scenario:

• The system settings on a live ClarkConnect gateway have been saved.
• Due to a hard disk failure, ClarkConnect was temporarily replaced with a basic router.
• ClarkConnect is re-installed on another server while connected to your LAN.
• The restore procedure is then used on the newly installed ClarkConnect system.

The network settings are now in limbo. The restored network configuration is expecting to be connected as a gateway, but the system is temporarily running as a standalone system on your LAN. In this scenario, you will either need to put the system back into its role as a gateway, or, reconfigure the network.

The date configuration tool allows you to select your time zone as well as enable/disable automatic time synchronization.

It is important to have the correct time zone configured on your system. Some software (notably, mail server software) depends on this information for proper time handling.

Keeping your system time accurate is recommended, so we suggest having the automatic time update enabled.

The encrypted volume module allows the creation of encrypted volumes that can be used to protect confidential data from unauthorized access in the event the server is physically removed from the premise or a portable mass storage device is lost/stolen while in transit.

Data is stored in an encrypted format when a volume has not been mounted. Mounting a volume requires the password. With a strong password, gaining access to the decrypted data (i.e. usable information) is impossible in the event the volume is unmounted. A volume is unmounted whenever a server is restarted (i.e. a shutdown, loss of power etc.) and must be mounted by an administrator having both Webconfig access and the volume password. It is important to note that this module does not provide protection against unauthorized access to data when a volume is mounted (i.e. the state the volume would normally be in during every day use). This module does not replace the need to maintain software updates, use of a properly configured firewall, IDS/IPS etc.

If you did not select this module to be included during the installation process, you must first install the module.

Any number of encrypted volumes can be created on the server - either on the local hard disk or an external mass storage devices. Volumes created on the local disk reside in parallel with other system/user data. By contrast, volumes created on unmounted devices (i.e. a USB attached hard disk) fill the entire physical disk size…formatting any/all data that may be on an existing file-system.

A unique name that describes the volume (i.e. ArchivedMail, ExternalUSB etc.)

The location the volume will be accessible. By default, the mount point is created in

/mnt/dmcrypt/<VolumeName> 

The physical device location.

The size (in MB) of the encrypted volume. Keep in mind, encrypted volumes have an encryption overhead approximately equal to 1-5% of the total defined size of the volume.

The password required to mount the encrypted volume.

Re-enter the password to verify.

In a word: don't. If you forget a volume encryption password, there is absolutely no way to recover the data. How can I auto-mount my encrypted volumes on bootup? You cannot…this would defeat the purpose of creating an encrypted volume.

• DM-Crypt Project Home Page

You can change the language used by ClarkConnect from this configuration page.

This configuration page gives you a bird's eye view of the services (also known as “daemons”) on your system.

A tool to shutdown or restart your system.

This module is installed only when a module dependent on the Mailer class is installed. To install manually, run:

# apt-get update              
# apt-get install cc-mailer 

Configuration of the SMTP relay is access under System Tools SMTP Relay.

The hostname of the SMTP server to connect to.

The port to used to send the initial connection request on. SMTP usually uses port 25.

Encryption protocol to use when connecting to the host server.

A valid username to authenticate to the server.

A valid password to authenticate to the server.

Once you have decided on the SMTP server to relay through and obtained and entered the settings necessary, it is time to test the relay to ensure e-mails can get through. Click on the Test Settings link. A form will be displayed requiring the input of a valid e-mail address. Enter an address that you can easily verify receipt of the test message that will be sent.

Click on the Send Test E-mail once you have entered the recipient of the test e-mail. If a successful connection and authentication (if required) is made, you will receive a notification that the test was successful. If the connection could not be made or if authentication using the settings provided failed, you need to go back and check your settings for correctness and update before repeating the test.

You should also verify that receipt of the test e-mail that is sent to the address specified, especially in the cases where you're using localhost as the SMTP hostname. You may find the test is successful, but you never receive the test message. In this case, the message could be queued on the local server and unable to deliver - usually because an ISP is blocking SMTP traffic.

If you are running a local SMTP service on the same server, you can leave the default in place (ie. port 25 at “localhost”). Keep in mind, this assumes that your local mail server is either:

• a) relaying directly and your ISP does not filter/block SMTP (port 25) traffic
• b) relaying through your ISP's SMTP servers
• c) configured to relay through an alternative (possibly non-standard port) relay service

If the system you are configuring is subscribed to ClarkConnect's ASP Antivirus and/or Antispam service, you can use Point Clark Networks' SMTP server to relay though, bypassing any filtering (blocking) on the part of your ISP.

With a valid Gmail account, one can easily setup the ClarkConnect's 'Mailer' module to relay through Google's SMTP server. Here is an example for a user with a Gmail account of “pcnl.developer@gmail.com”.

• SwiftMailer

SSL certificates are the de-facto standard for encrypting information sent over a network and can also be used to provide authentication, as in the case of SMIME email signature signing.

This module provides an administrator with the ability to create a Certificate Authority (CA) which can then be installed as a trusted CA on any operating system, browser or mail client in order to encrypt/decrypt (and/or sign emails) communications between two computers. Creating your own CA and using it to sign certificates is termed “self-signing”.

Self-signing of certificates is as secure as purchasing signed SSL certificates from a Trusted CA like Thawte or Verisign, where prices range from $US 50-300 per year. Self-signing is extremely convenient (and cost effective!) if you are providing access to known users (ie. employees, clients, vendors etc.). It is less convenient than a Trusted CA when dealing with unknown users such as website visitors using a browser to access your online store using HTTPS (HTTP over SSL), since the user will be prompted by their browser to trust the certificate that is presented to them.

The SSL Certificate Manager module can also create Certificate Signing Request (CSR) certificates. The contents of a typical CSR certificate are shown below:

A CSR is an unsigned copy of your certificate which can then be sent to a Trusted CA to be signed. The CSR will be used by the Trusted CA to generate your signed x509 SSL certificate (CRT). The Trusted CA sends back the signed certificate which may look similar to the CSR, but is not.

Whether your CRT was self-signed or signed by a Trusted CA, it now represents the public part of a public/private key (certificate) pair. The private half of the key (usually ending in .key or -key. pem) was generated automatically during the CSR creation and should never be sent across an untrusted network (i.e. the Internet). Unless this key was intended to secure another server, it should not be moved from its directory of origin (/etc/ssl/private).

This module is installed by default and should not be un-installed. SSL certificates are used by the Webconfig User Interface.

A Certificate Authority (or CA) is a trusted entity which issues digital certificates for use in cryptography and/or authentication. When dealing with unknown persons, you will probably want to use a commercial CA which is in business to provide a service - verifying an individual or organization is who they say they are, usually by way of a domain name or email address. The SSL Certificate Manager module allows you to create your own CA that one can then use to sign and validate certificates. You can have users download and import this CA to validate certificates presented to them. A common and cost-effective use of a self-signed certificate is the SSL certificate that encryptions communications in the Webconfig User Interface.

The module will force you to create a CA prior to allowing the creation of certificates requests, signed certificates or PKCS12 files. The form to create the CA is presented when no CA is found on the server (in the /etc/ssl directory) and is shown in a screenshot below. A brief description and suggested defaults is provided in the following sections.

This is the RSA key length. 1024b (default) is a good compromise between security and speed. Anything below 1024b can theoretically be cracked by brute force techniques. Note, this is the RSA key size and will not impact, for example, the encryption strength of a web browsing session (typically 128b, but could be 40b or 256b) that is dictated by the capabilities/settings of both the client web-browser and server.

The common name in the certificate authority can be anything. Generally speaking, you will want this to be descriptive of the purpose of the certificate as a trusted root certificate. An example might be Point Clark Networks Root Certificate Authority.

Typically the company name or person responsible for the CA. Example - Point Clark Networks Ltd.

In larger organizations, the organization unit might be a department within the company, such as IT Department.

The organization's city - for example, Toronto.

The organization's state or province - for example, Ontario or ON. Leave blank if this does not apply.

The organization's country - for example, Canada. The module will automatically convert the country to the 2-letter ISO-3166 country code.

The e-mail address of the person responsible for the CA within the organization - for example, certificates@pointclark.net.

Once a Certificate Authority has been created on your server, you will see a summary of the CA and any certificates you have created. If you have only just created your CA, you obviously won't have any signed certificates or PKCS12 files and your summary will look similar to the screenshot below.

Use the form below the three summary tables as illustrated above to create either a certificate request or signed certificate. For those new to SSL and encryption, it may not be immediately obvious as to the difference.

The certificate request is a pre-cursor to creating a signed certificate. It represents the public half of the private/public key pair used in RSA encryption. All signed certificates originate from a certificate request. A certificate request does not have an expiry date associated with it, but does have all the other fields associated with a signed certificate (common name, organization name etc.). A certificate request is cannot be used in cryptography and must be signed (usually from a trusted CA for an annual fee) in order to be useful.

As the name implies, this is a public certificate (the public half of the RSA private/key pair) that has been signed (verified) by a Certificate Authority (CA). The CA's service to the certificate holder and to anyone viewing the certificate is as a 3rd party validation as to the authenticity of the certificate owner. For example, if the certificate is to be used on an encrypted website (HTTPS), the CA will take measures to verify the owner of the domain against the certificate request being presented to be signed. A signed certificate has both a not-valid before and non-valid after timestamps that was attached to the certificate when the CA signed the request.

If you have determined a need for a trusted CA to sign a certificate request, you can use the Webconfig UI to generate the key. Select the purpose for the certificate (web/FTP encryption or e-mail signing/encryption) and your RSA key size (1024b recommended) and select Use Trusted CA (fees may apply) option from the Signing Authority field. Complete the other fields as they apply (see troubleshooting below) and click Create.

Notice how the Term field disappears when you selected Use a Trusted CA option - this is by design, since certificate requests do not store expiry dates.

Selecting the Self-Sign option will use the CA you created during the initializing of the SSL module to sign a certificate request that is temporarily created during the creation process.

In the example below, we sign our own certificate whose intended use will be to sign e-mail originating from “Joe Developer” at Point Clark Networks.

Two differences to note from the creation of a certificate request example above. First, there is an additional Term field - this field indicates the expiry date from the date of creation. For convenience, some users may want to set this to 25 years (essentially no expiry), but lesser terms may be desired for some applications. Second, additional fields named Import Password for PKCS12 and Verify Password for PKCS12 are visible. The Personal Information Exchange Syntax Standard (also called PKCS12) file is a convenient format to install certificates onto client machines for use in validating e-mail signatures. The file is protected with a password since the PKCS12 file contains both the private and public keys associated with the SSL signed certificate.

In order to import a signed certificate from a trusted CA, you first need a Certificate Request. If you haven't made one already follow the steps [#Creating_a_Certificate_Request here]. Certificate requests (also known as unsigned certificates) will be listed in the Unsigned Certificates as shown in the screenshot below.

This request needs to be downloaded and sent (typically via e-mail or a web form) to a Trusted CA. Click on the View link to view the contents of the certificate, including the part a Trusted CA requires.

At this point, you have two options to download the certificate request. First, use the Download link to save the entire PEM file to your local machine. The second option is to simply select the PEM Contents text starting from and ending (and including) the tag with your mouse, and “cut-and-paste” this into an e-mail to be sent to a Trusted CA or a web form for submittal.

Once you receive the signed certificate back from the Trusted CA (a process that make take up to 48 hours), return to the SSL Webconfig page, click on View again, and this time, select Import Signed Certificate from the available Actions. A web form will be displayed allowing you to “paste” the certificate contents.

Once “copied-and-pasted” into the form, click Save. Your certificate is now imported and ready for use.

The Personal Information Exchange Syntax Standard (or PKCS12) file is an industry standard format for storing or transporting a user's private keys, certificates or other secret information. The PKCS12 file format is used with the SSL module in ClarkConnect's Webconfig to password-protect and relate a private key tied to an e-mail address with a certificate authority in order to sign and/or encrypt e-mail.

A PCKS12 file is created automatically when a self-signed certificate is created with the Purpose/Use is set to Sign/Encrypt E-mail. See section Creating a Signed Certificate for information related to the fields/settings to create the PKCS12 in parallel with a self-signed certificate.

To create a PKCS12 file, you should already have a signed certificate under management with the appropriate e-mail that will match the user's signature (ie. e-mail address). The screenshot below shows one certificate (Joe Developer's) - in addition to the root CA - for the purpose of signing Joe's e-mail (joe.developer@pointclark.net).

To start the PKCS12 creation, click on the View link next to the certificate. Details of the certificate along with several actions which can be executed on the signed certificate will be displayed, similar to below.

If you do not see the Create PKCS12 option, it is because it already exists on the system. Return to the main menu and look under the PKCS12 Files table.

Since the certificate already exists, you only need to provide the password and verification that will be used to secure the PKCS12 file.

Clicking on the “Create” button will create the PKCS12 file using the password supplied and list it for download under the PKCS12 section. See the next sub-section for information on downloading and installing the file to your computer.

Provided you have been successful in creating a PKCS12 file, you should see thes files listed under the PKCS12 Files table. You can delete these files at any time, with the knowledge that the file can be re-created with a new password, if necessary, at any time. Since the PKCS12 file is specific to a user, once provided to the user, there is no need to keep the file on the server, except for purposes of backup. The screenshot below shows the PKCS12 summary, containing one file for Joe Developer. Assuming we are Joe Developer or Joe's IT administrator, we will now go through the steps to import (download) the PKCS12 file and install it.

Click on the Download link next to the PKCS12 you wish to download to your local machine (computer). Depending on your OS and browser, you will see a dialog box similar to the one shown below.

If access is from the machine where the file will be installed, you can choose the “Open With” which uses the PFXFile binary in Windows. If you will be e-mailing or making the file available to download via alternative ways (ie. FTP), you'll need to “Save to Disk” to save a copy of the PKCS12 file locally.

Installing on Thunderbird | If you use Mozilla's Thunderbird e-mail client, you need to use the “Save to File” option and import into the client in a separate step (see below).

Examples have been provided for installing PKCS12 files into two of the more popular mail clients, Thunderbird and Outlook/Outlook Express.

Before starting, make sure you have downloaded or received your PKCS12 file and saved it to your local machine. If you have not yet done this, see instructions provided in the above sections.

Open the Thunderbird mail client and click on Tools » Account Settings. Click on the Security summary under your account. You should see a form similar to the screenshot provided below.

Click on View Certificates under the Certificates section. Under the Your Certificates tab, click on Import. Use the file manager dialog pop-up to select the PKCS12 file you saved to your computer earlier. At this point, you may be prompted to created a master password for the security device. Choose a password you can remember but also difficult for anyone to guess. You will need to use this password each time you close and re-open Thunderbird to send a signed or encrypted e-mail.

You will then be prompted for the password for the PKCS12 file you are about to import. This is the password that was used during the creation of the PKCS12 using the ClarkConnect SSL Manager module. You should now see your certificate installed under Your Certificates.

You're not quite done - note how the Purposes field indicates Issuer Not Trusted. What you did not see happen transparently when installing the PKCS12 file is the import of a trusted CA under the Authorities section. You need to explicitly confirm what purpose Your Certificate can be used for. Click on the Authorities tab and scroll down until you find the Certificate Authority that was used to sign the certificate used to create the PKCS12 file. When you find your CA in the list, click once to highlight it and then click on the Edit button. A pop-up dialog box will be displayed as shown below.

Place a check mark in each checkbox, and click OK. Go back to the Your Certificates - you should now see the message Issuer Not Trusted has been replaced with Client, Server, Sign, Encrypt. Close the Certificate Manager dialog window and click on either of the Select buttons in the Digital Signing or Encryption sections. You will be prompted to select a certificate from a drop down box which will likely just have the one certificate you installed. Select it, and click OK. Close the Account Settings dialog window by clicking OK.

Congratulations - you can now sign e-mail and receive encrypted e-mail if senders use your public key to encrypt the message.

Outlook and Outlook Express uses the Windows OS certificate manager to perform message signing and encryption/decryption. The following help section describes how to install a PKCS12 file onto Microsoft's XP platform.

Click on Start » Control Panel and select Internet Options from the menu system. Select the Content.

Working in the Certificate dialog box pop-up, select the Personal tab and click on the Import button. An Import Wizard will start up, taking you the process in steps. Click Next to continue. Click on the Browse button and find the PKCS12 file that you saved to your system. Note, you may have to the default file type from X509 to Personal Information Exchange to see the proper extensions. Click Next to continue. The wizard will then ask you for the password. Enter the password you used in the ClarkConnect SSL Manager module when creating the PKCS12 file. It's also a good idea to check off both check boxes for additional security.

Keep the default location to store the certificate - Personal Store. Click Next to continue. Click Finish to complete the PKCS12 install. Unlike Thunderbird, Microsoft automatically enabled the uses for the certificate.

Congratulations - you can now sign e-mail with Outlook and receive encrypted communications from people using your public key.

Certificates that have been self-signed by the locally created Certificate Authority can be renewed at any time. Click on the View link, followed by the Renew button under the action options. A form similar to the one below will allow you to select the term to extend the original certificate in addition to re-issuing a new PKCS12 file with password.

When renewing a certificate that was not self-signed, a new certificate request will be created which can then be sent to a Trusted CA for signing and subsequent import.

There are really only two fields in the certificate generation process that can get you into trouble - Common Name and E-mail. These fields are explained below in relation to the two typical applications of SSL certificates (web and email).

For websites or FTP, the Common Name field must match exactly the domain name of the site.

Typically, this field would be the e-mail address of the web master or some alias referring back to support.

Website URL: https://secure.clarkconnect.com/webapp/ Common Name = secure.clarkconnect.com E-mail = accounts@pointclark.net

The common name is typically the full name of the individual.

This field must match exactly the e-mail address of the sender who intends to include a signed signature and/or receive encrypted communications.

E-mail Address of Sender: joe.developer@pointclark.net Common Name = Joe Developer E-mail = joe.developer@pointclark.net

• OpenSSL
• Public Key Cryptography
• CA Cert
• Certificate Authorities

The Webconfig settings page allows you to change the look and feel of the web-based interface.

A variety of templates are available for the web-based administration tool; select the one that most appeals to you.

Previous: Account Manager | Next: Database || Return: Index