Description

With MailSealer you can sign and encrypt e-mails for sending.
You can choose between different methods, which are divided into 3 product groups.

With S/MIME, MailSealer encrypts and signs according to S/MIME on the basis of X509v3 certificates or key pairs (asymmetric):

  • S/MIME certificates (X.509v.3) are usually personal and are issued by a trustworthy certification authority (e.g. VeriSign, CaCert etc.).
  • S/MIME "gateway certificates" can also be used, here only one certificate per domain must be acquired and managed.
    This is the enforced use of a certificate independent of the respective sender.
    This functionality is only necessary or recommended for certain procedures.
    Therefore, "gateway certificates" should only be used if the communication partners can also process this, as otherwise the signature of the e-mails, for example, will be classified as invalid by receiving systems.
  • Via the self-signed root CA certificate of the REDDOXX Appliance (Private Certificate Authority), certificates can also be created automatically for the users; the e-mail partner must import this certificate into its certificate store for authorities (Certificate Authorities).
  • S/Mime certificates are checked for validity when they are added manually or automatically or when they are used.
  • The OCSP status is checked hourly, the CRL is checked every 8 hours.

The e-mail signature is used to check whether an e-mail was transmitted unchanged on its way from the sender to the recipient and whether the e-mail actually originates from the sender.

For e-mail signing, a valid private certificate of the sender and the corresponding valid certificate chain (intermediate / root certificate of the certificate issuer) are required.
The certificate requires the function: Digital signature as the purpose of use (key usage).
When signing an e-mail, a hash value (checksum) of the e-mail document is created and encrypted with the help of the sender's private key.
The signed e-mail then contains the encrypted check value, the original document and the sender's Public Key.

For e-mail signature verification, the sender's public key and the corresponding valid certificate chain (intermediate / root certificate of the certificate issuer) are required.
The receiving system can then use the sender's public key to check whether the hash value of the e-mail determined with it matches the hash value transmitted.
If this is the case, the e-mail was not manipulated during transmission.

For e-mail encryption using S/MIME, the private certificate of the sender, the public certificate of the recipient and the corresponding valid certificate chains (intermediate / root certificates of the certificate issuers) are required.
The private certificate requires the function: digital signature and key encipherment as the purpose of use (key usage).

For e-mail decryption using S/MIME, the private certificate of the recipient, the public certificate of the sender and the corresponding valid certificate chains (intermediate / root certificates of the certificate issuers) are required.

Similar to S/MIME, PGP uses private and public key pairs for encryption and signing.
Since, in contrast to S/MIME, no intermediate and root certification authorities are necessary, the keys of the sender can be created automatically in the REDDOXX Appliance.
The public keys of the communication partners can also be collected automatically by the REDDOXX Appliance as with S/MIME.

The e-mail signature serves to check whether an e-mail was transmitted unchanged on its way from the sender to the recipient and whether the e-mail actually originates from the sender.

E-mail signing requires a valid private certificate from the sender.
During e-mail signing, a hash value (checksum) of the e-mail document is created and encrypted with the help of the sender's private key.
The signed e-mail then contains the encrypted check value, the original document and the sender's public key.

For e-mail signature verification, the sender's Public Key is required.
The receiving system can then use the sender's public key to check whether the hash value of the e-mail determined with it matches the hash value transmitted.
If this is the case, the e-mail was not manipulated during transmission.

For e-mail encryption using PGP, the private certificate of the sender and the public certificate of the recipient are required.
In contrast to S/MIME, a random key is first created to encrypt the data (symmetric encryption).
Then the random key is encrypted with the recipient's public key (asymmetric encryption) and the data is encrypted with this encrypted key.

For e-mail decryption using PGP, the private certificate of the recipient and the public certificate of the sender are required.

E-mail encryption via REDDCRYPT can also be carried out directly via the appliance.
In gateway mode, the appliance establishes a secure connection via API to our REDDCRYPT portal.
Similar to PGP, users and associated keys can then be created automatically.
In addition, e-mails can be encrypted with a defined or randomly generated one-time key to users who can then decrypt these e-mails in the web portal and also reply to them without a REDDCRYPT account.