Incoming encrypted email is not decrypted. Why is that?

Make sure that domain for which you receive email have been marked as an internal domain. If not, the gateway tries to encrypt the message instead of decrypting it because it thinks the messages is sent to an external user. If the domain is configured as an internal domain, check whether the gateway has access to the correct private key. Check the gateway specific headers to see which certificates or PGP keys the email was encrypted with (see Email received by the gateway contain X-Djigzo-Info headers. What are these?)

Email received by the gateway contain X-Djigzo-Info headers. What are these?

When an incoming email is handled by the gateway, special headers about the security properties of the email are automatically added to the email. For example, if an encrypted message was decrypted by the gateway, relevant information about the encryption algorithm and recipients are added to the headers.

The following CipherMail gateway specific headers are supported:

X-Djigzo-Info-Signer-ID-…
X-Djigzo-Info-Signer-Verified-…
X-Djigzo-Info-Signer-Trusted-…
X-Djigzo-Info-Signer-Trusted-Info-…
X-Djigzo-Info-Encryption-Algorithm-…
X-Djigzo-Info-Encryption-Recipient-…
X-Djigzo-Info-PGP-Encoding
X-Djigzo-Info-PGP-Encrypted
X-Djigzo-Info-PGP-Encryption-Algorithm
X-Djigzo-Info-PGP-Signed
X-Djigzo-Info-PGP-Signer-KeyID
X-Djigzo-Info-PGP-Signature-Valid
X-Djigzo-Info-PGP-Signature-Failure

Where ... is replaced by an index and level as explained below.

[INDEX-]LEVEL

INDEX and LEVEL are integer numbers starting at 0. INDEX is optional for some headers.

Example:

X-Djigzo-Info-Signer-ID-0-0

LEVEL denotes the S/MIME level the values applies to. An S/MIME message supports multiple nested levels of protection (CMS layers). For example, a message can first be signed and then encrypted. LEVEL 0 is the first level found by the S/MIME handler. Multiple items can exist within one level. For example, a message can be encrypted for multiple recipients. INDEX is the index of an item within a level.

Example Headers:

X-Djigzo-Info-Encryption-Algorithm-0: AES128, Key size: 128

X-Djigzo-Info-Encryption-Recipient-0-0:
   CN=Thawte Personal Freemail Issuing CA, O=Thawte Consulting (Pty) Ltd.,
   C=ZA/6B55D312FF5F9D5DAD9866FF827FFEB5//1.2.840.113549.1.1.1

X-Djigzo-Info-Encryption-Recipient-1-0:
   EMAILADDRESS=support@cacert.org, CN=CA Cert Signing Authority,
   OU=http://www.cacert.org, O=Root CA/6683C//1.2.840.113549.1.1.1

X-Djigzo-Info-Signer-ID-0-1: CN=UTN-USERFirst-Client Authentication and Email,
    OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City,
    ST=UT, C=US/88F9874A02A53042E0228D78CBD55795/

X-Djigzo-Info-Signer-Verified-0-1: True

X-Djigzo-Info-Signer-Trusted-0-1: True

The above example headers show that the message was first signed and then encrypted. The encryption algorithm was AES128. The message was encrypted with two certificates:

X-Djigzo-Info-Encryption-Recipient-0-0
X-Djigzo-Info-Encryption-Recipient-1-0

One certificate was issued by Thawte and the other was issued by CACert. The message was signed by one signer with a certificate issued by Usertrust.

X-Djigzo-Info-Signer-Verified

This headers shows whether the message content was signed and that the message was not been changed after signing.

X-Djigzo-Info-Signer-Trusted

This headers shows whether the signing certificate was trusted (signed by root etc.) by the gateway. If the signing certificate was not trusted, the reason for not trusting the certificate is given in the X-Djigzo-Info-Signer-Trusted header.

Note

When email is received by the gateway, all existing X-Djigzo-* headers will be removed before handling the email to make sure that an external sender cannot fake any gateway specific headers.

The PGP specific headers (X-Djigzo-Info-PGP) are similar to the S/MIME specfic headers but now for PGP.

The certificates from incoming digitally signed email are not stored in the certificates store?

Make sure the domain for which you receive email is marked as an internal domain. If not, the gateway does not extract the certificates from the digitally signed email.

What is the difference between the gateway back-end Web GUI?

The gateway back-end is responsible for all handling of email like encryption/decryption etc. All “business logic” is handled by the back-end. The Web GUI (front-end) is only a web interface to control the back-end. The front-end commmunicates with SOAP to the back-end. It is therefore possible to install the back-end and front-end on a separate server.

If I try to login immediately after starting the gateway I get an exception. Why is that?

The back-end and front-end are started separately. Starting and initializing the two processes takes some time. If the front-end startup process is finished before the back-end is functional logging into the front-end might result in a temporary error. Try to login after the back-end finished starting up.

Is it possible to authenticate the admin against LDAP or Active directory?

Yes this is possible with the Enterprise Edition. Please contact us for details.

Where should the CipherMail gateway be placed?

The CipherMail gateway is typically installed as an SMTP gateway. There are multiple ways the gateway can be placed within the existing infrastructure. For typical network setups see Network architecture.

Is the gateway an on-premises or a cloud based application?

That is up to you. The gateway is under your control. You can install it on-premises, in a private cloud or in the public cloud. You can manage it yourself or you can have it managed by someone else.

Can the gateway be used as a milter?

The gateway can be configured to provide a decryption only milter interface. For email encryption, the gateway cannot be used as a milter because a milter only supports “one message in, one message out”. If for example an email is sent to two recipients and one recipient only supports S/MIME and the other only supports PGP, the gateway will sent two emails, one S/MIME encrypted and the other PGP encrypted. This is not possible with a milter.

For decrypting email however a milter interface is avilable. This can be helpful if there is a requirement to scan encrypted email for spam or virusses before accepting the email. If an email is encrypted, the email cannot be scanned for spam or virusses. With an after queue filter, the gateway has to accept the email before the contents can be scanned because it has to be decrypted first. If the decrypted email then is flagged as spam, the gateway can no longer reject the email. The email can also not be bounced because that would result in “back scatter” email. By using the decryption milter, email can be decrypted and scanned before postfix accepts.

Does the gateway support Let’s Encrypt?

Yes. The Pro/Enterprise edition contains a Let’s Encrypt module with which you can request, configure and renew a proper TLS certificate for the Web GUI and SMTP server.