Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CERT_CHAIN_POLICY_STATUS Error 2148204810

512 views
Skip to first unread message

Dmitri

unread,
Oct 24, 2003, 6:34:46 AM10/24/03
to
Hello,

I'm using WSE 2.0 in simple peer-to-peer scenario via TCP/IP (server is a
console application, client is a WinForm).
All work just fine except for when I try to sign message on client and I get
an exception (in RequestResponseMethod):
"Invalid security token was provided. The certificate trust chain could not
be verified. CERT_CHAIN_POLICY_STATUS returned error 2148204810"

I have installed sample Client certificate which chained with test root
certificate (CN=Root Agency).
Everything done according documentation - certificate gotten, token added,
etc...

I tried to sign file (just to check crypto functions work) using singcode
utility - it works and chktrsust shows it's OK.

Further investigtion showed that 2148204810 error code corresponds to "An
internal certificate chaining error has occurred. "

Can you help with this issue?

Thanks

Dmitri


Dmitri

unread,
Oct 24, 2003, 7:32:11 AM10/24/03
to
More data....

Looking to trace files and setting breakpoints gave info that server-side
gets message, but processing doesn't get to RequestResponseMethod.

I'm only able to catch executing in FilterMessage overrided function.
Interesting enough that envelope.Context.Security.Tokens.Count == 0

But in message I can see Signature and <wsse:BinarySecurityToken
ValueType="wsse:X509v3" .... elements


"Dmitri" <dima...@hotmail.com> wrote in message
news:uNGiKqhm...@TK2MSFTNGP10.phx.gbl...

Benjamin Mitchell

unread,
Oct 24, 2003, 11:58:03 AM10/24/03
to
I'm not sure if this will help, but have you read this [1] recent post on
X.509 certificates and WSE:

"WSE is a bit peculiar on which keys it will find usable. The keys and
certificates need to be placed in the correct certificate container, such as
current user or local machine, so that the application can find them. The
corresponding private keys need to be readable by the application process
that accesses them. This is well documented in WSE, but easy to miss.

What isn't well documented is the fact that the certificates must have an
exact set of X.509 critical extensions: Digital Signature, Non-Repudiation,
Key Encipherment, and Data Encipherment (F0). It is important that these
extensions are marked critical for .NET WSE to acknowledge these keys. This
goes for both 1.0 and 2.0 TP. You need Data Encipherment if you plan to use
the key for WS-Security with encryption."

http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=1006be9b.0309251026.6472efc9%40posting.google.com

Hope that helps.

Cheers,

Benjamin Mitchell
Consultant, Axxiant Limited
blog: http://www.benjaminm.net/

"Dmitri" <dima...@hotmail.com> wrote in message

news:uiahRKi...@TK2MSFTNGP11.phx.gbl...

Lucien

unread,
Oct 27, 2003, 1:51:01 PM10/27/03
to
Try to disable X509 trust verification. Add this to web.config:

<microsoft.web.services>

<security>

<x509 allowTestRoot="true" allowRevocationUrlRetrieval="false"
verifyTrust="false" />


"Dmitri" <dima...@hotmail.com> wrote in message

news:uiahRKi...@TK2MSFTNGP11.phx.gbl...

Dmitri

unread,
Oct 28, 2003, 5:30:50 AM10/28/03
to
I did all this things, doesn't help :(

In docs I found that digital signing supprted only in ASP.NET case. Is it
correct?

My problem seems to come on server side, because I can get message in
FilterMessage method there.

So it turns out I generally can sign message and send them via TCP/IP but
have no automatic mechanism to support this in WSE 2.0 and need to write
custom DSIG handler.


"Lucien" <*lucien*@MicrosoftAccount.com> wrote in message
news:egRsFtL...@TK2MSFTNGP12.phx.gbl...

Lucien

unread,
Oct 28, 2003, 12:28:20 PM10/28/03
to
No that doesn't seem right. Could you post the client code? And could you
post the entire callstack?

Thanks,
Lucien


"Dmitri" <dima...@hotmail.com> wrote in message

news:%23JyIu6T...@TK2MSFTNGP12.phx.gbl...

Dmitri

unread,
Oct 29, 2003, 9:14:41 AM10/29/03
to
Resolved!

Thanks!

Solution: Must set "Allow trust root" to True and "Verify trust" to False ON
THE SERVER SIDE TOO, not only on caller side.

May be it's worth to highlight this in doc?

Dmitri


"Lucien" <*lucien*@MicrosoftAccount.com> wrote in message

news:eNJfijXn...@TK2MSFTNGP11.phx.gbl...

Lucien

unread,
Oct 29, 2003, 2:22:28 PM10/29/03
to
You should not need this on the client side unless you receive signed
responses with this certificate.
Also you should not set 'verify trust' to false unless you use these test
certificates (which are for testing only and should not be used
in production system).


"Dmitri" <dima...@hotmail.com> wrote in message

news:OIHRjcin...@TK2MSFTNGP09.phx.gbl...

0 new messages