Certificate Manager

Certificate Manager
The Certificate Manager is used to create, import and manage SSL/TLS X.509 certificates. 

You can reach this manager from Options | Certificates or through the Certificate Manager button on the SSL Certificate tab of the Service properties dialog.

Certificates are used to secure communication between client computers and the services installed on your system. 

Certificates provide two functions :-

Authentication (prove that the site is who the client thinks it is)

Encryption (prevent third parties from observing the communication, including the transmission of passwords)

Most email clients and web browsers are capable of accepting certificates and using them for secure communication.  

PCI Compliance
Mailtraq supports the highest level of security to allow direct HTTPS connection to credit card services, such as Visa, MasterCard and American Express, and to provide HIPAA medical record confidentiality compliance.

Security Options are available on the HTTPS Service to require SSL3 or TLS, and to require strong encryption. The "Require Strong Encryption" option rejects connections from older less secure browsers, only accepts 128bit or 256bit keys and disables anonymous encryption.  This makes Mailtraq's web server more secure than IIS.

More about PCI Compliance here... and PCI Compliance testing here... & here...

Secure web services
Mailtraq provides secure HTTPS web services. Read more here...

Wildcard certificates
Mailtraq supports wildcard certificates from build 2.17.0.3120 and above.
Some email clients (e.g. K9 for Android, Thunderbird) may not to trust wildcard certificates without additional confirmation from the user. Outlook generally accepts them.

Certificates

What is in a Certificate?

Certificates contain just a few items: a Subject (identifying the web site), an Issuer (identifying who issued the certificate), a public key (used for public-key cryptography) and the encryption parameters (used to secure the channel).Web Browsers have a list of issuers that the user trusts.  These issuers (Certificate Authorities) sign the certificate indicating that they believe the subject to be authentic.  Thus, if the user trusts the issuer, they implicitly trust the subject.  For this reason, certificates should always be signed by issuers who the user is likely to trust.  For most users, this means one of the large Certificate Authorities.

You can issue a self-signed certificate, indicating that there is no issuer, which means the user must explicitly choose to trust your certificate.  In such cases, a warning dialog is usually displayed to the user.  Not all web browsers can use self-signed certificates.

Creating a Self-Signed Certificate

You can create a Self-Signed certificate easily by clicking on New Certificate and choosing the Self-Signed option.  The default cryptography parameters are recommended.

Creating a Regular Certificate

Creating a CA-Signed certificate is more complex.  To do this, you must create a Certificate Signing Request which you then give to the Certificate Authority for them to authenticate and sign.  What they return is the completed certificate.

To do this, simply contact a Certificate Authority and request a new certificate.  They will typically ask for a Certificate Signing Request (CSR, or PKCS#10 certificate).  Normally they can accept a Base64 encoded CSR.  To get this, click on New Certificate and follow the steps.  A CSR will be displayed in Base64 which you can copy and paste.  The Certificate Authority will then begin the process which typically involves contacting you to verify the credentials.  Once complete, they will provide somewhere (typically on the web site) where you can download the completed certificate.  You can then use the Import button to install it in the system.