Public Key Infrastructure

Private Key

A block of data (a large binary number) generated using one of the PKI algorithms. Each party taking part in secure communications should keep its Private Key securely. This key should never be transferred between communication parties.

Public Key

A block of data (a large binary number) generated together with the Private Key. Each party taking part in secure communications can and should distribute its Public key openly. It is assumed that Public Key can be learned by anyone, including hostile entities. Public Keys are usually distributed in the form of Certificates.

Data Digest

A relatively small block of data calculated by applying a special digest function to the original (usually larger) data block.

Data Signature

A Digest of the Data block encrypted using the Private Key of the Signer.

Signed Data

A data block with attached Signature of that block. A party receiving Signed Data can verify that the data block has not been modified in transit by using the Public Key of the Signer to decrypt the Signature and to compare the resulting Data Digest with the Data Digest it calculated itself.

Certificate

A data block with containing the name of the Certificate owner (called Certificate Subject), the Public Key of the owner, the name of the Certificate Issuer, the serial number of the Certificate, and some additional data elements. This data block is signed by the Issuer.
Certificates play the role of Digital ID cards.

Issuer

A party that issues Certificates for other parties, signing them with the Private Key of the Issuer. Issuers are also called Certificate Authorities. Each certificate generated by a certain Issuer has a unique serial number.

Trusted Authorities

A list individually maintained by a communication party. Each list element contains the name of a "trusted authority" and its Public Key.
When a party receives any Certificate, it can check if the Certificate Issuer is included into the "trusted authority" list, and that the Certificate Signature can be verified using that "trusted authority" Public Key.
Modern operating systems allow users to securely maintain Trusted Authorities databases on their desktops.

Root Authorities

Globally recognized Certificate Authorities. Most modern operating systems pre-insert several Root Authorities into the client Trusted Authorities databases, making Root Authorities trusted by all client computers running these operating systems.

Authority Chain

A set of Issuer Certificates for a certain Certificate.
Some Authority X may be not widely accepted as a "trusted one", but its Certificate may be issued by a more widely trusted Authority Y. In this case Certificates issued by X won't be widely accepted, but if those Certificates are sent together with the X own Certificate, issued by Y, then these Certificates may be accepted by all parties that trust Y.

Self-Signed Certificate

A Certificate issued by a party for itself. The Subject and Issuer of such a Certificate are the same. The Self-Signed Certificate contains the party Public Key and is signed using the Private Key of the same party.
Self-Signed Certificates can be trusted only if other parties explicitly include them into their lists of "trusted authorities".

Multiparty Encryption

An encryption method used to send data to parties with known Certificates. A single encrypted messages can be independently decrypted by any party that possesses a Private Key matching one of the Certificates used for encryption.

Each CommuniGate Pro Domain has its own PKI settings. They include a Private Key associated with the Domain and Certificates containing the matching Public Keys.

To configure the Domain PKI settings, use the WebAdmin Interface to open the Domain Settings page for the target Domain, and click the Security link. The PKI page will appear:

PKI Services

default(Test)EnabledDisabledTest

This option allows you to specify the PKI Mode for this Domain:

Disabled

If this option is selected, PKI Functions for this Domain are disabled. If this option is selected, all other Domain PKI settings have no effect.

Test

If this option is selected, the Server-wide Test Private key and Test Certificate are used for this Domain. You do not have to configure any other Domain PKI settings if this option is selected. Use this mode for testing purposes only.
The Server-wide Test Certificate uses the Server Main Domain name as its Subject and AO StalkerSoft as the Issuer. The Test Certificate expires 30 days after the last Server restart time.

Enabled

If this option is selected, the Domain PKI functions are enabled.

Assigning a Private Key

Initially CommuniGate Pro Domains do not have any Private Keys assigned. You should select the size of the key and click the Generate Key button to create a random Private Key and assign it to the Domain.

Private Key
	Size:512102420484096

Note: depending on your server hardware platform, it can take up to several seconds to generate a 2048-bit Key.

Only after you assign a Private Key, the Certificate-related fields will appear on the Security page.

You can use any third-party program to generate a Private Key. You should instruct that program to output the Private Key in the PEM format (as shown below).
Copy the PEM-encoded Key (in the RSA or PKCS#8 format) into that text field, and click the Import Key button:

Private Key
	Enter a PEM-encoded Private Key: -----BEGIN RSA PRIVATE KEY----- MIIBPAIBAAJBAKrbeqkuRk8VcRmWFmtP+LviMB3+6dizWW3DwaffznyHGAFwUJ/I Tv0XtbsCyl3QoyKGhrOAy3RvPK5M38iuXT0CAwEAAQJAZ3cnzaHXM/bxGaR5CR1R rD1qFBAVfoQFiOH9uPJgMaoAuoQEisPHVcZDKcOv4wEg6/TInAIXBnEigtqvRzuy oQIhAPcgZzUq3yVooAaoov8UbXPxqHlwo6GBMqnv20xzkf6ZAiEAsP4BnIaQTM8S mvcpHZwQJdmdHHkGKAs37Dfxi67HbkUCIQCeZGliHXFa071Fp06ZeWlR2ADonTZz rJBhdTe0v5pCeQIhAIZfkiGgGBX4cIuuckzEm43g9WMUjxP/0GlK39vIyihxAiEA mymehFRT0MvqW5xAKAx7Pgkt8HVKwVhc2LwGKHE0DZM= -----END RSA PRIVATE KEY-----

Note: Make sure that the key you import is not password-encrypted. Something like the following starting lines:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-CBC,90C96A721C4E4B0B

GzLyio+Or3zXm1N7ILWlYDsR6cgPlzHomAxi6aeUthl4lSqBHaqMlh+/76I/6sNx
.................

indicate that the Private Key is encrypted and it cannot be imported into the Server.

If the Private Key is set correctly, and the Key can be used for public/private key cryptography, you will see the following panel:

Private Key
Key Size:	512 bit
Encryption Test:	Verification String is OK

If the Key Test field indicates an error, the imported Private Key cannot be used for public/private key cryptography.

Use the Remove button if you want to remove the entered Domain Private Key. Since the Domain Certificate can be used with one and only one Private Key, it becomes useless when you delete the Private Key, so the existing Domain Certificate will be removed, too.

Assigning a Certificate

A Domain must have a Certificate to support PKI functions.

The Domain Certificate name (the Common Name part of the Certificate Subject field) should match the domain name used by client applications.
If a CommuniGate Pro Domain has Domain Aliases, attempts to connect to the Server using a Domain Alias name will result in warning messages on the client workstations notifying users about the name mismatch. Since a Certificate can contain only one name, select the name (the real Domain name or one of the Domain Aliases) that your users will use in their client application settings. If your CommuniGate Pro Domain name is company.dom, and that domain name does not have a DNS A-record, but the Domain has an Alias mail.company.dom that has an A-record pointing to the CommuniGate Pro Server, your users will use the mail.company.dom name in their client settings and WebUser Interface URLs, so the Domain Certificate should be issued for the mail.company.dom name rather than the company.dom name.

You may also use "wildcard" domain names for your certificates. If the Domain name has at least 2 components, the Common Name menu will contain a "wildcard" domain name: the name of the Domain with the first component substituted with the asterisk (*) symbol. If the Domain name has only 2 components, the asterisk component is added to form a 3-component name.

To create a Certificate, fill the fields in the Certificate Attributes table:

Certificate Generator
Common Name:	d1.communigate.rumyalias.dom*.communigate.ru
Alternative Names:
Country:
Province:
City:
Organization:
Unit:
Contact:
Signature:	default(SHA1)MD5SHA1SHA2

Common Name

When the Certificate is sent to a client application, the application checks that the Certificate Common Name matches the name the user has specified in the URL and/or in the mailer settings.

Alternative Names

Optional comma-separated list of additional host names for which this certificate should be considered valid. Usually includes the Common Name as the first element.

Contact

This field must contain a valid E-mail address, though that address does not have to be inside this CommuniGate Pro Domain.

All other fields are optional.

To receive a Certificate from an external source ("trusted authority"), click the Generate Signing Request button. A text field containing the PEM-encoded CSR (Certificate Signing Request) will appear:

Certificate Generator
Common Name:	d1.communigate.rumyalias.dom*.communigate.ru
Country:
Province:
City:
Organization:
Unit:
Contact:
Enter a PEM-encoded Certificate
-----BEGIN CERTIFICATE REQUEST----- MIIBZTCCAQ8CAQAwgakxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTESMBAGA1UE BxMJU2F1c2FsaXRvMSEwHwYDVQQKExhBQ01FIFlhY2h0IFJlbnRhbHMsIEluYy4x GTAXBgNVBAsTEE9uLWxpbmUgU2VydmljZXMxFzAVBgNVBAMTDmQxLnN0YWxrZXIu Y29tMSIwIAYJKoZIhvcNAQkBFhNiaWxsQGRvbWFpbi5jb21wYW55MFwwDQYJKoZI hvcNAQEBBQADSwAwSAJBAKrbeqkuRk8VcRmWFmtP+LviMB3+6dizWW3DwaffznyH GAFwUJ/ITv0XtbsCyl3QoyKGhrOAy3RvPK5M38iuXT0CAwEAAaAAMA0GCSqGSIb3 DQEBBAUAA0EABFysKDutO/ZF16Sp7+LL3IcjUb29xlvZSnBXYsD/qWKqUF4gzfch 4Qyxci6ynsh7HNjdJBFdFyO+J2ywXZilYg== -----END CERTIFICATE REQUEST----- submit this request to a Certification Authority and paste the result below
Enter a PEM-encoded Certificate

Copy the CSR text and submit it to the Certification Authority (CA) of your choice. You can submit via E-mail or using a Web form on the CA site. The Certification Authority should send you back the signed Certificate in the PEM-format. Enter that Certificate into the bottom field and click the Set Certificate button.

If the Certificate is accepted, the Certificate information is displayed:

Domain Certificate
Issued to:	Country US Province CA City Sausalito Organization ACME Yacht Rentals, Inc. Unit On-line Services Common Name d1.communigate.ru Contact [email protected]
Issued by:	Country US Province CA City Sausalito Organization ACME Yacht Rentals, Inc. Unit On-line Services Common Name d1.communigate.ru Contact [email protected]
Serial Number:	89AB673940123456
Valid:	From: 06-Nov-07 Till: 05-Nov-09

The Certificate panel shows the Certificate Issuer (the Certificate Authority), the Certificate Subject (the data you have entered and the selected domain name), the Certificate serial number and the validity period of this Certificate.

Note: the entered Private Key and Certificate will be used for the Domain secure communications ONLY if the PKI Services option is set to Enabled.

Note: the Certificate contains the Domain name or a Domain Alias as a part of the "Subject" data.
When you rename the CommuniGate Pro Domain, the domain name in the Domain Certificate does not change, and the client applications may start to warn users about the name mismatch.

Click the Remove Certificate button to remove the Domain Certificate.

Assigning a Certificate Authority Chain

If the Certificate issuer is known to the users client software (mailers and browsers), the warning message does not appear on the user screen when the client software receives a Certificate from the Server. In many cases, the "trusted authority" does not issue certificates itself. Instead, it delegates the right to issue certificates to some other, intermediate authority. When your Server uses a Certificate issued by such an authority, the Server should also present the Certificate of that authority issued by the "trusted authority". The client software would check your Certificate first, then it will detect that the issuer of your Certificate is not a "trusted authority" and it will check the additional Certificate(s) the Server has sent. If that additional Certificate is issued by a "trusted authority", and it certifies the issuer of your Domain Certificate, your Certificate is accepted without a warning.

When you receive a Certificate from a Certificate Authority that is not listed as a "trusted authority" in the client software settings, that intermediate Certificate Authority (CA) should also give you its own Certificate signed with a "trusted authority". That Certificate should be in the same PEM format as your Domain Certificate:

Certificate Authority Chain (Optional)

-----BEGIN CERTIFICATE----- MIIEMTCCA5qgAwIBAgIQI2yXHivGDQv5dGDe8QjDwzANBgkqhkiG9w0BAQIFADBfMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDMgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTcwNDE3MDAwMDAwWhcN MDQwMTA3MjM1OTU5WjCBujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUG A1UECxMOVmVyaVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwg U2VydmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMgSW5j b3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA2IKA6NYZAn0fhRg5JaJlK+G/1AXTvOY2O6rwTGxbtueqPHNFVbLx veqXQu2aNAoV1Klc9UAl3dkHwTKydWzEyruj/lYncUOqY/UwPpMo5frxCTvzt01OOfdcSVq4 wR3Tsor+cDCVQsv+K1GLWjw6+SJPkLICp1OcTzTnqwSye28CAwEAAaOCAZAwggGMMA8GA1Ud EwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAgBgNVHSUEGTAX BgpghkgBhvhFAQgBBglghkgBhvhCBAEwggE1BgNVHSAEggEsMIIBKDCCASQGC2CGSAGG+EUB BwEBMIIBEzAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB5gYI KwYBBQUHAgIwgdkwFRYOVmVyaVNpZ24sIEluYy4wAwIBARqBv1ZlcmlTaWduJ3MgQ2VydGlm aWNhdGlvbiBQcmFjdGljZSBTdGF0ZW1lbnQsIHd3dy52ZXJpc2lnbi5jb20vQ1BTLCBnb3Zl cm5zIHRoaXMgY2VydGlmaWNhdGUgJiBpcyBpbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlIGhl cmVpbi4gU09NRSBXQVJSQU5USUVTIERJU0NMQUlNRUQgJiBMSUFCSUxJVFkgTFRELiAoYykx OTk3IFZlcmlTaWduMA0GCSqGSIb3DQEBAgUAA4GBALiMmMMrSPVyzWgNGrN0Y7uxWLaYRSLs EY3HTjOLYlohJGyawEK0Rak6+2fwkb4YH9VIGZNrjcs3S4bmfZv9jHiZ/4PC/NlVBp4xZkZ9 G3hg9FXUbFXIaWJwfE22iQYFm8hDjswMKNXRjM1GUOMxlmaSESQeSltLZl5lVR5fN5qu -----END CERTIFICATE-----

The CA Chain may include several certificates: the first one certifies the issuer of the Domain Certificate you have entered, but it itself may be issued by some intermediate authority. The next Certificate certifies that intermediate authority, etc. The last Certificate in the chain should be issued by some authority "known" to client software - usually, some Root Authority.

If your CA Chain contains several separate PEM-encoded Certificates, enter all of them into the Certificate Authority Chain field. The Certificate issued by a Root Authority should be the last one in the list.

Click the Set CA Chain button to assign the Certificate Authority Chain to the Domain. If all Certificates in the Chain are decoded successfully and their format is correct, the CA Chain list is displayed:

Certificate Authority Chain (Optional)
Issued to	Issued by	From	Till
Organization VeriSign Trust Network Unit VeriSign, Inc. Unit VeriSign International Server CA - Class 3 Unit www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign	Country US Organization VeriSign, Inc. Unit Class 3 Public Primary Certification Authority	17-Apr-97	08-Jan-04

Note: CommuniGate Pro checks only the format of each Certificate in the Chain. It does not check that each Certificate really certifies the issuer of the previous Certificate and that the last certificate in the Chain is issued by a Root Authority.

When set, the Certificate Authority Chain is sent to clients together with the Domain Certificate.

Click the Remove CA Chain button to remove the Certificate Authority Chain from the Domain Security Settings.

You can create a Self-Signed Certificate if you do not want to use any external Certificate Authority.
Click the Generate Self-Signed button and the CommuniGate Pro Server creates a Self-Signed certificate for you: the Issuer will be same entity you have specified, and the entire Certificate will be signed using the Domain Private Key. When a Domain has a Self-Signed Certificate, client applications will warn users that the addressed server has presented a certificate "issued by an unknown authority". Users can "install" self-signed certificates to avoid these warnings.

When client applications receive a Certificate and its issuer is not included into their list of Trusted Authorities, the applications may display warnings or they may refuse to accept the Certificate.

Your users can "install" your Domain Certificates into their Trusted Authorities lists. Once installed, the Certificate becomes a "trusted" one. For some programs (such as Mac versions of Microsoft Outlook and Outlook Express) installing an "untrusted" Certificate is the only way to use that Certificate for secure communications.

To install a Domain Certificate, the user should use a browser application and open the login page of the WebUser Interface for the selected Domain. If the Domain has an enabled Certificate, the Secure Certificate link appears. The user should click on that link to download the Domain Certificate and "open" it. The browser should allow the user to verify the Certificate and to install it into the list of Trusted Authorities.

When a Domain has a Self-Signed Certificate, the Refresh Self-Signed button appears on the WebAdmin page. Click this button to create a new Self-Signed Certificate with the same serial number, but with a new validity period.

The CommuniGate Pro Server can verify validity of Certificates presented to it. For example, the WebUser Interface performs validity checks when displaying signed messages.

A Certificate is considered valid if:

• it is equal to one of the Trusted Certificates, or
• it is issued by a holder of one of the Trusted Certificates.

There are several sets of the Trusted Certificates:

• Built-in trusted Certificates: these certificates are installed with the CommuniGate Pro Server software, and they are updated when the Server software is updated.
• Server-wide and Cluster-wider Trusted Certificates.
• Domain-wide Trusted Certificates.

When a PKI operation is performed for a certain Domain (or for a certain Account in that Domain), the following Trusted Certificates are checked:

• the Domain Trusted Certificates
• the Cluster-wide Trusted Certificates if the Domain is a Shared one, and the Server-wide Trusted Certificates if the Domain is not a Shared one
• the built-in Trusted Certificates

When a PKI operation is performed for the System itself (for example, an outgoing TLS connection is being established), the following Trusted Certificates are checked:

• the Server-wide Trusted Certificates
• the Cluster-wide Trusted Certificates
• the built-in Trusted Certificates

Use the WebAdmin Interface to update the set of Server-wide and Cluster-wide Trusted Certificates. Open Security page in the the Users realm. The Trusted Certificates page will open:

	Issued to	Serial Number	From	Till
	RSA Data Security, Inc.	02AD667E4E45FE5E576F3C98195EDDC0	09-Nov-94	08-Jan-10
	Thawte Personal Freemail CA	00	01-Jan-96	01-Jan-21
	Thawte Personal Basic CA	00	01-Jan-96	01-Jan-21
	My Company CA	010256FF	01-Jan-96	01-Jan-21

Trusted Certificates included into the displayed set have a checkbox marker. To remove certain Trusted Certificates, select its checkbox and click the Remove Marked button.

In addition to the certificates from the displayed set, the Domain-wide pages display the built-in Trusted Certificates, and the Trusted Certificates from the Server-wide set (or from the Cluster-wide set for Shared Domains).
The Server-wide and Cluster-wide Trusted Certificates pages display the the built-in Trusted Certificates.
These additional certificates do not have checkbox markers.

Enter a PEM-encoded Certificate

-----BEGIN CERTIFICATE----- MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhh d3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfY DFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5E rHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVq uzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zAN BgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjP MPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa /RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRznei gQ== -----END CERTIFICATE-----

To add a Certificate to the set, enter the PEM-encoded Certificate data into the text field and click the Set Certificate button. The new Certificate should appear in the displayed set.

The TLS (Transport Level Security) protocol a PKI application used to provide security and integrity of data transferred between a pair of communicating parties. The parties use PKI encryption to securely exchange a "secret key" data, and then all data transferred between the parties is encrypted using that "secret key". The earlier versions of the TLS protocol were called the SSL (Secure Socket Layer) protocols.

The CommuniGate Pro Server supports SSL/TLS connections for all its TCP-based services and modules. Secure connections can be established in two ways:

• A client application uses a special port to connect to the Server and starts to establish a TLS (encrypted) connection right after a TCP connection with that port is established. This method is used in all Web browsers when a https:// URL is used.
  This method is also used when SIP clients use the "TLS transport" option.
  Some mail clients use it for POP, IMAP, LDAP, and (rarely) for SMTP connections.
  To support these clients, configure the Listeners for HTTP, SIP, POP, IMAP, SMTP, and LDAP modules: the Listeners should accept TCP connections on those special ports (see the module descriptions for the proper Secure Port Numbers) and the Init SSL/TLS option should be enabled for those ports.
• A client application uses a standard port to connect to the Server, and then it issues a special command (usually called STARTTLS or STLS) over the established clear-text TCP connection. When the Server receives such a command it starts to establish a secure connection. To support these clients you do not have to configure additional ports with the module Listeners.

Usually certificates for SSL/TLS communications can be assigned only to the CommuniGate Pro Domains that have at least one assigned network (IP) address. This limitation comes from the design of the TLS protocols used today: when a client application wants to initiate a secure connection, the Server has no information about the Domain the client wants to connect to. The Server knows only to which local IP address the client has connected, so it opens the Domain this IP address is assigned to, and uses the PKI Settings of that Domain.

An exception to this rule is the XMPP protocol. Before an XMPP client sends the <starttls> command, it explicitly specifies the target domain in the <stream> data, so the Server can initiate a TLS session with a Domain that has no assigned network address.

Use the WebAdmin Interface to specify the Server-wide SSL/TLS processing parameters. Open the General pages in the Settings realm, and find the TLS Sessions panel on the Others page:

TLS Sessions
Log Level:	Crashes OnlyFailuresMajor & FailuresProblemsLow LevelAll Info	CBC Ciphers for old TLS	Process Target Domain extensions
Time to Live:	15 seconds30 secondsminute2 minutes3 minutes5 minutes10 minutes15 minutes30 minuteshour2 hours3 hours6 hours12 hoursday2 days3 daysweek10 days2 weeksmonth	Weak Ciphers	Accept SSLv2 'hello'
Oldest Accepted:	SSLv3TLSv1.0TLSv1.1TLSv1.2		Abort on Wrong Client Certificate

Log

Use this setting to specify what kind of information the TLS module should put in the Server Log. The TLS module records in the System Log are marked with the TLS tag.

Time To Live

This setting specifies the cache time for TLS sessions. When all connections using the same TLS session are closed, the Server waits for the specified time before deleting the TLS session parameters. This feature allows clients to open new connections resuming the old TLS sessions. It increases connection speeds and decreases the Server CPU load. This feature is especially important for HTTP clients that open and close connections very often.

Oldest Accepted

This setting specifies the oldest SSL/TLS protocol version accepted. If a remote peer specifies that it only supports an SSL/TLS version older than this one, an attempt to create a secure connection is rejected.
This option controls incoming TCP connections only.

Process Target Domain extensions

When this setting is enabled, the Server supports the TLS protocol extensions which allow the client to specify the name of the Server Domain it wants to access. This feature allows you to host several TLS-enabled Domains using the same Server Network IP Address.

CBC Ciphers for old TLS

Select this setting if you want to support CBC-based cipher methods for SSL 3.0 and TLS 1.0 protocols. The CBC-based cipher methods are always supported for datagram (DTLS) protocols.

Weak Ciphers

Select this setting if you want to support weak (less than 128-bit) security (cipher methods). The CBC Ciphers setting should be selected, too.

Accept SSLv2 'hello'

If this setting is enabled, the Server accepts SSLv2-style initial connection requests used by many older clients.
Note: even if this option is enabled, the actual security protocol used is SSLv3 or TLS, the SSLv2 security protocol is always disabled. There is no real reason to disable this option (other than to pass some bogus "security checks").

Abort on Wrong Client Certificate

When a Server requires a client to send a Certificate, the client may send an incorrect certificate: expired, issued by a wrong issuer, etc.
If this option is enabled, this situation aborts the current TLS negotiation process. If this option is disabled, then incorrect certificates are ignored.

The CommuniGate Pro Server can request a Client Certificate when an external client (a mailer, browser, or a real-time device) establishes a TLS connection with a certain Domain.

Use the WebAdmin Interface to open the Domain Settings page for the target Domain, and click the Security link. The PKI page will appear:

Request Client Certificates
Issued by:	Certificate Name 1Certificate Name 2Certificate Name 3	Required:	default(No)NoYes

Issued By

Select one of the Trusted Certificates specified for this Domain.
When a Trusted Certificate is selected, all TLS clients connecting to this Domain will be requested to present a valid certificate issued by the owner of the selected Trusted Certificate. These certificates can be used for Certificate Authentication.

Required

If this option is selected, only clients presenting valid Certificates can establish TLS connections to this Domain.

The CommuniGate Pro Server processes Client Certificate requests when it establishes a TLS connection to remote servers (SMTP, XMPP, SIP, POP, and other connections). It processes these requests by sending the TLS Certificate assigned to the Main Domain.

S/MIME is a PKI application used to digitally sign and encrypt E-mail and other messages. While TLS ensures data security when information is sent over an unprotected network, such as the Internet, S/MIME provides end-to-end data security: an S/MIME message is encrypted by the sender (using Multiparty Encryption) and submitted to the sender's server in the encrypted form. The same encrypted form is used when the message is transferred over a network, when it is stored on an intermediate server, and when it is deposited in the recipients' Mailboxes. Only the recipients can decrypt the message using their Private Keys, and only when they actually read the message: the message stays encrypted in the recipient's Mailboxes.

To use end-to-end S/MIME security, individual users should have their own PKI keys. Each user should have a Private Key securely stored in a storage available to that user only, and a matching Public Key embedded into a Certificate. This Certificate should be issued by a Certificate Authority that other users trust.

CommuniGate Pro WebUser and XIMSS Interfaces support S/MIME functions. The Server provides secure storage for user Private Keys. These Keys can be unlocked and used only by the users themselves, using these Interfaces.

To use a traditional desktop client application (a POP, IMAP, or MAPI client) the user Private Key should be stored in the PKI storage of the desktop operating system.
The WebUser and XIMSS Interfaces can export and import Private Keys, so the user can use the same Private Key for desktop applications and when employing these Interfaces. See the Secure Mail section for more details.

The CommuniGate Pro Server implements a Certificate Server, issuing Certificates for its users.

A CommuniGate Pro Domain can act as a Certificate Authority for all its Accounts if:

• The Domain PKI Functions are Enabled.
• The Domain has a valid Private Key.
• The Domain has a special S/MIME Certificate.

To specify Domain S/MIME settings, use the WebAdmin Interface to open the Domain Settings pages. Open the Security page and click the S/MIME link. If the Domain has a valid Private Key, a page similar to those for the generic Domain Certificate are displayed. These fields can be used to enter a special S/MIME certificate for the Domain. This Certificate is used as the Issuer (Certificate Authority) for all S/MIME Certificates requested by users in this Domain.

The S/MIME features can be used to provide secure message store. CommuniGate Pro can encrypt all or certain messages before it stores them in user Mailboxes.

The Store Encrypted Rule action is used to encrypt incoming E-mail messages and store them in the specified Mailbox.

Messages are encrypted using the S/MIME Certificate of the Mailbox owner. If the Store Encrypted Rule action is used in an Account-Level (i.e. in an Account or in a Domain-wide) Rule, and the specified Mailbox does not belong to the user Account, the message is encrypted using the Certificates of the Mailbox owner and the current Account.

Sample:

The Account john has a Rule with the following action:
Store Encrypted in    ~jim/INBOX
When this action is taken, the message is stored in the INBOX Mailbox of the Account jim encrypted with both john and jim Certificates. Both jim and john can decrypt and read this message.

After CommuniGate Pro users receive certain clear-text E-mail messages, they may prefer to keep them encrypted in the Server Mailboxes. The MAPI and XIMSS clients, and the WebUser Interface provide the Encrypt and Decrypt functions that allow users to encrypt and decrypt individual messages in their Mailboxes.

DKIM (stands for DomainKeys Identified Mail) is an E-mail authentication method which allows for a unique Signature to be added for each E-mail message you send. The Signature is generated by using encryption with public and private keys. The receiving mail server can use the public key to determine if your private key was used to generate the message's Signature, and that the message body and the most important headers were not altered during the transit.

To specify Domain DKIM settings, use the WebAdmin Interface to open the Domain Settings pages. Open the Security page and click the DKIM link.

To enable adding the Signatures to outgoing messages you need to complete the following steps:

1. Generate (or import externally-generated) Private Key in the same way as assigning a Private Key for the Domain.
   After the Private Key is assigned the corresponding Public Key will be displayed.

   Private Key
   Key Size:	1024 bit
   Encryption Test:	Verification String is OK

   
   

   Public Key

   MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDjLml46+DMPGpLpSQROFxyNnyFcyX9ZtscLo3YegyhB266JOYNzlfdPU4gBKWS89lnr2yVWC6dUgIVInJhin+stzROZ1MBd9dx6iOE4xAC2LxZeYvzjT07CoXzfdyb35N1TpSfL09ERXilNUgAoDqTAaJ+eGeN+N45LQTPtd0+QQIDAQAB

   
   
2. Specify the value for Domain - it should be either the current Domain name, or its "organizational domain" name.
3. Choose and specify the value for Selector - an arbitrary string.

DKIM Signature Parameters

Public Key
Domain:	mail.dept1.company.com
Selector:	mail



4. Create DNS TXT record for name Selector._domainkey.Domain with value "v=DKIM1; p=MIGfMA0GCSqG..." where the value of "p=" is your Public Key.
5. Use Check button to verify that the DNS record exists and contains the right Public Key. Remember that newly created DNS records may need time to propagate through the world.

DNS Record

feb2017._domainkey.company.com text = "v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDjLml46+DMPGpLpSQROFxyNnyFcyX9ZtscLo3YegyhB266JOYNzlfdPU4gBKWS89lnr2yVWC6dUgIVInJhin+stzROZ1MBd9dx6iOE4xAC2LxZeYvzjT07CoXzfdyb35N1TpSfL09ERXilNUgAoDqTAaJ+eGeN+N45LQTPtd0+QQIDAQAB"



6. After all the above steps are complete switch the Enabled to Yes

Sign Outgoing Messages

Enabled: NoYes

It is recommended to rotate the Private Key regularly (about every 3 months), by generating new Keys and creating new DNS record for a new Selector.

Note:The DKIM Signatures are composed by Enqueuer component when the message is enqueued, but physically added when the message is sent, stored or sent to an external program.

Note: For the DKIM signing process the relation of a message to a Domain is determined by the message's From: address. A user whose Account is in some other Domain may change his From: address so his messages will be signed according to the current Domain settings. Also, messages being relayed from external sources may be signed by the current Domain if their From: addresses match the names of the objects in the current Domain.