|
Version 6.3 |
|
| |||||||||||||||||||||||||||||||
PKI Terminology
Domain PKI SettingsEach 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: This option allows you to specify the PKI Mode for this Domain:
Assigning a Private KeyInitially 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. 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).
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: 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 CertificateA 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.
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:
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: 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: 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.
Click the Remove Certificate button to remove the Domain Certificate. Assigning a Certificate Authority ChainIf 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: 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: 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. Using Self-Signed CertificatesYou can create a Self-Signed Certificate if you do not want to use any external
Certificate Authority.
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. Trusted Root CertificatesThe 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:
There are several sets of the 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:
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:
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: 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).
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. SSL/TLS Secure ConnectionsThe 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:
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:
Client CertificatesThe 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:
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 FunctionalityS/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.
Domain S/MIME SettingsThe 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:
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. Automatic S/MIME EncryptionThe 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.
Stored Message EncryptionAfter 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 Message SigningDKIM (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:
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. |