Admins Are Enjoying Safer Mobile Access to Email Archives with TLS Encryption
Managers in both small and medium-sized businesses are facing greater challenges than ever before in ensuring their users can access services and data anytime, anywhere. While VPNs remain the preferred method for managing this, despite their complexities, providing universal access, the acceptance of smartphones, and the resulting Bring Your Own Device (BYOD) trend have made this task far more complicated for managers. Additionally, more solutions now offer the advantages of client-side platform independence as well as suitable web-based access that requires fewer requirements for managers in service delivery.
More Secure and User-Friendly Web-Based Access
When making web-based access more secure and user-friendly, two main points should be considered:
- Access should be encrypted.
- Clients and/or web browsers should trust certificates.
Current web browsers mark websites as insecure when they transmit passwords or credit card information unencrypted. It should be assumed that such labeling will in the future cover all unencrypted websites to protect transmitted data from prying eyes. At present, unencrypted data transmission over public wireless networks poses a very significant risk that can only be addressed by servers applying encryption.
Therefore, administrators should move towards TLS encryption and secure their services with certificates. In general, it is advisable to avoid using automatically signed certificates generated during installation or those signed by an internal Certificate Authority (CA) for production use. Instead, we recommend that certificates be signed by official Certificate Authorities (CAs). Such signed certificates are automatically trusted based on information stored in browsers and operating systems.
In principle, the general procedure for this is not dependent on the service used and can be implemented as follows:
- A private and a public key are created. Then, a Certificate Signing Request (CSR) containing the details of the certificate to be requested is created. The public key is part of the CSR.
- The CSR is then sent to a Certificate Authority (CA), which usually happens via the CA's website.
- These will then create the certificate from the CSR (after possible verification through additional documents or phone calls), sign it, and send it back to you as a signed certificate.
A certificate signed by the CA can then be used for a single service or, if required, for multiple services. This depends on the integration product.
Wildcard Certificates for Domains
In addition to separate certificates for a service or server, there are also "wildcard certificates" that apply to all domain names. These are valid for the domain name itself (e.g., example.com) and all existing subdomain names (*.example.com). These are particularly advantageous when a manager wants to secure many services under different subdomain names. The only drawback is that if the security of a server with a wildcard certificate is breached, the wildcard certificate must be revoked and replaced on all servers. In contrast, when individual certificates are used, this process needs to be carried out only for the affected server.
MailStore Prefers Encrypted Communication
In version 10.2 of the MailStore Server and the Service Provider Version, we started gradually adapting the services offered by our products. In the future, we will only activate encrypted communication. This way, new sensitive Web Access will only be available via an encrypted HTTPS connection. MailStore Server users will also receive a notification if they attempt to access unencrypted Web Access via HTTP. However, in the past, unencrypted access was also not possible in the Service Provider Version.
Source: Secure Mobile Access to Email Archives Using TLS Encryption (mailstore.com)