Admins enjoy more Secure Mobile Access to Email Archives using TLS Encryption

Now more than ever, administrators in both small and medium-sized businesses face the challenge of giving their users access to their services and data at any time, and from anywhere. While VPNs used to be the method of choice to manage this despite their complexity, ensuring universal access has developed into a much more complex task for administrators due to the acceptance of smartphones and the resulting ‘Bring Your Own Device’ (BYOD) trend. At the same time, even more solutions offer suitable Web-based access, which entails the advantages of platform independence on the client side as well as lower requirements for administrators in providing the service.

More secure and user-friendly Web-based access

Two main points should be considered in making Web-based access secure and user-friendly:

1. Access must be encrypted.
2. Clients and/or Web browsers must trust the certificates used

Current Web browsers flag websites as insecure whenever they transmit passwords or credit card details unencrypted. It should be assumed that this type of flagging will extend to all unencrypted websites in the future to always protect transmitted data from the prying eyes of third parties. At present, the unencrypted transmission of data in public wireless networks poses an enormous risk that can only be countered with encryption enforced server-side.

Certificates for TLS encryption

Administrators should therefore turn to TLS encryption, and secure their services with certificates accordingly. As the self-signed certificates which are often created during installation or certificates signed by an internal Certificate Authority (CA) are not readily trusted, you should avoid production use. Instead, we recommend having certificates signed by official Certificate Authorities (CA). These types of signed certificates are automatically trusted based on information stored in browsers and operating systems.

In principle, the general procedure for this does not depend on the services used, and is carried out as follows:

1. A private and a public key are generated. Then, a Certificate Signing Request (CSR) is created, which contains the details of the certificate to be applied for. The public key is part of the CSR.
2. The CSR is then transmitted to the Certificate Authority (CA). This usually happens via the CA’s websites.
3. These then generate the certificate from the CSR (if necessary, after validation in the form of additional documents or telephone calls), which is signed and then sent back to you as a signed certificate.

The certificate signed by the CA can now be made available for one service, or, if required, for multiple services. Integration is product-specific.

Wildcard certificates for domains

Alongside individual certificates for one service or server, there are also ‘wildcard certificates’ for entire domains, which are then valid for the domains themselves (e.g., example.com) and all existing host names included in them (*.example.com). These are primarily advantageous if an admin wishes to secure a large number of services under different host names. There’s just one downside to them: If one of the servers with a wildcard certificate is compromised, then the wildcard certificate must be revoked and replaced on every server. When individual certificates are used, this only needs to be carried out for the server affected.

MailStore opts for encrypted communication

Within Version 10.2 of the MailStore Server and the MailStore Service Provider Edition, we have begun to gradually adapt services made available by our products. In the future, we will only enable encrypted communication. This way, new responsive Web Access will only be made available via an encrypted HTTPS connection, for example. MailStore Server users will also get a notification if they attempt to access Web Access unencrypted via HTTP. However, unencrypted access was also not possible in the Service Provider Edition in the past.

We will explain how to replace the self-signed certificate created in both products during installation with your own, trustworthy one in the following articles about MailStore Server (https://help.mailstore.com/en/server/Using_Your_Own_SSL_Certificate) and the MailStore Service Provider Edition (https://help.mailstore.com/en/spe/Replace_Self-signed_SSL_Certificates and https://help.mailstore.com/en/spe/Working_with_SSL_Certificates).