M
Michael Zimdars
Hello,
I have a problem calling a SSL secured WebService (written in C#, .Net
Framework 1.1 SP1 running on IIS 5 on Windows Advanced Server 2003,en) via a
Windows Forms application (also C#, .Net 1.1 Sp1 running on Windows 2000 en).
The setup is as follows:
We have a Root CA that Issued a Certificate to an Intermediate CA. The
Intermediate CA signed both, the certificate for the IIS Website that is
hosting the WebService, and the Client Certificate used in the Windows Forms
Client.
This means the certificate chain looks something like this:
Root CA
Intermediate CA
WebService Certificate
and
Root CA
Intermediate CA
Client Certificate(s)
The WebService certificate has the website name as the CN.
On both, the server and the client, the Root CA was imported in the 'Trusted
Root Certification Authorities' store of the local machine and the user. The
same goes for the Intermediate CA Certificate, except that it is imported in
the 'Intermediate Certificate Authorities' store (again local machine and
user).
The WebService is running on its own (virtual) server. It uses TCP Port 81
and SSL Port 1234. The Web Servers Directory Security is configured as
follows:
- Anonymous access (as given as default)
- "Authenticated access" all turned off
- Server Certificate is configured as stated above (WebService certificate)
and is validated OK when 'view certificate' is clicked
- "Secure Communications" requires secure channel and accepts client
certificates. No certificate mapping is done, because we do _not_ want to use
windows user management. The web service has its own user management, which
relies on the client certificates.
With these settings we tried to connect to the WebService via IE.
The address is something like https://servername:1234. The entry of the
'.asmx' filename is not necessary, because the asmx script is configured
under 'documents', so the client is redirected automatically. Because the
certificate has the name "servername.orga.com", the Internet Explorer shows
the 'accept server certificate' screen where it mentions that the certificate
name does not match the name of the site. After accepting, we can choose the
Certificate for the connection and the method list of the WebService is shown.
A look in the 'Application Trace' of the WebService shows, that the CERT_xxx
Environment Variables are set correctly with the values of the client
certificate.
Now for the Windows application.
We built up the Windows application by taking the class that was generated
out of the WSDL document. We changed the URL to the URL of the server (which
should be configurable), Add a Certificate to the clientCertificates list.
The certificate is read from the 'current user' certificate store using a
CryptoAPI Wrapper Class. To follow the asmx redirect, we set the
'AllowAutoRedirect' property to true. To manage Cookies, we create a
CookieContainer and assign it to the WebService wrapper.
To accept the server certificate (even with the 'wrong' site name in it), we
create and assign a CertificatePolicy to the ServicePointManager, that
accepts the server certificate.
Now we call a method of the WebService and establish the connection.
Now we get different results on different PCs. On one PC of a colleague, the
client certificate is taken (again this can be seen in the application trace)
On my PC on the other hand, and on the PCs of any other colleague we tried,
we can see from the application trace, that the client certificate wasn't
taken and instead an intermediate certificate was generated.
So far, we could not discover, what the colleague did, that he can connect
using his certificate. The Certificates, the entries in the Certifticate
store, .NEt Framework version and Patchlevel, machine.config, etc. all look
the same.
After debugging the connection establishment in the bytecode (what a pain,
where is the source code of these classes?), we could discover the methods
called after all (because the method names are shown in the call stack). You
can see, how the ClientCertificate list is read by the (internal)
SecureChannel class. It seems like it checks the certificate fingerprints
against a value it got from somewhere. After some rounds through the
CLientCertificate list, it goes to a method, that apparently generates a
default certificate for the connection (I don't remember the name of the
method, sorry).
If we configure the IIS to 'require' certificates, we can see (as
excepcted), that the IIS generates the error 403, substatus 7 (Access
Forbidden, Client Certificate required). Naturally, the WebService isn't
called in that case.
After a week of Investigation in several newsgroups and blogs, we saw, that
some other people had the exact same problem, but an answer was given
nowhere, except the things we had done already. So any suggestions are
greatly appreciated.
thanks,
Michael Zimdars
I have a problem calling a SSL secured WebService (written in C#, .Net
Framework 1.1 SP1 running on IIS 5 on Windows Advanced Server 2003,en) via a
Windows Forms application (also C#, .Net 1.1 Sp1 running on Windows 2000 en).
The setup is as follows:
We have a Root CA that Issued a Certificate to an Intermediate CA. The
Intermediate CA signed both, the certificate for the IIS Website that is
hosting the WebService, and the Client Certificate used in the Windows Forms
Client.
This means the certificate chain looks something like this:
Root CA
Intermediate CA
WebService Certificate
and
Root CA
Intermediate CA
Client Certificate(s)
The WebService certificate has the website name as the CN.
On both, the server and the client, the Root CA was imported in the 'Trusted
Root Certification Authorities' store of the local machine and the user. The
same goes for the Intermediate CA Certificate, except that it is imported in
the 'Intermediate Certificate Authorities' store (again local machine and
user).
The WebService is running on its own (virtual) server. It uses TCP Port 81
and SSL Port 1234. The Web Servers Directory Security is configured as
follows:
- Anonymous access (as given as default)
- "Authenticated access" all turned off
- Server Certificate is configured as stated above (WebService certificate)
and is validated OK when 'view certificate' is clicked
- "Secure Communications" requires secure channel and accepts client
certificates. No certificate mapping is done, because we do _not_ want to use
windows user management. The web service has its own user management, which
relies on the client certificates.
With these settings we tried to connect to the WebService via IE.
The address is something like https://servername:1234. The entry of the
'.asmx' filename is not necessary, because the asmx script is configured
under 'documents', so the client is redirected automatically. Because the
certificate has the name "servername.orga.com", the Internet Explorer shows
the 'accept server certificate' screen where it mentions that the certificate
name does not match the name of the site. After accepting, we can choose the
Certificate for the connection and the method list of the WebService is shown.
A look in the 'Application Trace' of the WebService shows, that the CERT_xxx
Environment Variables are set correctly with the values of the client
certificate.
Now for the Windows application.
We built up the Windows application by taking the class that was generated
out of the WSDL document. We changed the URL to the URL of the server (which
should be configurable), Add a Certificate to the clientCertificates list.
The certificate is read from the 'current user' certificate store using a
CryptoAPI Wrapper Class. To follow the asmx redirect, we set the
'AllowAutoRedirect' property to true. To manage Cookies, we create a
CookieContainer and assign it to the WebService wrapper.
To accept the server certificate (even with the 'wrong' site name in it), we
create and assign a CertificatePolicy to the ServicePointManager, that
accepts the server certificate.
Now we call a method of the WebService and establish the connection.
Now we get different results on different PCs. On one PC of a colleague, the
client certificate is taken (again this can be seen in the application trace)
On my PC on the other hand, and on the PCs of any other colleague we tried,
we can see from the application trace, that the client certificate wasn't
taken and instead an intermediate certificate was generated.
So far, we could not discover, what the colleague did, that he can connect
using his certificate. The Certificates, the entries in the Certifticate
store, .NEt Framework version and Patchlevel, machine.config, etc. all look
the same.
After debugging the connection establishment in the bytecode (what a pain,
where is the source code of these classes?), we could discover the methods
called after all (because the method names are shown in the call stack). You
can see, how the ClientCertificate list is read by the (internal)
SecureChannel class. It seems like it checks the certificate fingerprints
against a value it got from somewhere. After some rounds through the
CLientCertificate list, it goes to a method, that apparently generates a
default certificate for the connection (I don't remember the name of the
method, sorry).
If we configure the IIS to 'require' certificates, we can see (as
excepcted), that the IIS generates the error 403, substatus 7 (Access
Forbidden, Client Certificate required). Naturally, the WebService isn't
called in that case.
After a week of Investigation in several newsgroups and blogs, we saw, that
some other people had the exact same problem, but an answer was given
nowhere, except the things we had done already. So any suggestions are
greatly appreciated.
thanks,
Michael Zimdars