Domain encryption and S/MIME: Not all certificates are created equal
Encrypting emails is the best way to protect your company’s communications and keep sensitive data from being illegally accessed. Many companies have understood this and therefore use encryption solutions. But compliance-based requirements and legal requirements such as the General Data Protection Regulation (GDPR) also contribute to the spread of email encryption solutions: Since 25 May 2018, the GDPR obliges companies encrypt emails that contain personal data and to perform transport encryption.
When encrypting content such as personal data, S/MIME is usually used, one of the two standards for email encryption. S/MIME is based on the use of so-called X.509 certificates and is now natively supported by all major email programmes. S/MIME-based encryption offers secure and effective encryption of emails if appropriate certificates are used.
Those who use S/MIME want to encrypt all emails sent and received via the corporate domain with as little effort as possible. This article explains what you need to consider when using S/MIME in your company and why not all providers offer the right certificates.
How does S/MIME encryption work?
S/MIME is short for Secure/Multipurpose Internet Mail Extension and is a standard for encrypting and digitally signing emails. In S/MIME, email encryption is based on the use of public and private keys. The sender must be in possession of both his private and public keys.
The use of public and private keys is similar to the use of a padlock and the corresponding key. The recipient makes his lock available to all communication partners – namely the public key with which the emails are then encrypted.
Where can I get an S/MIME certificate?
A certificate according to the X.509 standard is needed to create the two keys. To do this, the user first creates both a private and a public key him or herself. The public key is transferred to the certificate authority (CA) and signed by it. In this way, the CA confirms the correctness of the characteristics specified in the certificate request, such as the email address or the first and last name of the applicant.
With S/MIME, the credibility of a public key is therefore based on a hierarchical certificate system. The so-called certificate chain then extends from the individual user certificate via any intermediate certificates to the root certificate of the certification authority.
The certification of the public keys by the certification authority is subject to a fee, but offers the certainty that it is a trustworthy certificate. This in turn is the prerequisite for the respective certificate to be accepted by the recipient side and the email to be delivered.
Domain encryption with S/MIME certificates
The company-wide use of user- or person-based S/MIME encryption is simple, but nevertheless some companies fear the effort involved. Perhaps they also fear that individual employees will be forced to invest a lot of time in encrypting emails: Users’ private and public keys have to be managed, secured and protected. The public keys must also be distributed. Moreover, the users have to be trained.
For this reason, some providers offer their own proprietary domain encryption: Here, the entire email domain within an organisation is to be secured with the help of a single public key. What’s more, communication between different companies is also to be encrypted automatically, without the need to exchange public keys. In order for domain encryption to be used in this way, an encryption gateway must then be used that takes over the processing of the certificates.
Of course, it sounds tempting to use just one domain certificate instead of hundreds of user or personal certificates. However, these proprietary domain certificates bring with them numerous problems and dangers.
Why proprietary domain encryption is a bad idea
No security without trust
The basis of all certificates used with S/MIME is trust. This trust is created because the root certificate is issued by a recognised certification authority. Provider-owned domain certificates, however, are created by the provider’s own certificate authority, which is not affiliated with any recognised trust centre and therefore does not enjoy trust outside the provider’s infrastructure.
Bypassing standards is dangerous
Providers who create their own certificates may not adhere to proven secure standards. The S/MIME standard is based on open-source algorithms that can be reproduced at any time. If one deviates from this standard, there is always the danger that the encryption is less effective and the provider inadvertently introduces vulnerabilities – or even intentionally.
Where do things happen?
It is also often unclear where the keys are created: Does this happen with the help of the appliance at the user’s premises or by the provider using the respective email address? In the latter case, the private key would still have to be transmitted to the user, so that the provider potentially has access to the private key, which is a major security risk.
Domain certificates are not always accepted
A general problem with domain certificates – even non-proprietary ones – is the fact that email programs compare the email address in the certificate with the sender’s address during validation. However, since the certificate was issued for a central email address assigned to the domain, the validation of the certificate and often also that of the signature fails.
If the communicating email systems do not both use the same provider, the encryption may not work or emails cannot be delivered. Customers and other communication partners must then configure exceptions in their spam filters to prevent communication from breaking down.
Open solutions offer better protection
When using proprietary certificates, compliance with a generally accepted minimum security policy would be a big step towards more security. However, very few providers of proprietary certificates are willing to do this. However, effective protection and secure encryption can be achieved even better and more easily with existing, open solutions:
Transport Layer Security (TLS)
TLS secures the transmission paths between the communicating email servers. Emails sent via TLS-secured connections are encrypted and protected from unauthorised access. TLS-based encryption is also part of the Hypertext Transfer Protocol Secure (HTTPS) and is used by current browsers in version 1.3 or 1.2.
It is important to note that TLS in version 1.2 will soon be mandatory for many internet users. The German Federal Office for Information Security (BSI) has also made TLS 1.2 the minimum standard.
Since TLS only affects the transport side and does not provide content encryption, TLS also only provides additional security for email communication. S/MIME cannot be replaced by TLS, but is ideal for parallel use. Enforcing TLS encryption with the help of an email gateway is an easy way to effectively protect your emails in transit.
S/MIME and Open Keys: Security meets simplicity
For content encryption of data transmitted by email, S/MIME remains the measure of all things. It is not for nothing that S/MIME has become the standard for email encryption, because it offers effective protection and is based on recognised standards. Currently, S/MIME is available in version 4.0, which is specified in RFC 8551.
In combination with the public key server Open Keys, S/MIME is not only secure, but also particularly easy to implement. Open Keys makes the public keys available to anyone and everyone and only queries trustworthy trust centres. Open Keys thus offers a major advantage over proprietary solutions, because S/MIME-based encryption can thus be used not only between provider-owned appliances.
Open Keys is also integrated into secure email gateways such as NoSpamProxy, so that available certificates are automatically retrieved and your own are made available. S/MIME encryption could not be simpler.
Email encryption with NoSpamProxy Encryption – Get your free trial now
Encrypting emails is secure and easy with NoSpamProxy Encryption! Ensure legally compliant and DSGVO-compliant email communication now. Request your trial version now!
