Develop Reference

C# Azure - Specified Resource not found after moving from Microsoft.Azure.Cosmos.Table to Azure.Data.Tables

I have an Azure storage account with a table that we are trying to access using C# in a function app. I migrated over from the deprecated Microsoft.Azure.Cosmos.Table library to Azure.Data.Tables.
I get an error when trying to query the table for an entity.
{
"The specified resource does not exist.
RequestId:8612b003-0002-0071-64b2-054424000000
Time:2022-12-01T18:27:02.5504487ZrnStatus: 404 (Not Found)
ErrorCode: ResourceNotFound
Content:
{
"odata.error":
{
"code":"ResourceNotFound",
"message":
{
"lang":"en-US",
"value":"The specified resource does not exist.
RequestId:8612b003-0002-0071-64b2-054424000000
Time:2022-12-01T18:27:02.5504487Z"
}
}
}
rnrnHeaders:rnCache-Control: no-cacher
Transfer-Encoding: chunked
Server: Windows-Azure-Table/1.0,
Microsoft-HTTPAPI/2.0
x-ms-request-id: 8612b003-0002-0071-64b2-054424000000
x-ms-client-request-id: c1668171-b91f-4eba-b2d1-1fef1120595a
x-ms-version: REDACTED
X-Content-Type-Options: REDACTED
Date: Thu, 01 Dec 2022 18:27:02 GMT
Content-Type: application/json;
odata=minimalmetadata;
streaming=true;
charset=utf-8rn"
}
Old previous working code
var primaryCloudStorageAccount = CloudStorageAccount.Parse(Environment.GetEnvironmentVariable("EntityRegistryStorageAccountConnectionString"));
var tableClient = primaryCloudStorageAccount.CreateCloudTableClient();
_registry = tableClient.GetTableReference("EntityRegistry");
Code with new libary that is not working
private readonly TableClient _registry;
_registry = new TableClient(Environment.GetEnvironmentVariable("EntityRegistryStorageAccountConnectionString"), "EntityRegistry");
Also tried this
var tableClient = new TableServiceClient(Environment.GetEnvironmentVariable("EntityRegistryStorageAccountConnectionString"));
_registry = tableClient.GetTableClient("EntityRegistry");
Error is thrown in this code
var registryRecord = await _registry.GetEntityAsync<TableEntity>(entityType.ToString(), registryId);
This also returns a 404 error
var registryRecord = await _registry.GetEntityIfExistsAsync<TableEntity>(entityType.ToString(), registryId);
I know the table exists and it seems to be authenticating me, I can see the URL that is being set on the TableClient and it matched what I see in Azure. I also use the connection string from Azure that has the account and key.
What could be going on with this?

Important note!
In the past library, the GetEntity call would be okay with returning null if the record does not exist. In this case, you need to call GetEntityIFExistsAsync and parse the value returned, it won't just return null like it did previously if the value does not exist.
var registryRecord = await _registry.GetEntityIfExistsAsync<TableEntity>(entityType.ToString(), registryId);
if (registryRecord.HasValue)
return registryRecord.Value;
else
return null;

Construct MIME message for outlook compatible meeting invitation

I am failing to construct a MIME message that is displayed as a meeting invitation in Outlook, compared to when sending an invitation natively via Outlook.
What I want is this view (at least more or less):
What I get instead:
(The file displayed as .ics attachment can be opened and shows correct content).
Here's the meeting body (ics), that I construc programmatically:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:123
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Europe/Amsterdam
BEGIN:STANDARD
TZOFFSETTO:+0100
TZOFFSETFROM:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Amsterdam:20201214T085500
DTEND;TZID=Europe/Amsterdam:20201214T095500
SUMMARY:Test Event
LOCATION:skico HQ
DESCRIPTION:A test in appointment chatbot
PRIORITY:3
END:VEVENT
END:VCALENDAR
The MIME message is built via MimeKit:
private static string BuildMimeContent(Mail mail)
{
var textBody = new TextPart("plain") { Text = mail.BodyText };
var htmlBody = new TextPart("html") { Text = mail.BodyHtml };
var alternative = new Multipart("alternative");
alternative.Add(textBody);
alternative.Add(htmlBody);
var multiPart = new Multipart("mixed") { alternative };
if (mail.Event != null)
{
var eventBody = mail.Event.Parse();
var calendarBody = new TextPart("calendar")
{
Text = eventBody,
ContentTransferEncoding = ContentEncoding.Base64
};
calendarBody.ContentType.Parameters.Add("method", "REQUEST");
calendarBody.ContentType.Parameters.Add("name", "meeting.ics");
alternative.Add(calendarBody);
}
var mimeMessage = new MimeMessage();
mimeMessage.From.Add(new MailboxAddress(mail.Sender.Name, mail.Sender.EMail));
mimeMessage.To.Add(new MailboxAddress(mail.Recipient.Name, mail.Recipient.EMail));
mimeMessage.Subject = mail.Subject;
mimeMessage.Body = multiPart;
// parse and return mime message
return mimeMessage.ToString();
}
yielding:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-rdfmBTE1TuDNFI0Wzfmibg=="
--=-rdfmBTE1TuDNFI0Wzfmibg==
Content-Type: multipart/alternative; boundary="=-6bp3YWbl6STSnwQq7Fne2A=="
--=-6bp3YWbl6STSnwQq7Fne2A==
Content-Type: text/plain; charset=utf-8
Hi!
--=-6bp3YWbl6STSnwQq7Fne2A==
Content-Type: text/html; charset=utf-8
<strong>Hi!</strong>
--=-6bp3YWbl6STSnwQq7Fne2A==
Content-Type: text/calendar; charset=utf-8; method=REQUEST
Content-Id: <123#s.com>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Microsoft Corporation//Outlook 15.0 MIMEDIR//EN
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Europe/Amsterdam
BEGIN:STANDARD
TZOFFSETTO:+0100
TZOFFSETFROM:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Amsterdam:20201214T120800
DTEND;TZID=Europe/Amsterdam:20201214T130800
SUMMARY:Test Event
LOCATION:skico HQ
DESCRIPTION:A test in appointment chatbot
PRIORITY:3
END:VEVENT
END:VCALENDAR
--=-6bp3YWbl6STSnwQq7Fne2A==--
--=-rdfmBTE1TuDNFI0Wzfmibg==--
How does the MIME content need to be constructed instead, such that the alternate view works in Outlook?

There was something wrong with my ICS content. This fixed it:
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 15.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20201214T121600Z
DTEND:20201214T131600Z
SEQUENCE:0
UID:56b39b14ebb641ab7de716a62bed46aa
DTSTAMP:20201210T121600Z
LAST-MODIFIED:20201210T121600Z
SUMMARY:Test Event
LOCATION:s HQ
DESCRIPTION:A test in appointment chatbot
END:VEVENT
END:VCALENDAR
I did not track it down to the root cause. Probably the UID is madatory or the date/timezone format was invalid before.

Using MimeKit to cms sign and verify

I am using Mimekit to do rsa pss cms sign, to simulate this openssl command
openssl cms -sign -in keys.zip -binary -nodetach -signer selfsigned.crt -inkey keypair.pem -out keys.zip.signed -keyopt rsa_padding_mode:pss
public byte[] Sign(byte[] data, byte[] signCert, byte[] privateKey, CmsKeyOpt cmsKeyOpt)
{
MimeMessage message = new MimeMessage
{
Body = new MimePart()
{
Content = new MimeContent(new MemoryStream(data)),
ContentTransferEncoding = ContentEncoding.Binary,
},
};
// Load private key from byte array
StreamReader stream = new StreamReader(new MemoryStream(privateKey), Encoding.Default);
AsymmetricCipherKeyPair keyPair = (AsymmetricCipherKeyPair)new PemReader(stream).ReadObject();
// load certifacte from byte array
X509CertificateParser parser = new X509CertificateParser();
X509Certificate certificate = parser.ReadCertificate(signCert);
// Create RSA PSS CMS signer
CmsSigner signer = new CmsSigner(certificate, keyPair.Private)
{
RsaSignaturePadding = RsaSignaturePadding.Pss,
DigestAlgorithm = DigestAlgorithm.Sha256,
};
// Create BouncyCastle Secure MimeContext
BouncyCastleSecureMimeContext ctx = new TemporarySecureMimeContext();
ctx.EncapsulatedSign(signer, new MemoryStream(data));
// Get signed message body and override it
message.Body = MultipartSigned.Create(ctx, signer, message.Body);
byte[] singedData;
using (var memory = new MemoryStream())
{
message.WriteTo(memory);
singedData = memory.ToArray();
}
return singedData;
}
And everything works fine, my question how I can achieve verify by Mimekit/BouncyCastle, to simulate this openssl command
openssl cms -verify -in keys.zip.signed.dec -CAfile selfsigned.crt -out keys_dec_unsigned.zip
I tried this but I got exception System.NotSupportedException: 'SQLite is not available on pkcs7.Verify(out original) line
public byte[] Verify(byte[] data, byte[] signCert, byte[] privateKey)
{
bool valid = false;
// Load private key from byte array
StreamReader stream = new StreamReader(new MemoryStream(privateKey), Encoding.Default);
AsymmetricCipherKeyPair keyPair = (AsymmetricCipherKeyPair)new PemReader(stream).ReadObject();
// load certifacte from byte array
X509CertificateParser parser = new X509CertificateParser();
X509Certificate certificate = parser.ReadCertificate(signCert);
MimeMessage message = MimeMessage.Load(new MemoryStream(data));
// Create BouncyCastle Secure MimeContext
MimeEntity original;
ApplicationPkcs7Mime pkcs7 = message.Body as ApplicationPkcs7Mime;
if (pkcs7 != null && pkcs7.SecureMimeType == SecureMimeType.SignedData)
{
foreach (var signature in pkcs7.Verify(out original))
{
try
{
valid = signature.Verify();
}
catch (DigitalSignatureVerifyException)
{
// There was an error verifying the signature.
}
}
}
byte[] res = { 0 };
return res;
}
Is there any guide I can follow to verify and return the data to it's origin forum, or an example?

By default, MimeKit tries to instantiate a S/MIME verify context based on its SQLite backend for certificate storage.
If you don't have SQLite installed and/or don't have your certificates stored in the SQLite database that MimeKit will maintain for you, then you need to either register a different backend for certificate storage/retrieval or instantiate your own S/MIME context (like you did for signing).
MimeKit comes with 2 options:
TemporarySecureMimeContext which stores certificates in memory and is what you used to sign the message in your code snippet above.
WindowsSecureMimeContext which uses the Windows OS X.509 certificate store.
Once you decide on which of those to use, you will need to import your certificate(s) into the context (which will import them into the appropriate backend storage location).
Then, after that, you can do this:
using (BouncyCastleSecureMimeContext ctx = new TemporarySecureMimeContext()) {
ctx.Import (...);
foreach (var signature in pkcs7.Verify(ctx, out original)) {
// ...
}
}
Update:
This devolved into misuse of the openssl cms sign command and an inability to verify the signature using MimeKit because MimeKit expects the encapsulated signed data to be in MIME format as it is supposed to be according to the S/MIME specifications.
Here's the deal:
The openssl cms sign command can be used to sign arbitrary data and the corresponding openssl cms verify command can be used to verify such signed output. HOWEVER, it is only valid S/MIME if the original content signed by the openssl cms sign command is/was in MIME format.
MimeKit expects valid S/MIME because it is... surprise, surprise... a MIME library.
As you might have noticed, the Verify() method has an output parameter (out MimeEntity originalEntity). This means that the Verify() method extracts the encapsulated content from within the signed data and parses it into a MIME entity and returns it to you, the caller, in the form of said output parameter.
If the encapsulated content is not in MIME format, then, obviously, the parser will fail to parse it.
Additional background with how CMS signatures work:
When you sign content using the CMS signing routine (e.g. openssl cms sign ...), it produces something that looks a bit like this:
MIME-Version: 1.0
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m"
Content-Transfer-Encoding: base64
MIIQgAYJKoZIhvcNAQcCoIIQcTCCEG0CAQExDTALBglghkgBZQMEAgEwggkPBgkq...
The base64 content in the above MIME part includes both the original content and the CMS signature data (i.e. a list of signatures).
Therefor, MimeKit's Verify() method needs to separate the signatures from the original content after base64 decoding it. MimeKit then returns to you, the caller, the original content (which it expects to be in MIME format) and the list of signatures that you can then independently verify the authenticity of.
When I kept repeating myself that it mattered what format the file.bin file was in when you signed the content, I was not saying that openssl or MimeKit needed to parse file.bin when verifying the signature, I was saying that file.bin has exactly the same content as what would be extracted from the base64 blob in the S/MIME output produced by openssl cms sign ... and therefore, it needs to be in MIME format.

Verify pkcs7 Signature received from AS2 trading partner

I am receiving an AS2 message from my trading partner. I have successfully decrypted it and it has following content:
Content-Type: multipart/signed; boundary="----1E2FB76A361B53C9D12B3971C32BC0D8"; protocol="application/pkcs7-signature"; micalg="sha-256"
------1E2FB76A361B53C9D12B3971C32BC0D8
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="edi.dat"
Content-Type: application/octet-stream; charset="ascii"; name="edi.dat"
ISA*00* *00* *ZZ*SPSAS2 *ZZ*SPSAS2 *140919*1159*|*00501*100000001*0*P*>
GS*PO*AS2S3REC*AS2S3SEND*20140919*1159*123*X*005010
ST*850*1234
BEG*00*SA*SPSAS2TEST**20121017
REF*IA*TEST
PER*OC*Someone*TE*2844994944
DTM*001*20121025
N1*ST*SomeoneElse
N3*My address is private
N4*ST THOMAS*VI*00801
PO1*54812*1*EA***SK*123546*VP*123546*UP*123456987111
CTT*1
SE*11*1234
GE*1*123
IEA*1*100000001
------1E2FB76A361B53C9D12B3971C32BC0D8
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
MIIL5gYJKoZIhvcNAQcCoIIL1zCCC9MCAQExDzANBglghkgBZQMEAgEFADALBgkq
hkiG9w0BBwGgggg3MIIIMzCCBxugAwIBAgIQCq+jbObLeCwtsdF61BAtBzANBgkq
hkiG9w0BAQsFADBNMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5j
MScwJQYDVQQDEx5EaWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgw
MjA5MDAwMDAwWhcNMjEwMjE3MTIwMDAwWjCBgjELMAkGA1UEBhMCVVMxEjAQBgNV
BAgTCU1pbm5lc290YTEUMBIGA1UEBxMLTWlubmVhcG9saXMxGzAZBgNVBAoTElNQ
UyBDb21tZXJjZSwgSW5jLjELMAkGA1UECxMCSVQxHzAdBgNVBAMTFnNwc2FzMi5j
b21tZXJjZXZhbi5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCw
1fJZ14+32k+Qutklk2+YYxaPMe2ASv41lfR5945H6M2SmdgFqqF2LPNZqWofcBPQ
HbMWctbBHOW1shOS2XvBRUFT5tuyQKcG4iYz7FEHFGpu4oGyC0eUYSuBBtTQMmRi
zk8bMwwNhRUUyzxa/y3OePK0lEDdaQsSKi8WHLkfkVZBo7Lk9CPyR4WZ8q8uo/qW
tNMDbk1Fn2CtXqYrXFTmLJ81ScXGTp5zoIUhrkGcUzumK+25EBT9p+2XcVMCUj9S
LY1DWyTnWx2mgT0ekeHM0pXV2MPDuUG99SiQB4Q0CH0I3J4ZafP2rCzBVkvNlTFJ
ZojaQyfcP9W73ZiYSgUmQ3mCa/BjACTO8wztu9DBelUNVjSxCYysGUdKNyl6hAAI
OAPe8z0mmDCVA7S4rnTYkliW+2JQdOTaKc0GOiaHQjrd+Gta1aAJHRR1pxjSX2FC
apS3DkiJl4i5vdyPZM53QhS51XCxGHtCCcJ574MIPkthI4SLwKJkk6rSgvb7B0ai
7jbDmvp1FjY0SgKoHyN+QNH1J4rMeK7IUp2N0R+YrJa6kEaocIptSoPToDGKWk+o
qAx65r3T2n21jEfiCzN6JyqxNfE1T35Pekpvu4ioUEfW1ICf6AOQ5oQHWLr/Fhk2
sVzptYw5Lmtkb/sPGP1R/hBy88HAlTAh+QFrRJHHWwIDAQABo4ID1zCCA9MwHwYD
VR0jBBgwFoAUD4BhHIIxYdUvKOeNRji0LOHG2eIwHQYDVR0OBBYEFJs5x7uPOhBe
2Mp1aThYg8urrQ4FMCEGA1UdEQQaMBiCFnNwc2FzMi5jb21tZXJjZXZhbi5jb20w
DgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBr
BgNVHR8EZDBiMC+gLaArhilodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1z
aGEyLWc2LmNybDAvoC2gK4YpaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NzY2Et
c2hhMi1nNi5jcmwwTAYDVR0gBEUwQzA3BglghkgBhv1sAQEwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAIBgZngQwBAgIwfAYIKwYB
BQUHAQEEcDBuMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20w
RgYIKwYBBQUHMAKGOmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2Vy
dFNIQTJTZWN1cmVTZXJ2ZXJDQS5jcnQwDAYDVR0TAQH/BAIwADCCAfYGCisGAQQB
1nkCBAIEggHmBIIB4gHgAHYApLkJkLQYWBSHuxOizGdwCjw1mAT5G9+443fNDsgN
3BAAAAFhezY//QAABAMARzBFAiEA/peliWFFZt3DPuaO1JekVr9XQhfW/SeCVONq
Rmju3zECIDByDCYP5dzgszieTnkpP3w5dsOfiVmJ+RRmuNORjb0rAHYAh3W/51l8
+IxDmV+9827/Vo1HVjb/SrVgwbTq/16ggw8AAAFhezZA2gAABAMARzBFAiEAmlnD
uPy34+XDxNZU8r0dD4fI+hFJwxQQkatA9zkIzegCIFxT3jLCCf9pVoEIeWYBOv3C
BjVqsn0jDqXLYSVOJTQVAHYAu9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e
0YUAAAFhezZAzAAABAMARzBFAiEAwAWMiOFLxRBqVjLc/cktB7SjMujisPPx5WQA
Bat22NoCIAtVJcU2yoj6c66x8o/YI2lfSdZqF46K51WGb6/J79UdAHYAb1N2rDHw
MRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RMAAAFhezZDCwAABAMARzBFAiAqzLuy
gkPgUSELvuB2xF9bFxPOj2YjBoiggQbUGfCMqgIhAL3VnGsi6xXUBswPEMn0M3P5
Cgnz6UGp2M4ItBE69YQnMA0GCSqGSIb3DQEBCwUAA4IBAQBbxA1NvqhkXddENUT5
qHY1pF91metZG38DwUS7c0xgS/LoY/WZZJ2cv0rEMoGCzRwwYijiiTc1MY6muiGE
hpdNja9Tu3bYJ9Z1bkiJJVKknqcqs64ibIbD762a7L/J0O9DzFKHeUwXAhpzT+rh
Z2eIPSR9BpUbiBpok73F/TvW2beJb2ncEiQJujK+UKlB9XeSsghrMOBiGnNJFB5t
Y155GAQb6oGiwRkkhWiJYZOq6riU5dmUbyqAqaxHij6hZOUzDL/fM5oeOpusedR0
4+eYgTe7LBq2teDNjchSceapKRXbbtz4UNDp0Ce3ZQyU4T4ndAsF9QiQnq7478SO
2ZgpMYIDczCCA28CAQEwYTBNMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNl
cnQgSW5jMScwJQYDVQQDEx5EaWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EC
EAqvo2zmy3gsLbHRetQQLQcwDQYJYIZIAWUDBAIBBQCggeQwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwODMwMTkxMjQ3WjAvBgkq
hkiG9w0BCQQxIgQgh0UxRgyVkgQvRpk0/2ZBwHWFEqKH5Hu6qgpvjX9ETjUweQYJ
KoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl
AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggIAEb1tlBKO
lSv69TDq4Jlhmtqt2szWKZazOhTMDUo68j3rJ6xJS9so7NKrQv+aeo8DdAblU/G/
OD2U6XS5iDdYg94aIyNEjuCZOfvibV8U1PA6WP+8VTo3vEDP0JoAt/NgWJKiKESS
iQ/8waAcLqxECW1Pa11KxdvO6xhJKpNI/xpl/t0007mYrZDseuLZNcyQjOOrP0Kj
E/21geSIyTTN842R0Zg6qTn6XlkPUq/bSa9MnlCUDNGxFn25Uqv+3nYlJhEiGyHa
GQef4vZL1faz7ljxnx/MJKiWAbq07F7tYEHGyVTkO3MGF/wBe8vDlYs3U1T4v+2g
hjEWiOyREYTt9a4XJ1QcscjbGCRl28BajmxBBHibkSM2o5ztLxPUoiEKjY3XQc6J
oHX3Gmj63qMQPQz58AVoalGtwxOxlJiFc0Y13NIydbxMRuxep0XHVNE5XFQGE1K/
2r5iV4pS1f+EarDxfjzkrUwZFYJLdO27DqIL//6m6uTiIgZBXnzqulWlLxX17MCD
2yUOTRPGqo9eRhnrtbeh3PYGXG0zhGSdmzoTQr2mf2k7EDB/48BGvUWeHGsc7sQT
LUrlnLKqiG1uRB4sWTWMtxsKtH8kGP824ihszLh+13IXlMztCEg+kh472KQENguC
Yxt8DzcvxMi0rIsbsC/Thq3nxpFCGDV7m3Q=
------1E2FB76A361B53C9D12B3971C32BC0D8--
It has the signature in "Base64" format and "pkcs7-signature". I am not able to match signature. I am considering following part as main data:
ISA*00* *00* *ZZ*SPSAS2 *ZZ*SPSAS2 *140919*1159*|*00501*100000001*0*P*>
GS*PO*AS2S3REC*AS2S3SEND*20140919*1159*123*X*005010
ST*850*1234
BEG*00*SA*SPSAS2TEST**20121017
REF*IA*TEST
PER*OC*Someone*TE*2844994944
DTM*001*20121025
N1*ST*SomeoneElse
N3*My address is private
N4*ST THOMAS*VI*00801
PO1*54812*1*EA***SK*123546*VP*123546*UP*123456987111
CTT*1
SE*11*1234
GE*1*123
IEA*1*100000001
and base64 string as sign. and sung following function to match sign:
static bool Verify(string text, byte[] signature, string certPath)
{
X509Certificate2 cert = new X509Certificate2(certPath);
RSACryptoServiceProvider csp = (RSACryptoServiceProvider)cert.PublicKey.Key;
SHA1Managed sha1 = new SHA1Managed();
UnicodeEncoding encoding = new UnicodeEncoding();
byte[] data = encoding.GetBytes(text);
byte[] hash = sha1.ComputeHash(data);
// Verify the signature with the hash
return csp.VerifyHash(hash, CryptoConfig.MapNameToOID("SHA1"), signature);
}
But this function is not matching the signature.
Please help me with this problem.
Thank you...

I can't, personally, get the data to validate. (I'm assuming that either there are trailing spaces that aren't copying correctly or that the payload has been altered (e.g. "My address is private"))
The flow that I expect is happening:
The pkcs7 content is a CMS SignedData with detached content.
The signed content was specified in the first stream
So you need to do something like:
byte[] dataBytes = ReadFirstSegment();
byte[] signatureBytes = ReadSecondSegment();
SignedCms cms = new SignedCms(new ContentInfo(dataBytes), detached: true);
cms.Decode(signatureBytes);
// This next line throws a CryptographicException if the signature can't be verified
cms.CheckSignature(true);
SignerInfoCollection signers = cms.SignerInfos;
if (signers.Count != 1)
{
// probably fail
}
if (!IsExpectedCertificate(signers[0].Certificate))
{
// fail
}
// success

Word 2010 reports an error after saving to WebDAV server

I've got a custom WebDAV server, built using Sphoirum webdav server, that resides inside an ASP.NET MVC3 application. It's a .Net 4.0 project.
The document repository is a SharePoint, where our MVC application is a front end to it, and exposes the whole thing via the WebDAV. Just to note we don't have WebDAV publishing enabled on our IIS 7.5.
I've implemented the following HTTP verbs:
Get
Head
Lock
Options
PropFind
Put
Unlock
Now, when I open a word document, it's first in the read only mode. Getting the lock and into edit mode is successful, but when I want to save the changes in my document I get the following:
Your changes were saved but could not be uploaded because of an error.
The trick is that document is indeed saved correctly to the repository, and the response from our WebDAV server to word is HTTP/200 but the Word complains nonetheless.
I've also tried editing in Word directly from the SharePoint repository, just to confirm that my Office isn't broken somehow - all works.
Here's the response from PUT request when saving the document from Word:
HTTP/1.1 200 OK
Date: Tue, 06 Sep 2011 12:25:47 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.6545
Last-Modified: Tue, 06 Sep 2011 12:25:47 GMT
ETag: "{F4A63494-D302-4C9B-9C57-D0CB0937A2B0},9"
ResourceTag: rt:F4A63494-D302-4C9B-9C57-D0CB0937A2B0#00000000009
X-MSDAVEXTLockTimeout: Second-3600
Lock-Token: opaquelocktoken:{F4A63494-D302-4C9B-9C57-D0CB0937A2B0}20110906T122532Z
Expires: Mon, 22 Aug 2011 12:25:47 GMT
Cache-Control: private,max-age=0
Content-Length: 0
Public-Extension: http://schemas.microsoft.com/repl-2
Set-Cookie: WSS_KeepSessionAuthenticated=40689; path=/
And here's the same response, for the same document, from our WebDAV server:
HTTP/1.1 200 OK
Cache-Control: private,max-age=0
Content-Length: 0
Expires: Wed, 24 Aug 2011 08:03:28 GMT
Last-Modified: Wed, 07 Sep 2011 08:03:28 GMT
ETag: "{4a4331a8-7df6-43e6-bd5f-bb80765e83a2},1"
Server: Microsoft-IIS/7.5
MS-Author-Via: DAV
ResourceTag: rt:4a4331a8-7df6-43e6-bd5f-bb80765e83a2#00000000001
Lock-Token: opaquelocktoken:{4a4331a8-7df6-43e6-bd5f-bb80765e83a2}20110907T080328Z
X-MSDAVEXTLockTimeout: Second-3600
Public-Extension: http://schemas.microsoft.com/repl-2
MicrosoftSharePointTeamServices: 12.0.0.6545
Set-Cookie: WSS_KeepSessionAuthenticated=40689; path=/
X-Powered-By: ASP.NET
Date: Wed, 07 Sep 2011 08:03:27 GMT
So I've tried to mimic some of the headers SharePoint emits, like MicrosoftSharePointTeamServices but to no avail.

By the way, I found the bug in Sphorium webdav that was causing this. The bug was in the method DavLockBase_InternalProcessDavRequest() and the incorrect line of code was:
string[] _lockTokens = this.RequestLock.GetLockTokens();
which should be:
string[] _lockTokens = this.ResponseLock.GetLockTokens();
After that change, saving files in Word 2010 worked fine.

If someone ever runs into this again, here is a fix that was built based on the above answer, and on what I have found from working with word 2010. Basically the fix involves replacing the code for the "DavLockBase_InternalProcessDavRequest" method (I've added some comments for each "correction").
As a note (found some info here): the behavior of the webdav implementation for word 2010 differs on whether there is a patch installed on the client side or not; therefore the 3rd correction may not be needed in all cases!
Hope it helps!
private int DavLockBase_InternalProcessDavRequest(object sender, EventArgs e)
{
int _responseCode = (int)DavLockResponseCode.Ok;
//string[] _lockTokens = this.RequestLock.GetLockTokens();
//#1 the above line is incorrect. replaced with the following:
string[] _lockTokens = this.ResponseLock.GetLockTokens();
//Check to see if a lock refresh was requested
if (base.HttpApplication.Request.Headers["If"] != null)
{
if (_lockTokens.Length == 1)
{
//#2 not sure why this should be done (or not), however I've seen this in other people corrections.
//DavRefreshEventArgs _refreshEventArgs = new DavRefreshEventArgs(_lockTokens[0], this.RequestLock.LockTimeout);
//OnRefreshLockDavRequest(_refreshEventArgs);
}
base.HttpApplication.Response.AppendHeader("Timeout", "Second-" + this.ResponseLock.LockTimeout);
}
else
{
//New lock request
StringBuilder _opaquelockTokens = new StringBuilder();
//#3 finally, added the check below, as most of the times, when using word 2010 there are no lock requests
if (_lockTokens.Length > 0)
{
foreach (string _lockToken in _lockTokens)
_opaquelockTokens.Append("<opaquelocktoken:" + _lockToken + ">");
base.HttpApplication.Response.AppendHeader("Lock-Token", _opaquelockTokens.ToString());
}
}
//Check to see if there were any process errors...
Enum[] _errorResources = this.ProcessErrorResources;
if (_errorResources.Length > 0)
{
//Append a response node
XmlDocument _xmlDocument = new XmlDocument();
XmlNode _responseNode = _xmlDocument.CreateNode(XmlNodeType.Element, _xmlDocument.GetPrefixOfNamespace("DAV:"), "response", "DAV:");
//Add the HREF
XmlElement _requestLockHrefElement = _xmlDocument.CreateElement("href", "DAV:");
_requestLockHrefElement.InnerText = base.RelativeRequestPath;
_responseNode.AppendChild(_requestLockHrefElement);
//Add the propstat
XmlElement _propstatElement = _xmlDocument.CreateElement("propstat", "DAV:");
XmlElement _propElement = _xmlDocument.CreateElement("prop", "DAV:");
XmlElement _lockDiscoveryElement = _xmlDocument.CreateElement("lockdiscovery", "DAV:");
_propElement.AppendChild(_lockDiscoveryElement);
_propstatElement.AppendChild(_propElement);
XmlElement _statusElement = _xmlDocument.CreateElement("status", "DAV:");
_statusElement.InnerText = InternalFunctions.GetEnumHttpResponse(DavLockResponseCode.FailedDependency);
_propstatElement.AppendChild(_statusElement);
_responseNode.AppendChild(_propstatElement);
base.SetResponseXml(InternalFunctions.ProcessErrorRequest(this.ProcessErrors, _responseNode));
_responseCode = (int)ServerResponseCode.MultiStatus;
}
else
{
//No issues
using (Stream _responseStream = new MemoryStream())
{
XmlTextWriter _xmlWriter = new XmlTextWriter(_responseStream, new UTF8Encoding(false));
_xmlWriter.Formatting = Formatting.Indented;
_xmlWriter.IndentChar = '\t';
_xmlWriter.Indentation = 1;
_xmlWriter.WriteStartDocument();
//Open the prop element section
_xmlWriter.WriteStartElement("D", "prop", "DAV:");
_xmlWriter.WriteStartElement("lockdiscovery", "DAV:");
this.ResponseLock.ActiveLock.WriteTo(_xmlWriter);
_xmlWriter.WriteEndElement();
_xmlWriter.WriteEndElement();
_xmlWriter.WriteEndDocument();
_xmlWriter.Flush();
base.SetResponseXml(_responseStream);
_xmlWriter.Close();
}
}
return _responseCode;
}

Observation: the lock token uses an invalid syntax (so does Sharepoints). Also; most of these headers shouldn't be needed (being proprietary) or do not apply to a PUT response (such as Lock-Token).
I would recommend to try publishing to Apache with mod_dav first, and to observe the HTTP exchange.