HTTPS Send Port + Client Certificate Authentication

[Doug]

Hi

I'm having a final shot at getting some advice on this! This time I'm using
my shiny new "nospam" email alias, so hopefully someone at Microsoft MSDN
will take a look and comment.

I have BizTalk Server 2004 with an HTTP send port configured to post an XML
file to an https URL. Proxy is set to "Don't use". Under the authentication
tab I have Authentication Type set to Anonymous (I've also tried Kerberos),
but have a valid SSL client certifcate thumbprint set. The client certificate
is in the Personal store of the account BizTalk runs as.

On the target system (where the URL points to) IIS is set to require SSL and
require client certificates The certificate is mapped to a local windows
account. All other authentication methods are disabled.

Whenever I try sending via the send port, the message is suspended with the
error "The remote server returned an error: (403) Forbidden."

I know that the BizTalk server is capable of authenticating and HTTP posting
because I can logon as the BizTalk account and run a small vbs script which
uses WinHttpRequest (using SetCredentials to specify the same client
certificate) to post a file to the web server, and this works OK.

What have I missed? It would be good if someone could confirm that they have
this working.

Thanks in advance.

[WenJun Zhang[msft]]

Hi Doug,

To address the problem, you should first determine which the exact
kind of 403 errors was returned by the remote web server. All the 403
errors defined in IIS are:

403 - Forbidden. IIS defines a number of different 403 errors that
indicate a more specific cause of the error:
403.1 - Execute access forbidden.
403.2 - Read access forbidden.
403.3 - Write access forbidden.
403.4 - SSL required.
403.5 - SSL 128 required.
403.6 - IP address rejected.
403.7 - Client certificate required.
403.8 - Site access denied.
403.9 - Too many users.
403.10 - Invalid configuration.
403.11 - Password change.
403.12 - Mapper denied access.
403.13 - Client certificate revoked.
403.14 - Directory listing denied.
403.15 - Client Access Licenses exceeded.
403.16 - Client certificate is untrusted or invalid.
403.17 - Client certificate has expired or is not yet valid.
403.18 - Cannot execute requested URL in the current application
pool. This error code is specific to IIS 6.0.
403.19 - Cannot execute CGIs for the client in this application
pool. This error code is specific to IIS 6.0.
403.20 - Passport logon failed. This error code is specific to IIS
6.0.

If the web server is IIS6 on Win2K3, you can collect the web site's
IIS log in \Windows\System32\Logfiles\W3SVC[SiteID] directory. Search
the request records from your Biztalk machine, the sc-status field is
server return code which should be 403 and the next sc-substatus
field is the required subcode.

Furthermore, I wonder if you install the client certificate into your
correct logon account's Personal store and then access the web site
via IE, what will happen? Will it properly prompt you to select the
client certificate from dialog?

Please let me know if you get any progress or findings.
Thanks.

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[Doug]

Many thanks for the response. Sorry for the delay in getting back to you.

I now have this working OK. I tried a different client certificate (trial
Verisign DigitalID) and it works!

My guess is that BizTalk is fussy about the type of certificate being used.
Do you have any further information on this?

The certificate that does work reports purposes of "Protects e-mail
messages" and "Proves your identity to a remote computer". The certificate I
couldn't get to work (a Verisign SSL certificate) reports "Ensures the
identity of a remote computer" and "2.16.840.1.113733.1.7.1.1" (whatever that
means!). I guess it's the "Proves your identity to a remote computer" which
is the important bit.

The curious thing is that both certificates worked OK in a test vbs script I
wrote, which uses WinHttpRequest to submit XML documents to the URL, using
SetClientCertificate to specify the certificate. If WinHttpRequest is OK with
the certificate, and the remote site is also happy to accept it and map to a
local user account, then why can't BizTalk use it?

If BizTalk does not like the certificate, it would be more useful if the
send failed and a sensible error reported, rather than sending the document
anyway with no client certificate.

I would welcome your feedback.

Regards

Doug

Post by WenJun Zhang[msft]
Hi Doug,
To address the problem, you should first determine which the exact
kind of 403 errors was returned by the remote web server. All the 403
403 - Forbidden. IIS defines a number of different 403 errors that
403.1 - Execute access forbidden.
403.2 - Read access forbidden.
403.3 - Write access forbidden.
403.4 - SSL required.
403.5 - SSL 128 required.
403.6 - IP address rejected.
403.7 - Client certificate required.
403.8 - Site access denied.
403.9 - Too many users.
403.10 - Invalid configuration.
403.11 - Password change.
403.12 - Mapper denied access.
403.13 - Client certificate revoked.
403.14 - Directory listing denied.
403.15 - Client Access Licenses exceeded.
403.16 - Client certificate is untrusted or invalid.
403.17 - Client certificate has expired or is not yet valid.
403.18 - Cannot execute requested URL in the current application
pool. This error code is specific to IIS 6.0.
403.19 - Cannot execute CGIs for the client in this application
pool. This error code is specific to IIS 6.0.
403.20 - Passport logon failed. This error code is specific to IIS
6.0.
If the web server is IIS6 on Win2K3, you can collect the web site's
IIS log in \Windows\System32\Logfiles\W3SVC[SiteID] directory. Search
the request records from your Biztalk machine, the sc-status field is
server return code which should be 403 and the next sc-substatus
field is the required subcode.
Furthermore, I wonder if you install the client certificate into your
correct logon account's Personal store and then access the web site
via IE, what will happen? Will it properly prompt you to select the
client certificate from dialog?
Please let me know if you get any progress or findings.
Thanks.
Best regards,
WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[WenJun Zhang[msft]]

Hi Doug,

Sounds like the issue is hard to be reproduced.. Do you make sure the
Verisign cert is trusted by both the remote IIS machine and the
Biztalk machine?(install its CA cert in Computer account's trust root
CA store)

Also as I mentioned before if you use the client cert in IE to
manually authenticate against that web site, what's the result?

Thanks.

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[Doug]

It's easy to reproduce the behaviour - I just don't know why it happening!

So the situation is this:

IIS 5.0 web server. ASP page with ACL such that only one local Windows user
account has read/execute permission. All authentication methods unchecked in
IIS (anonymous, basic, integrated, etc.). Under "Secure communications",
settings are to require SSL and client certificate, and a map is in place
between the public certificate and the local windows account which has access
to the ASP page.

On the BizTalk box, I have two certifcates available to me as previously
described - a trial Verisign DigitalID and a Verisign SSL certificate. The
first certificate works in all respects, the second does not.

With the trial Verisign DigitalID:
- public key is exported and used in the account mapping in IIS
- certificate is in the Personal store of the BizTalk 2004 user account
- when logged on as the BizTalk user, can access the ASP page in IE
without problem
- can run a VBS script using WinHttpRequest to post XML to the ASP page
(using SetClientCertificate to specify the certificate)
- BizTalk HTTP send port works fine using the thumbprint of this certificate


With the SSL certificate:
- public key is exported and used in the account mapping in IIS
- certificate is in the Personal store of the BizTalk 2004 user account
- when logged on as the BizTalk user, CANNOT access the ASP page in IE.
Get a return code 403.7 Client certificate required
- however, CAN run the VBS script using WinHttpRequest to post XML to the
ASP page
- BizTalk messages are suspended with a 403 error code


So it would appear that both BizTalk and IE don't like the SSL certificate
for some reason, whereas WinHttpRequest is less fussy.

Note that the SSL certificate is in current use on a BizTalk 2000 machine,
and is working fine as both a SSL certificate and a client certificate. Does
this mean that when we migrate to BizTalk 2004 we'll need two separate
certificates - one to enable SSL communications and another for client
authentication on remote systems?

Regards

Doug

[WenJun Zhang[msft]]

Doug,

"Does this mean that when we migrate to BizTalk 2004 we'll need two
separate certificates - one to enable SSL communications and another
for client authentication on remote systems?"

Yes, this should be the problem. I know at least client
authentication certificates created by windows certificate service
will not work as Web server certificate(for server authentication).
Also in a common SSL scenario, it doesn't make sense that the server
cert can be obtained and used by clients, right?

Thanks.

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[Doug]

Hi

Sure, I agree that it should not be possible for a client certificate
to be used as a server certificate, but I don't think the reverse is
necessarily true.

This is proven by the fact WinHttpRequest and BizTalk Server 2000 are
both happy to use a server certificate as a client certificate. BizTalk
Server 2004 obviously works differently, and it's a shame that there's
no help or documentation (that I can find) which details certificate
pre-requisites.

When a server certificate is used in a SSL scenario it is always only
the PUBLIC key which the client obtains. Therefore, although the client
can (and indeed must) get the server certicate when using SSL, it's
impossible for the client to then use the same certificate for client
authentication, as this requires the client to hold the private key also.

I guess there's nothing we can do except purchase separate server and
client certificates.

Regards

Doug

[WenJun Zhang[msft]]

"I guess there's nothing we can do except purchase separate server
and client certificates."

Yes, this should be the appropriate plan currently, and I agree use
web server cert as client cert should be possible.. the only guess is
the cert may not be trusted or validated properly. Have you used a
sever certificate issued from Windows CA to have a test?

Thanks.

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[Doug]

Hi

Thanks for the response, and apologies for the delay in relpying.

I'm happy that you think it should be possible to use a web server cert as a
client cert. As I say, BTS 2000 and WinHttp are happy to do so.

The certificate that BTS 2004 is not happy with is from Verisign, so it
should be trusted OK. If it were not, I think BTS 2000 and WinHttp would
object.

I haven't tried a self generated server certificate from Windows CA. If I
get time I'll give it a go. However, this is not a solution as our trading
partners will not allow us to use self generated certicates for client
authentication. They must come from a trusted third party such as Verisign.

Surely somewhere in Microsoft someone must know why a certificate is
acceptable to BTS2000 but not BTS2004?? It would be good to get a definitive
explanation.

Regards

Doug Hughes

Post by WenJun Zhang[msft]
"I guess there's nothing we can do except purchase separate server
and client certificates."
Yes, this should be the appropriate plan currently, and I agree use
web server cert as client cert should be possible.. the only guess is
the cert may not be trusted or validated properly. Have you used a
sever certificate issued from Windows CA to have a test?
Thanks.
Best regards,
WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[WenJun Zhang[msft]]

Hi Doug,

That's ok. I'll distribute an email to our world wide Biztalk group
to discuss this issue. Hopefully somebody might have seen the some
case and could give a solid explanation.

Also it'll be better if you can export the problematic cert and send
to me for a test:

v-***@online.microsoft.com (please remove online.)

Thanks.

Best regards,

WenJun Zhang
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no
rights.