Initial situation:

The signature of an incoming, signed email was found to be valid by the SEPPmail Secure E-Mail Gateway. The corresponding mark (by default [signed OK]) is present in the subject line of the email.

The SEPPmail Secure E-Mail Gateway is configured in such a way that successfully checked signatures are not removed.

In the receiving email client, only the signature is displayed as invalid, however.

If the signature is checked in detail, the notification indicates

 

a) that the email was changed.

 

Cause:

1.The email was changed between the SEPPmail Secure E-Mail Gateway and the email client by an unauthorised third party.
With a correct configuration of the systems, the path from the SEPPmail Secure E-Mail Gateway to the email client is encrypted and this option is thus excluded.

 

2.The email was changed by an intermediate relay (e.g. a line break or similar) en route between the SEPPmail Secure E-Mail Gateway and the email client.
 
Individual remedy:
In this case, the intermediate relays are to be checked.
 

3.When signing the email, the sender used the padding procedure RSA-PSS, but the email client cannot handle this procedure.
RSA-PSS is required by EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport), for instance. Since the SEPPmail Secure E-Mail Gateway is capable of handling this standard, the signature is recognised as valid here. However, since most email clients cannot handle RSA-PSS, these will identify the signature as invalid.
 
Individual remedy:
Successfully checked signatures should be removed by the SEPPmail Secure E-Mail Gateway (see Mail Processing Ruleset generator Signing Incoming e-mails Remove signature if S/MIME signature check succeeds).
 

 

b) the certificate originates from an unknown certification authority

 

Cause:

4.The issuing CA is present on the SEPPmail Secure E-Mail Gateway under "X.509 Root Certificates" and classified as "trusted".
In the email client, the same CA is unknown or classified as "untrusted".
 

5.The signature was not created in a RFC-compliant manner by the sender. The necessary intermediate certificates are missing.
The missing intermediate certificates are known on the SEPPmail Secure E-Mail Gateway, which is why the certificate chain can be traced back and the origin of the certificate can still be determined.
The intermediate certificates are not known at the email client. The certificate chain is thus not known there. The origin of the certificate can thus not be determined.
 
Individual remedy:
Intermediate certificates are to be imported in a decentralised manner in the email clients.
 

c) the sender of the email does not correspond to the applicant of the certificate in the signature.

 

Cause:

For verifying the sender of an email, the SEPPmail Secure E-Mail Gateway checks both the FROM as well as the SENDER header for compliance with the applicant of the certificate.

The email client used checks the compliance of the sender with the applicant of the certificate based on other criteria.

Individual remedy:

Successfully checked signatures should be removed by the SEPPmail Secure E-Mail Gateway (Remove signature if S/MIME signature check succeeds).

 

General remedy:

In this SEPPmail Secure E-Mail Gateway configuration, successfully checked signatures should be removed (see Mail Processing Ruleset generator Signing Incoming e-mails Remove signature if S/MIME signature check succeeds).