Question
Coforge
IN
Last activity: 16 Nov 2018 4:33 EST
Email listener not able to decrypt email.
Email listener is processing plain email (not encrypted).
But there are some secure systems which are sending encrypted email to our listener inbox and listener is failing to process with below error for same.
PRPC failed to process the attached email.
The reason(s) for the failure may be internal to the application or caused by external dependencies.
The following issues were detected during processing:
* Unable to decrypt email MIMEMessage:
* Key not found for Listener's email address
* No certificates found for Listener's email address
You may need to verify the state of inbound and/or outbound mail servers.
Please check PRPC logs for details.
I tried to open the encrypted email received in listener inbox using my desktop outlook client but it was failing with "Your Digital Id Name Cannot Be Found By The Underlying Security". So imported required certificate in my outlook and now I'm able to read the encrypted email.
So I am looking for how and where to import this certificate so that listener can read the encrypted message.
Accepted Solution
Coforge
IN
John- Thanks for a update and it makes sense.
I am able to solve it by creating the keystore and referred same in pyEmailCertificateMap decision table.
Synechron
US
I believe its depends on (app server) environment. If it is Apache Tomcat then we can add in server.xml file.
please check the below URL for more information.
Pegasystems Inc.
GB
I believe you are talking about S/Mime here. (https://en.wikipedia.org/wiki/S/MIME).
Who are these encrypted emails aimed at ?
The Sender of these emails must have used a specific certificate to encrypt these emails.
Find out who sent them - and ask them to tell you who they are meant for. (And which Certificate they used to encrypt, and where they got that from).
I'm *pretty* sure PRPC isn't able to decrypt incoming s/Mime emails: and (personally) I think this is probably just fine:
I'm not sure what the use-case would be to give the Email Listener an s/Mime key (or indeed a set of keys?) enabling it to decrypt incoming emails - only (presumably?) to translate them automatically into plain-text and save them ? (The *transmission* encryption - see below - is enough I would say?)
(Note: PRPC *is* able to *encrypt* (outgoing) emails for sure: but that doesn't require a secret key - only a public certificate: and there *is* a use-case for this).
The PDN articles given above, although they also relate to encryption : relate to the *transmission* of emails in a secure way - once the email have reached their destination, they are effectively plain-text again.
An analogy:
SSL/TLS here acts a 'secure envelope' while emails are in transit; but S/Mime means the 'letter' itself is written in a 'secret code'.
I believe you are talking about S/Mime here. (https://en.wikipedia.org/wiki/S/MIME).
Who are these encrypted emails aimed at ?
The Sender of these emails must have used a specific certificate to encrypt these emails.
Find out who sent them - and ask them to tell you who they are meant for. (And which Certificate they used to encrypt, and where they got that from).
I'm *pretty* sure PRPC isn't able to decrypt incoming s/Mime emails: and (personally) I think this is probably just fine:
I'm not sure what the use-case would be to give the Email Listener an s/Mime key (or indeed a set of keys?) enabling it to decrypt incoming emails - only (presumably?) to translate them automatically into plain-text and save them ? (The *transmission* encryption - see below - is enough I would say?)
(Note: PRPC *is* able to *encrypt* (outgoing) emails for sure: but that doesn't require a secret key - only a public certificate: and there *is* a use-case for this).
The PDN articles given above, although they also relate to encryption : relate to the *transmission* of emails in a secure way - once the email have reached their destination, they are effectively plain-text again.
An analogy:
SSL/TLS here acts a 'secure envelope' while emails are in transit; but S/Mime means the 'letter' itself is written in a 'secret code'.
I hope this makes sense; and if I'm wrong about the Email Listener not being able to decrypt - I hope somebody can correct me.
Accepted Solution
Coforge
IN
John- Thanks for a update and it makes sense.
I am able to solve it by creating the keystore and referred same in pyEmailCertificateMap decision table.
Pegasystems Inc.
GB
I could be wrong still on this - but I *think* the key used here is for signing (outgoing, encrypted) emails.
But I haven't tried this in a while, so I might have got it wrong.
Pegasystems Inc.
GB
Ok - so it seems the Email Listener *is* able to decrypt (and sign - I guess it uses the same key?)
I just checked the source code.
Anyway - glad you got it working !
Cheers