Incoming encrypted email is not decrypted. Why is that?
Confirm that the recipient domain is configured as an internal domain. If it is not, the gateway treats the message as external and will try to encrypt it instead of decrypting it. If the domain is correctly marked as internal, verify that the gateway has access to the appropriate private key for decryption. To identify which certificate or PGP key was used to encrypt the message, check the gateway-specific email headers (see Email received by the gateway contain X-CipherMail-Info headers. What are these?)
Email received by the gateway contain X-CipherMail-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.
When necessary, CipherMail automatically adds the following S/MIME‑specific email headers:
X-CipherMail-Info-Signer-ID-…
X-CipherMail-Info-Signer-Email-…
X-CipherMail-Info-Signer-Verified-…
X-CipherMail-Info-Signer-Verification-Info-…
X-CipherMail-Info-Signer-Trusted-…
X-CipherMail-Info-Signer-Trusted-Info-…
X-CipherMail-Info-Signer-Mismatch
X-CipherMail-Info-Encryption-Algorithm-…
X-CipherMail-Info-Encryption-Recipient-…
X-CipherMail-Info-SMIME-Encrypted
X-CipherMail-Info-SMIME-Signed
X-CipherMail-Info-SMIME-Decryption-Key-Not-Found
X-CipherMail-Info-SMIME-Illegal-Chars-Found
When necessary, CipherMail automatically adds the following PGP‑specific email headers:
X-CipherMail-Info-PGP-Encoding
X-CipherMail-Info-PGP-Signed
X-CipherMail-Info-PGP-Signer-KeyID
X-CipherMail-Info-PGP-Signature-Valid
X-CipherMail-Info-PGP-Signature-Failure
X-CipherMail-Info-PGP-Encrypted
X-CipherMail-Info-PGP-Encryption-Algorithm
X-CipherMail-Info-PGP-Decryption-Key-Not-Found
X-CipherMail-Info-PGP-Signer-Mismatch
X-CipherMail-Info-PGP-Signer-Email
X-CipherMail-Info-PGP-Mixed-Content
Where the placeholder ... is replaced with the appropriate index and level, as described below.
[INDEX-]LEVEL
INDEX and LEVEL are integer values that start at 0. For certain headers, the INDEX value is optional.
Example:
X-CipherMail-Info-Signer-ID-0-0
LEVEL indicates the protection layer within an S/MIME message. S/MIME can apply multiple, nested layers of protection (also called CMS layers). For example, a message might be signed first and then encrypted. LEVEL 0 refers to the first layer detected by the S/MIME handler. A single layer can contain multiple items; for instance, an encrypted message can include multiple recipients. INDEX identifies the position of a specific item within its layer.
Note
For security, the gateway removes any X-CipherMail-* headers from incoming
emails before processing them. This prevents external senders from spoofing
gateway-specific headers.
Certificates from incoming digitally signed emails are not automatically saved to the certificate store
Confirm that the domain where you receive email is configured as an internal domain. If it is not, the gateway will not extract certificates from digitally signed emails.
Where should the CipherMail gateway be placed?
CipherMail Gateway is usually deployed as an SMTP relay. You can position it in several ways within your existing mail infrastructure. For examples of common network layouts, see Network architecture.
Is the gateway an on-premises or a cloud based application?
You have full control over where and how to deploy the gateway. You can install it on-premises, in a private cloud, or in the public cloud. You may manage it yourself or delegate management to a third party.
Can the gateway be used as a milter?
The gateway can be configured to provide a decryption‑only milter interface.
For outbound encryption, the gateway cannot operate as a milter because a milter enforces a “one message in, one message out” model. If a single email is addressed to multiple recipients who require different encryption methods (for example, one S/MIME and one PGP), the gateway must produce two separate encrypted messages. This fan‑out is not possible within the constraints of a milter.
For inbound decryption, however, a milter interface is available. This is useful when you need to scan encrypted email for spam or viruses before accepting it. Encrypted messages cannot be scanned until they are decrypted. With an after‑queue filter, the gateway must accept the message first in order to decrypt it, which means it cannot later reject the message if it is flagged as spam; bouncing it would also risk generating backscatter. By using the decryption milter, the gateway can decrypt and scan messages before Postfix accepts them, allowing safe rejection without backscatter.
Does the gateway support Let’s Encrypt?
The gateway includes built-in Let’s Encrypt integration that automatically obtains, configures, and renews valid TLS certificates for the Web UI and the SMTP server.
Why is it not possible to create a backup from the UI?
Creating a backup from the user interface bypasses the standard permission model. The backup includes the entire database, including all settings and keys.
Why is it not possible to restore a backup from the UI?
Restoring backups from the web interface can unintentionally grant higher system privileges than intended. Back-end administrators do not have Unix-level accounts, but the backups include system files and database dumps. To avoid security risks, restore backups using the approved server-side procedure.
How can I upgrade from version 5 to version 6?
CipherMail Gateway version 6 is a major redesign. Existing databases from earlier versions cannot be imported into version 6. You can, however, export all certificates and PGP keys from your current gateway to a file and then import that file into the new gateway. If you have a paid support contract and need assistance upgrading to version 6, please contact us.
A security scanner reports that the gateway uses SHA-1 for the TLS key exchange. Why?
The hash functions the gateway uses to sign a TLS key exchange are set by the system-wide crypto policy of Alma Linux.
The DEFAULT policy does not allow SHA-1. Some cloud images of Alma Linux 9, for example the image of DigitalOcean,
use the LEGACY policy instead. With LEGACY, the web UIs, Postfix and Cockpit sign a TLS 1.2 key exchange with
SHA-1 for a client which asks for it, and security scanners such as internet.nl report this.
Check which crypto policy is in use:
update-crypto-policies --show
If it shows LEGACY, first check the TLS certificate of the gateway. The web UIs, Postfix and Cockpit use the same
certificate. The following command lists the certificate and the intermediate certificates of its chain:
sudo openssl storeutl -noout -text -certs /etc/pki/tls/private/ciphermail.tls.pem | grep -E 'Subject:|Signature Algorithm'
DEFAULT refuses a certificate, intermediate certificates included, which is signed with SHA-1
(sha1WithRSAEncryption or ecdsa-with-SHA1). Replace such a certificate first, otherwise the web UIs do not
start and Postfix accepts email without TLS after the switch.
Then switch to DEFAULT and reboot:
sudo update-crypto-policies --set DEFAULT
sudo reboot
DEFAULT also refuses SSH clients which only support ssh-rsa signatures with SHA-1. Any recent SSH client works;
if you cannot log in after the reboot, use the console of your cloud provider.
The crypto policy applies to the TLS connections the gateway makes as well. A server which only supports SHA-1 signatures, for example a partner mail server or an LDAP server with an old certificate, can then no longer be reached over TLS.
Note
If the system must keep the LEGACY policy, you can limit the signature algorithms of the web UIs to SHA-256
and stronger with the Ansible variable ciphermail_ui__ssl_signature_algorithms. Add it to the Ansible override
file /etc/ciphermail/ansible/group_vars/all/override.yml:
ciphermail_ui__ssl_signature_algorithms: 'ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512'
Then run the playbook:
sudo cm-run-playbook
This does not change the other services, such as Postfix and Cockpit.