Zitat von Martijn Brinkers <[email protected]>:
On 10/08/2013 05:57 PM, [email protected] wrote:Hello, today we had a problem that one customer send us encrypted mail with a certificate/key pair which was already expired. Therefore the encrypted data passed the Djigzo gateway to the clients not able to handle it. As the certificate/key pair is still present it would be nice to get the mail decrypted without manually whitelist the certificate/key pair. Thinking about it, this also might be a side effect of using strict-mode, no?I'm 99.9% certain that this is a side-effect of strict-mode. In strict mode, a check is done to see whether the key belongs to the user and is valid. If the key expired, than the key is no longer valid for the user and therefore the message is not decrypted for the user. I'll need to check this to be 100% certain.Is this intended or even useful behaviour and the only fix to add it to the CTL with expired allowed?Good question whether this is expected behaviour or not. I'm not sure whether it is easy to add an "allow expired" cert just for strict mode. Let me think about this. Currently the only work around is I think to add it to the CTL with expired allowed (or disable strict mode) Kind regards, Martijn
The certificate should not be used, but only the (private)key if necessary for decryption. We don't want to sign messages with expired certificates for sure. As there is no "expire" for the key anyway and decryption should be possible if a mail is stuck in queue for more than a day anyway this might be a feature, no?
As to strict-mode, the check if the recipient is matching should of course be done anyway, expired or not.
Regards Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Users mailing list [email protected] https://lists.djigzo.com/lists/listinfo/users
