Hi all,

Some time ago a customer of mine wanted to use the Windows Server 2008 R2 Certificate Enrollment Web Services, so they could send a PKCS#10 request and get the certificate back.

They followed the instructions in this whitepaper: Certificate Enrollment Web Services in Windows Server 2008 R2. They installed the CA and the web services, and they were able to enroll certs by using the windows GUI ("Request new certificate..." option in the certificate store).

Then they tried to consume those web services from a C# client. The issue was that they couldn't find the relevant method for enrollment.

Our "Request New Certificate..." GUI uses CertEnroll behind the scenes to access those web services, instead of attacking the web services directly.

Microsoft SDKcontains a sample which uses the Certificate Enrollment Web Services through CertEnroll:
"
C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\security\x509 certificate enrollment\CSharp\enrollWithIX509EnrollmentHelper
"

From its readme.txt:
"
Windows 7 X509CertificateEnrollment C# Sample

Sample name: enrollWithIX509EnrollmentHelper

Description:
This sample demonstrates how to use the Windows 7 new http protocol to
enroll a certificate by calling the IX509EnrollmentHelper::AddEnrollmentServer
and IX509Enrollment2::Enroll methods. The purpose of the call to the
IX509EnrollmentHelper::AddEnrollmentServer is to cache the authentication
credential to enrollment server in Windows vault.

This sample does not support certificate authentication type

"

I hope this helps.

Regards,

Alex (Alejandro Campos Magencio)

Hi all,

You may want to sign data and verify those signatures by following the CAdESstandard in your .NET application.

The issue is that, by default, we haveno specific MS API or MS .NET security library to create or verify CAdES signatures.

As you may know already, .NET security libraries are a wrapper around the Microsoft native CryptoAPI. Unfortunately, low level CryptoAPI doesn’t understand CAdEs signatures.

So you may try to use e.g. SignedCms.CheckSignature to verify a CAdES signature (which is the usual way to check a CMS digital signature by using the approach detailed at Understanding of SignedCms.CheckSignature(True)) and it may return “true”. But .NET won’t be verifying the CAdES piece so it won’t satisfy your requirements.

You may need to follow the CAdES standard (RFC5126 - CMS Advanced Electronic Signatures (CAdES)) and implement your own library for the creation and verification of this kind of signatures, or you may leverage the possibility of buying a third-party library that supports that standard. This is one example I found from one of our partners:

TrueSigner - advanced electonic signature application
“
Application fully implements ETSI i IETF standards for advanced electronic signatures: ETSI TS 101 733 - CAdES and IETF RFC 5126 - CMS Advanced Electronic Signatures (CAdES). To support modularity TrueSigner exposes full COM interface, so solution can be easily integrated to customer or partner solution.
“

I hope this helps.

Regards,

Alex (Alejandro Campos Magencio)

Hi all,

The other day a customer of mine was trying to generate XML signatures following the ebXML standard with .NET and its SignedXML class. The main issue was that they didn't know how to refer in the signature the reference to an attachment that appears in the manifest of the SOAP Envelopebody here:

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap..org/soap/envelope/" xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd">

  <SOAP:Header xsi:schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd">

...

  </SOAP:Header>

  <SOAP:Body>

    <eb:Manifest eb:version="2.0">

      <eb:Reference xlink:href="cid:ref1" />

    </eb:Manifest>

  </SOAP:Body>

</SOAP:Envelope>

The resultant signature didn't contain a reference like this in its SignedInfo node, so a third-party was refusing the signature:

<Reference URI="cid:ref1">

  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>

  <DigestValue>3pkh0c4HZp81qc062h/cAiZE+wM=</DigestValue>

</Reference>

Well,this is a known limitation of SignedXml when working with ebXml: SignedXml won’t support URIs with “cid:” prefix by design. SignedXml only knows how to deal with URL's as it uses XmlSecureResolver which only deals with URL's as well.

At the end, my customer managed to generate a valid ebXML signature, using SignedXml to create the Signature element and then adding the Reference element with URI=cid:ref1 "manually" into the signature element. The DigestValue of this element should be easy to generate with SHA1CryptoServiceProvider and then converted to a base64 string. Then SignedData should be re-generated to take the changes to Signature element into account.

In any case, please note that we already commented that this scenario is not supported at all by SignedXML: Which standards does SignedXml support?

Also note that people found ways to verify signatures with "cid:" prefixes, as commented here:

XML Digital Signature Verification with Unknown URI Schemes

Validating XML Digital Signatures with References Using Unrecognized URI Prefixes

I hope this helps.

Regards,

Alex (Alejandro Campos Magencio)

Hi all,

The other day a customer of mine was trying to validate the chain of a cert like this:

X509Certificate2 cert = new X509Certificate2(fileName);

Console.WriteLine(String.Format("Certificate {0} is valid: {1}", fileName, cert.Verify()));

But the issue was that the cert had no validCRL (Certificate Revocation List) and they didn't want the validation to fail because of that. They still wanted to be able to use the cert. So we changen the validation code to avoid CRL validation:

X509Certificate2 Cert = new X509Certificate2(fileName);

X509Chain chain = new X509Chain();

chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck;            

Console.WriteLine(String.Format("Certificate {0} is valid: {1}", fileName, chain.Build(cert)));

I hope this helps.

Regards,

Alex (Alejandro Campos Magencio)

Hi all,

I've been working recently on a couple of issues with SignedXml not being able to generate XML signatures following certain standards or validate those signatures properly. Well, at the end we sometimes managed to make things work,but we must note that .NET SignedXml class was only designed to adhere to the XMLDSIG spec. It has no knowledge of SAML, SAML 2.0,SOAP or any other higher level XML protocol. If you are using SignedXml for any other protocol other than XMLDSIG, the scenario is not supported.

From SignedXmlarticle inMSDN:

The SignedXml class is the main class used for XML signing and verification (XMLDSIG) in the .NET Framework. XMLDSIG is a standards-based, interoperable way to sign and verify all or part of an XML document or other data that is addressable from a Uniform Resource Identifier (URI). The .NET Framework XMLDSIG classes implement the World Wide Web Consortium (W3C) specification for XML signing and verification located at http://www.w3.org/TR/xmldsig-core/.

I hope this helps.

Regards,

Alex (Alejandro Campos Magencio)