Check if email is digitally signed using VB.Net
I would like to know if it's possible, using VB.Net, to check if an e-mail is digitally signed and who is the issuer of the certificate.
Using Extended MAPI Wrapper and Cryptography I was able to get the smime.p7m attachment from an e-mail and get the certificate information out of it (including the issuer), so it seemed like everything was working. The issue is that if I send an unsigned e-mail and manually attach a smime.p7m file, it will trick the code into thinking that the e-mail is signed.
Does anyone have a solution for this? I can also use other methods like Outlook Interop.
vb.net outlook mapi smime
add a comment |
I would like to know if it's possible, using VB.Net, to check if an e-mail is digitally signed and who is the issuer of the certificate.
Using Extended MAPI Wrapper and Cryptography I was able to get the smime.p7m attachment from an e-mail and get the certificate information out of it (including the issuer), so it seemed like everything was working. The issue is that if I send an unsigned e-mail and manually attach a smime.p7m file, it will trick the code into thinking that the e-mail is signed.
Does anyone have a solution for this? I can also use other methods like Outlook Interop.
vb.net outlook mapi smime
add a comment |
I would like to know if it's possible, using VB.Net, to check if an e-mail is digitally signed and who is the issuer of the certificate.
Using Extended MAPI Wrapper and Cryptography I was able to get the smime.p7m attachment from an e-mail and get the certificate information out of it (including the issuer), so it seemed like everything was working. The issue is that if I send an unsigned e-mail and manually attach a smime.p7m file, it will trick the code into thinking that the e-mail is signed.
Does anyone have a solution for this? I can also use other methods like Outlook Interop.
vb.net outlook mapi smime
I would like to know if it's possible, using VB.Net, to check if an e-mail is digitally signed and who is the issuer of the certificate.
Using Extended MAPI Wrapper and Cryptography I was able to get the smime.p7m attachment from an e-mail and get the certificate information out of it (including the issuer), so it seemed like everything was working. The issue is that if I send an unsigned e-mail and manually attach a smime.p7m file, it will trick the code into thinking that the e-mail is signed.
Does anyone have a solution for this? I can also use other methods like Outlook Interop.
vb.net outlook mapi smime
vb.net outlook mapi smime
edited Nov 1 '18 at 0:02
Blackwood
4,042122338
4,042122338
asked Oct 31 '18 at 22:07
Fabio LeonardoFabio Leonardo
414
414
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Outlook Object Model always tries to represent signed and encrypted messages as regular MailItem
objects. The MessageClass
property will return "IPM.Note"
. It goes as far as returning a fake IMessage
object from the MailItem.MAPIOBJECT
property.
If you are using Extended MAPI, you can read the PR_MESSAGE_CLASS
property and check if its value corresponds to one of the signed/encrypted message classes (e.g. "IPM.Note.SMIME.MultipartSigned"
). Just make sure to unwrap the IMessage
object if you are retrieving it from the MailItem.MAPIOBJECT
property.
You can also use Redemption and and its RDOEncryptedMessage object - it allows to decrypt an encrypted message using RDOEncryptedMessage.GetDecryptedMessage
message as well as access the certificate properties.
add a comment |
If you have a truly signed S/MIME message, then the "smime.p7m" attachment will either have a Content-Type
value of application/pkcs7-mime; smime-type=signed-data
-or- it will have a Content-Type
value of application/pkcs7-signature
and will be the 2nd child MIME part of a multipart/signed
container.
To visualize:
Option 1:
Content-Type: application/pkcs7-mime; smime-type="signed-data"; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
Option 2:
Content-Type: multipart/signed; boundary="some-bounary-string"; protocol="application/pkcs7-signature"
--some-boundary-string
Content-Type: text/plain
This is the message content that was signed...
--some-boundary-string
Content-Type: application/pkcs7-signature; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
...
--some-boundary-string--
I'm not familiar with the Exchange MAPI wrapper API, but there should be a way to get the Content-Type
value. Depending on what that is, you can check for the other attributes I mentioned above to verify if it is actually a signed message or just an attachment.
Note: They can also be application/x-pkcs7-mime
and application/x-pkcs7-signature
, but other than the leading x-
of the MIME subtype, the logic is the same.
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 '18 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 '18 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 '18 at 13:30
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53092614%2fcheck-if-email-is-digitally-signed-using-vb-net%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Outlook Object Model always tries to represent signed and encrypted messages as regular MailItem
objects. The MessageClass
property will return "IPM.Note"
. It goes as far as returning a fake IMessage
object from the MailItem.MAPIOBJECT
property.
If you are using Extended MAPI, you can read the PR_MESSAGE_CLASS
property and check if its value corresponds to one of the signed/encrypted message classes (e.g. "IPM.Note.SMIME.MultipartSigned"
). Just make sure to unwrap the IMessage
object if you are retrieving it from the MailItem.MAPIOBJECT
property.
You can also use Redemption and and its RDOEncryptedMessage object - it allows to decrypt an encrypted message using RDOEncryptedMessage.GetDecryptedMessage
message as well as access the certificate properties.
add a comment |
Outlook Object Model always tries to represent signed and encrypted messages as regular MailItem
objects. The MessageClass
property will return "IPM.Note"
. It goes as far as returning a fake IMessage
object from the MailItem.MAPIOBJECT
property.
If you are using Extended MAPI, you can read the PR_MESSAGE_CLASS
property and check if its value corresponds to one of the signed/encrypted message classes (e.g. "IPM.Note.SMIME.MultipartSigned"
). Just make sure to unwrap the IMessage
object if you are retrieving it from the MailItem.MAPIOBJECT
property.
You can also use Redemption and and its RDOEncryptedMessage object - it allows to decrypt an encrypted message using RDOEncryptedMessage.GetDecryptedMessage
message as well as access the certificate properties.
add a comment |
Outlook Object Model always tries to represent signed and encrypted messages as regular MailItem
objects. The MessageClass
property will return "IPM.Note"
. It goes as far as returning a fake IMessage
object from the MailItem.MAPIOBJECT
property.
If you are using Extended MAPI, you can read the PR_MESSAGE_CLASS
property and check if its value corresponds to one of the signed/encrypted message classes (e.g. "IPM.Note.SMIME.MultipartSigned"
). Just make sure to unwrap the IMessage
object if you are retrieving it from the MailItem.MAPIOBJECT
property.
You can also use Redemption and and its RDOEncryptedMessage object - it allows to decrypt an encrypted message using RDOEncryptedMessage.GetDecryptedMessage
message as well as access the certificate properties.
Outlook Object Model always tries to represent signed and encrypted messages as regular MailItem
objects. The MessageClass
property will return "IPM.Note"
. It goes as far as returning a fake IMessage
object from the MailItem.MAPIOBJECT
property.
If you are using Extended MAPI, you can read the PR_MESSAGE_CLASS
property and check if its value corresponds to one of the signed/encrypted message classes (e.g. "IPM.Note.SMIME.MultipartSigned"
). Just make sure to unwrap the IMessage
object if you are retrieving it from the MailItem.MAPIOBJECT
property.
You can also use Redemption and and its RDOEncryptedMessage object - it allows to decrypt an encrypted message using RDOEncryptedMessage.GetDecryptedMessage
message as well as access the certificate properties.
answered Oct 31 '18 at 23:30
Dmitry StreblechenkoDmitry Streblechenko
42.4k32760
42.4k32760
add a comment |
add a comment |
If you have a truly signed S/MIME message, then the "smime.p7m" attachment will either have a Content-Type
value of application/pkcs7-mime; smime-type=signed-data
-or- it will have a Content-Type
value of application/pkcs7-signature
and will be the 2nd child MIME part of a multipart/signed
container.
To visualize:
Option 1:
Content-Type: application/pkcs7-mime; smime-type="signed-data"; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
Option 2:
Content-Type: multipart/signed; boundary="some-bounary-string"; protocol="application/pkcs7-signature"
--some-boundary-string
Content-Type: text/plain
This is the message content that was signed...
--some-boundary-string
Content-Type: application/pkcs7-signature; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
...
--some-boundary-string--
I'm not familiar with the Exchange MAPI wrapper API, but there should be a way to get the Content-Type
value. Depending on what that is, you can check for the other attributes I mentioned above to verify if it is actually a signed message or just an attachment.
Note: They can also be application/x-pkcs7-mime
and application/x-pkcs7-signature
, but other than the leading x-
of the MIME subtype, the logic is the same.
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 '18 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 '18 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 '18 at 13:30
add a comment |
If you have a truly signed S/MIME message, then the "smime.p7m" attachment will either have a Content-Type
value of application/pkcs7-mime; smime-type=signed-data
-or- it will have a Content-Type
value of application/pkcs7-signature
and will be the 2nd child MIME part of a multipart/signed
container.
To visualize:
Option 1:
Content-Type: application/pkcs7-mime; smime-type="signed-data"; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
Option 2:
Content-Type: multipart/signed; boundary="some-bounary-string"; protocol="application/pkcs7-signature"
--some-boundary-string
Content-Type: text/plain
This is the message content that was signed...
--some-boundary-string
Content-Type: application/pkcs7-signature; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
...
--some-boundary-string--
I'm not familiar with the Exchange MAPI wrapper API, but there should be a way to get the Content-Type
value. Depending on what that is, you can check for the other attributes I mentioned above to verify if it is actually a signed message or just an attachment.
Note: They can also be application/x-pkcs7-mime
and application/x-pkcs7-signature
, but other than the leading x-
of the MIME subtype, the logic is the same.
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 '18 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 '18 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 '18 at 13:30
add a comment |
If you have a truly signed S/MIME message, then the "smime.p7m" attachment will either have a Content-Type
value of application/pkcs7-mime; smime-type=signed-data
-or- it will have a Content-Type
value of application/pkcs7-signature
and will be the 2nd child MIME part of a multipart/signed
container.
To visualize:
Option 1:
Content-Type: application/pkcs7-mime; smime-type="signed-data"; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
Option 2:
Content-Type: multipart/signed; boundary="some-bounary-string"; protocol="application/pkcs7-signature"
--some-boundary-string
Content-Type: text/plain
This is the message content that was signed...
--some-boundary-string
Content-Type: application/pkcs7-signature; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
...
--some-boundary-string--
I'm not familiar with the Exchange MAPI wrapper API, but there should be a way to get the Content-Type
value. Depending on what that is, you can check for the other attributes I mentioned above to verify if it is actually a signed message or just an attachment.
Note: They can also be application/x-pkcs7-mime
and application/x-pkcs7-signature
, but other than the leading x-
of the MIME subtype, the logic is the same.
If you have a truly signed S/MIME message, then the "smime.p7m" attachment will either have a Content-Type
value of application/pkcs7-mime; smime-type=signed-data
-or- it will have a Content-Type
value of application/pkcs7-signature
and will be the 2nd child MIME part of a multipart/signed
container.
To visualize:
Option 1:
Content-Type: application/pkcs7-mime; smime-type="signed-data"; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
Option 2:
Content-Type: multipart/signed; boundary="some-bounary-string"; protocol="application/pkcs7-signature"
--some-boundary-string
Content-Type: text/plain
This is the message content that was signed...
--some-boundary-string
Content-Type: application/pkcs7-signature; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
...
--some-boundary-string--
I'm not familiar with the Exchange MAPI wrapper API, but there should be a way to get the Content-Type
value. Depending on what that is, you can check for the other attributes I mentioned above to verify if it is actually a signed message or just an attachment.
Note: They can also be application/x-pkcs7-mime
and application/x-pkcs7-signature
, but other than the leading x-
of the MIME subtype, the logic is the same.
answered Nov 10 '18 at 19:17
jstedfastjstedfast
18.6k15177
18.6k15177
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 '18 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 '18 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 '18 at 13:30
add a comment |
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 '18 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 '18 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 '18 at 13:30
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 '18 at 11:17
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 '18 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 '18 at 13:27
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 '18 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 '18 at 13:30
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 '18 at 13:30
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53092614%2fcheck-if-email-is-digitally-signed-using-vb-net%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown