Client certificate private key prompt
Berndt Johansson
Is there anyone that have had problems with multiple private key prompting
when performing a simple HttpWebRequest.GetResponse(). The client
certificate is installed with the "Enable strong private key protection....
" option. The server is configured to require SSL and a client certificate.
When the GetResponse is called, the Protected Item prompt will be displayed
twice instead of, as expected, once (see code below).
Later when I make the first call to a webservice, through a vs.net generated
proxy object I get another prompt, altoghether three prompts. This is during
our login, so it is quite annoying. When the application is up and running,
the prompting does not appear for subsequent calls to webservices.
I cannot understand this behaviour. Is there anyone that knows anything
about this or maybe have identified a workaround. The most obvious
workaround would be to stop using the "Strong private key protection"
option, but you know, the customer's request is our law. :-)
Dim request As System.Net.HttpWebRequest =
CType(HttpWebRequest.Create(Common.GetProtocol & EXIGOInstance &
"/API//CMyServiceAPI.asmx"), HttpWebRequest)
request.Method = "GET"
request.Credentials = cred
request.Proxy = Common.CurrentProxy
If Not Common.Certificate Is Nothing Then
request.ClientCertificates.Add(Common.Certificate)
request.GetResponse()
Peter Huang
Based on my test, I can not reproduce the problem, the Protected Item
dialog will be pop up just once in the code line as below.
HttpWebResponse myHttpWebResponse = (HttpWebResponse)req.GetResponse();
Firstly I think you may try to access to the webservice in the internet
explorer first, did the dialog will pop up once or twice?
Here is my test code.
using System;
using System.Net;
using System.Security.Cryptography.X509Certificates;
using System.IO;
namespace CerTest
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
//create webRequest
string url="https://sha-vphuang-05/HttpsWebService/Service1.asmx";
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url);
//add credentials
req.Credentials = CredentialCache.DefaultCredentials;
//add cert
X509Certificate m_cert =
X509Certificate.CreateFromCertFile(@"c:\testcer.cer");
req.ClientCertificates.Add(m_cert);
req.Method="GET";
//Now get response
HttpWebResponse myHttpWebResponse = (HttpWebResponse)req.GetResponse();
// Gets the stream associated with the response.
Stream receiveStream = myHttpWebResponse.GetResponseStream();
System.Text.Encoding encode = System.Text.Encoding.GetEncoding("utf-8");
// Pipes the stream to a higher level stream reader with the required
encoding format.
StreamReader readStream = new StreamReader( receiveStream, encode );
Console.WriteLine("\r\nResponse stream received.");
Char[] read = new Char[256];
// Reads 256 characters at a time.
int count = readStream.Read( read, 0, 256 );
Console.WriteLine("HTML...\r\n");
while (count > 0)
{
// Dumps the 256 characters on a string and displays the string to the
console.
String str = new String(read, 0, count);
Console.Write(str);
count = readStream.Read(read, 0, 256);
}
Console.WriteLine("");
// Releases the resources of the response.
myHttpWebResponse.Close();
// Releases the resources of the Stream.
readStream.Close();
abce.Service1 s = new abce.Service1();
Console.WriteLine(s.HelloWorld().ToString());
}
}
}
So please try my code on the machine where the webservice is located on,
that is to say we may try to run the console application to access the
local webservice first, so that we can isolate the problem.
Also if the problem still persists, can you tell me which code line cause
the dialog pop up twice.
Best regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
Berndt Johansson
I tried your project and that works as expected, but try only Basic
Authentication (no anonymous and no Integrated authentication) and create a
NetworkCredential with the username and password and throw it into the
credentials property. When calling GetResponse now, I now get two prompts.
//add credentials
NetworkCredential cred = new NetworkCredential("testuser", "password");
req.Credentials = cred;
/Berndt
""Peter Huang"" <v-ph...@online.microsoft.com> wrote in message
news:doEgDrrT...@cpmsftngxa10.phx.gbl...
Peter Huang
I also try to use the Basic Authentication only, but I can not reproduce
the problem, i.e. the Protected Item Dialog will pop up just once.
So I assume your senario is that when the code goes to the line below when
you use the Basic Authentication.
HttpWebResponse myHttpWebResponse = (HttpWebResponse)req.GetResponse();
the Protected Item Dialog will pop up and you press OK, and the same dialog
will pop up again and you press OK again then the code will run and write
out the response.
Am I right?
As for the Basic authentication, what do you set for the Default Domain in
the IIS setting for the https website?
You may try to set the default domain so that we do not need to specified
in the code.
Also as I said before, you may try to do the same thing in the IE to see if
the problem persists.
Berndt Johansson
Yes, I use Basic authentication with a locally created account. I have
disabled any other option in Directory Security except Basic Authentication
and put localhost as Realm. And in the Secure communications section I have
put require SSL and Client certificate.
Yes the GetResponse in the code below will give me two prompts rather than
one before getting to the GetResponseStream row in the debugger.
The Default domain was left empty and the Realm set to localhost.If I put
localhost in the Default domain, I'll get Access Denied and when I left it
empty it'll work.
If I paste the URL into IE I will get a client certificate prompt and when I
have selected the client certificate I one Protected Item prompt as
expected, so this works perfectly as it should.
Also included the code that I am running. It is a slightly modified version
of you test program.
/Berndt
using System;
using System.Net;
using System.Security.Cryptography.X509Certificates;
using System.IO;
namespace CerTest
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
//create webRequest
string url="https://se10lt0242/WebService2/Service1.asmx";
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url);
//add credentials
NetworkCredential cred = new NetworkCredential("user1234", "1234");
req.Credentials = cred;
//add cert
X509Certificate m_cert =
X509Certificate.CreateFromCertFile(@"c:\own.cer");
req.ClientCertificates.Add(m_cert);
req.Method="GET";
//Now get response
HttpWebResponse myHttpWebResponse = (HttpWebResponse)req.GetResponse();
Stream receiveStream = myHttpWebResponse.GetResponseStream();
while (count > 0)
{
Console.Write(str);
}
Console.WriteLine("");
myHttpWebResponse.Close();
readStream.Close();
s.Url= url;
//s.Credentials = cred;
s.ClientCertificates.Add(m_cert);
Console.WriteLine(s.HelloWorld().ToString());
}
}
}
""Peter Huang"" <v-ph...@online.microsoft.com> wrote in message
news:T7Q$$T2TEH...@cpmsftngxa10.phx.gbl...
Berndt Johansson
Are you running on IIS 5 or 6?
Some further findings....
If I do the following
string auth;
auth =
Convert.ToBase64String(System.Text.Encoding.ASCII.GetBytes(cred.UserName +
":" + cred.Password));
req.Headers["Authorization"] = "Basic " + auth;
before the GetResponse call, I will only get one prompt. For some reason or
other, there must be a request being sent to the server without the header
that is later re-sent again causing the Private key to be retrived twice. I
don't understand this and I am puzzled by the fact that our clients behave
differently.....
Can you draw any conclusions to this?
/Berndt
""Peter Huang"" <v-ph...@online.microsoft.com> wrote in message
news:T7Q$$T2TEH...@cpmsftngxa10.phx.gbl...
Peter Huang
I tested on IIS6.
I think now you may try to post the iis log under the directory below
usually.
C:\WINDOWS\system32\LogFiles\W3SVC1045851656
Please specified the correct directory, the 1045851656 is identity of your
website.
Please remove the logfile in the directory first(you may backup into
another directory).
Now try to reproduce the problem with credential(not using the header),
which the dialog will pop up twice in your side and then post the iis log
about the fact when you using the code that access the website.
NOTE: in my side, there will be just one line of log when I use the
credential.
Berndt Johansson
Yes, there are two entries for the GET in the logfile, one without the
credentials and with the credentials. I doesn't make any difference if I use
PreAuthenticate = true before the request either.
#Software: Microsoft Internet Information Services 5.1
#Version: 1.0
#Date: 2004-06-15 06:06:08
#Fields: time c-ip cs-username cs-method cs-uri-stem sc-status
06:06:08 10.112.136.157 - GET /WebService2/Service1.asmx 401
06:06:12 10.112.136.157 user1234 GET /WebService2/Service1.asmx 200
06:06:15 10.112.136.157 user1234 POST /WebService2/Service1.asmx 200
""Peter Huang"" <v-ph...@online.microsoft.com> wrote in message
news:JShKdWoU...@cpmsftngxa10.phx.gbl...
Peter Huang
Can you post the detailed information about your environment so that I can
reproduce the problem on my side?
e.g.
Windows XP+SP1, IIS 5,VS.NET 2003, .NET framework 1.1 and so on.
Berndt Johansson
Just tried to run the test application against a WebService on an IIS 6
server (on Windows 2003 Server). That worked fine. When looking at the
network traffic using Ethereal there is a difference in behaviour with
regards to the connection. IIS 5 closes the connection whereas IIS 6
maintains the connection. Don't you think that this is reason for the double
prompting? But what is the difference between my setup and your's?
My configuration is XP Pro SP1, IIS 5, VS.NET 2003, .NET FX 1.1. I am
running both the IIS server and the client application on my developer
machine. When I tried the IIS 6 I copied the WebService application to an
Windows Server 2003 server without the Header manually added to the request.
Below is an excerpt from the ethereal result. Sorry for the big post...
Frame 34 will be closing the connection. This is not happening on IIS 6.
Do you think that it is a good idea to keep posting this or should we use
emails instead?
/Berndt
No. Time Source Destination Protocol
Info Port
1 0.000000 10.112.136.88 10.112.136.127 NETLOGON SAM
LOGON request from client netbios-dgm
No. Time Source Destination Protocol
Info Port
33 6.095175 10.112.136.76 10.112.136.157 TCP
2954 > https [ACK] Seq=1621 Ack=9979 Win=65239 Len=0 https
Frame 33 (54 bytes on wire, 54 bytes captured)
Arrival Time: Jun 16, 2004 10:19:23.361175000
Time delta from previous packet: 0.000014000 seconds
Time since reference or first frame: 6.095175000 seconds
Frame Number: 33
Packet Length: 54 bytes
Capture Length: 54 bytes
Ethernet II, Src: 00:08:02:b7:9a:dd, Dst: 00:0e:83:55:ef:00
Destination: 00:0e:83:55:ef:00 (Cisco_55:ef:00)
Source: 00:08:02:b7:9a:dd (CompaqCo_b7:9a:dd)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.112.136.76 (10.112.136.76), Dst Addr:
10.112.136.157 (10.112.136.157)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x7d7b (32123)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x578b (correct)
Source: 10.112.136.76 (10.112.136.76)
Destination: 10.112.136.157 (10.112.136.157)
Transmission Control Protocol, Src Port: 2954 (2954), Dst Port: https (443),
Seq: 1621, Ack: 9979, Len: 0
Source port: 2954 (2954)
Destination port: https (443)
Sequence number: 1621 (relative sequence number)
Acknowledgement number: 9979 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65239
Checksum: 0xac34 (correct)
SEQ/ACK analysis
This is an ACK to the segment in frame: 32
The RTT to ACK the segment was: 0.000014000 seconds
No. Time Source Destination Protocol
Info Port
34 6.095184 10.112.136.157 10.112.136.76 TCP
https > 2954 [FIN, ACK] Seq=9979 Ack=1621 Win=64512 Len=0 2954
LOOK HERE!!!
Frame 34 (60 bytes on wire, 60 bytes captured)
Arrival Time: Jun 16, 2004 10:19:23.361184000
Time delta from previous packet: 0.000009000 seconds
Time since reference or first frame: 6.095184000 seconds
Frame Number: 34
Packet Length: 60 bytes
Capture Length: 60 bytes
Ethernet II, Src: 00:0e:83:55:ef:00, Dst: 00:08:02:b7:9a:dd
Destination: 00:08:02:b7:9a:dd (CompaqCo_b7:9a:dd)
Source: 00:0e:83:55:ef:00 (Cisco_55:ef:00)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol, Src Addr: 10.112.136.157 (10.112.136.157), Dst Addr:
10.112.136.76 (10.112.136.76)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x284b (10315)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 126
Protocol: TCP (0x06)
Header checksum: 0xaebb (correct)
Source: 10.112.136.157 (10.112.136.157)
Destination: 10.112.136.76 (10.112.136.76)
Transmission Control Protocol, Src Port: https (443), Dst Port: 2954 (2954),
Seq: 9979, Ack: 1621, Len: 0
Source port: https (443)
Destination port: 2954 (2954)
Sequence number: 9979 (relative sequence number)
Acknowledgement number: 1621 (relative ack number)
Header length: 20 bytes
Flags: 0x0011 (FIN, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...1 = Fin: Set
Window size: 64512
Checksum: 0xaf0a (correct)
No. Time Source Destination Protocol
Info Port
35 6.095195 10.112.136.76 10.112.136.157 TCP
2954 > https [ACK] Seq=1621 Ack=9980 Win=65239 Len=0 https
Frame 35 (54 bytes on wire, 54 bytes captured)
Arrival Time: Jun 16, 2004 10:19:23.361195000
Time delta from previous packet: 0.000011000 seconds
Time since reference or first frame: 6.095195000 seconds
Frame Number: 35
Packet Length: 54 bytes
Capture Length: 54 bytes
Ethernet II, Src: 00:08:02:b7:9a:dd, Dst: 00:0e:83:55:ef:00
Destination: 00:0e:83:55:ef:00 (Cisco_55:ef:00)
Source: 00:08:02:b7:9a:dd (CompaqCo_b7:9a:dd)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.112.136.76 (10.112.136.76), Dst Addr:
10.112.136.157 (10.112.136.157)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x7d7c (32124)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x578a (correct)
Source: 10.112.136.76 (10.112.136.76)
Destination: 10.112.136.157 (10.112.136.157)
Transmission Control Protocol, Src Port: 2954 (2954), Dst Port: https (443),
Seq: 1621, Ack: 9980, Len: 0
Source port: 2954 (2954)
Destination port: https (443)
Sequence number: 1621 (relative sequence number)
Acknowledgement number: 9980 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65239
Checksum: 0xac33 (correct)
SEQ/ACK analysis
This is an ACK to the segment in frame: 34
The RTT to ACK the segment was: 0.000011000 seconds
No. Time Source Destination Protocol
Info Port
36 6.099015 Cisco_55:ef:20 Spanning-tree-(for-bridges)_00 STP
Conf. Root = 32778/00:0e:83:55:ef:00 Cost = 0 Port = 0x8020
Frame 36 (60 bytes on wire, 60 bytes captured)
Arrival Time: Jun 16, 2004 10:19:23.365015000
Time delta from previous packet: 0.003820000 seconds
Time since reference or first frame: 6.099015000 seconds
Frame Number: 36
Packet Length: 60 bytes
Capture Length: 60 bytes
IEEE 802.3 Ethernet
Destination: 01:80:c2:00:00:00 (Spanning-tree-(for-bridges)_00)
Source: 00:0e:83:55:ef:20 (Cisco_55:ef:20)
Length: 38
Trailer: 0000000000000000
Logical-Link Control
DSAP: Spanning Tree BPDU (0x42)
IG Bit: Individual
SSAP: Spanning Tree BPDU (0x42)
CR Bit: Command
Control field: U, func=UI (0x03)
000. 00.. = Command: Unnumbered Information (0x00)
.... ..11 = Frame type: Unnumbered frame (0x03)
Spanning Tree Protocol
Protocol Identifier: Spanning Tree Protocol (0x0000)
Protocol Version Identifier: Spanning Tree (0)
BPDU Type: Configuration (0x00)
BPDU flags: 0x00
0... .... = Topology Change Acknowledgment: No
.... ...0 = Topology Change: No
Root Identifier: 32778 / 00:0e:83:55:ef:00
Root Path Cost: 0
Bridge Identifier: 32778 / 00:0e:83:55:ef:00
Port identifier: 0x8020
Message Age: 0
Max Age: 20
Hello Time: 2
Forward Delay: 15
No. Time Source Destination Protocol
Info Port
37 6.104466 10.112.136.76 10.112.136.157 TCP
2954 > https [FIN, ACK] Seq=1621 Ack=9980 Win=65239 Len=0 https
Frame 37 (54 bytes on wire, 54 bytes captured)
Arrival Time: Jun 16, 2004 10:19:23.370466000
Time delta from previous packet: 0.009271000 seconds
Time since reference or first frame: 6.104466000 seconds
Frame Number: 37
Packet Length: 54 bytes
Capture Length: 54 bytes
Ethernet II, Src: 00:08:02:b7:9a:dd, Dst: 00:0e:83:55:ef:00
Destination: 00:0e:83:55:ef:00 (Cisco_55:ef:00)
Source: 00:08:02:b7:9a:dd (CompaqCo_b7:9a:dd)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.112.136.76 (10.112.136.76), Dst Addr:
10.112.136.157 (10.112.136.157)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x7d7d (32125)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x5789 (correct)
Source: 10.112.136.76 (10.112.136.76)
Destination: 10.112.136.157 (10.112.136.157)
Transmission Control Protocol, Src Port: 2954 (2954), Dst Port: https (443),
Seq: 1621, Ack: 9980, Len: 0
Source port: 2954 (2954)
Destination port: https (443)
Sequence number: 1621 (relative sequence number)
Acknowledgement number: 9980 (relative ack number)
Header length: 20 bytes
Flags: 0x0011 (FIN, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...1 = Fin: Set
Window size: 65239
Checksum: 0xac32 (correct)
No. Time Source Destination Protocol
Info Port
38 6.104823 10.112.136.157 10.112.136.76 TCP
https > 2954 [ACK] Seq=9980 Ack=1622 Win=64512 Len=0 2954
Frame 38 (60 bytes on wire, 60 bytes captured)
Arrival Time: Jun 16, 2004 10:19:23.370823000
Time delta from previous packet: 0.000357000 seconds
Time since reference or first frame: 6.104823000 seconds
Frame Number: 38
Packet Length: 60 bytes
Capture Length: 60 bytes
Ethernet II, Src: 00:0e:83:55:ef:00, Dst: 00:08:02:b7:9a:dd
Destination: 00:08:02:b7:9a:dd (CompaqCo_b7:9a:dd)
Source: 00:0e:83:55:ef:00 (Cisco_55:ef:00)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol, Src Addr: 10.112.136.157 (10.112.136.157), Dst Addr:
10.112.136.76 (10.112.136.76)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 40
Identification: 0x284c (10316)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 126
Protocol: TCP (0x06)
Header checksum: 0xaeba (correct)
Source: 10.112.136.157 (10.112.136.157)
Destination: 10.112.136.76 (10.112.136.76)
Transmission Control Protocol, Src Port: https (443), Dst Port: 2954 (2954),
Seq: 9980, Ack: 1622, Len: 0
Source port: https (443)
Destination port: 2954 (2954)
Sequence number: 9980 (relative sequence number)
Acknowledgement number: 1622 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 64512
Checksum: 0xaf09 (correct)
SEQ/ACK analysis
This is an ACK to the segment in frame: 37
The RTT to ACK the segment was: 0.000357000 seconds
No. Time Source Destination Protocol
Info Port
39 6.105259 10.112.136.76 10.112.136.157 TCP
2955 > https [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460 https
Frame 39 (62 bytes on wire, 62 bytes captured)
Arrival Time: Jun 16, 2004 10:19:23.371259000
Time delta from previous packet: 0.000436000 seconds
Time since reference or first frame: 6.105259000 seconds
Frame Number: 39
Packet Length: 62 bytes
Capture Length: 62 bytes
Ethernet II, Src: 00:08:02:b7:9a:dd, Dst: 00:0e:83:55:ef:00
Destination: 00:0e:83:55:ef:00 (Cisco_55:ef:00)
Source: 00:08:02:b7:9a:dd (CompaqCo_b7:9a:dd)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.112.136.76 (10.112.136.76), Dst Addr:
10.112.136.157 (10.112.136.157)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 48
Identification: 0x7d7e (32126)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x5780 (correct)
Source: 10.112.136.76 (10.112.136.76)
Destination: 10.112.136.157 (10.112.136.157)
Transmission Control Protocol, Src Port: 2955 (2955), Dst Port: https (443),
Seq: 0, Ack: 0, Len: 0
Source port: 2955 (2955)
Destination port: https (443)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0xde9d (correct)
Options: (8 bytes)
Maximum segment size: 1460 bytes
NOP
NOP
SACK permitted
""Peter Huang"" <v-ph...@online.microsoft.com> wrote in message
news:A3a2$F4UEH...@cpmsftngxa10.phx.gbl...
Peter Huang
Thank you for your quick response.
I can not reproduce the problem based on the environment you have input(XP
Pro SP1, IIS 5, VS.NET 2003, .NET FX 1.1).
Now I am finding other colleague who can help you.
Thank you for your understanding.
Peter Huang
I am sorry for delay. We are working with other engerneer on this issue,
please pay more patience, we can update you with new information ASAP.
Berndt Johansson
Thank you. Please let me know if you need any other tests on my side.
/Berndt
""Peter Huang"" <v-ph...@online.microsoft.com> wrote in message
news:op5bPA2V...@cpmsftngxa10.phx.gbl...
Brian Combs
Here is how HttpWebRequest works with client certs, SSL, and Basic auth.
First when you protect a client cert by installing it with strong private
key protection and configure it to prompt for each access call to private
key, then you will get a prompt when anything try's to access this private
key.
Here is what is happening.
1. HttpWebRequest sends anonymous request to IIS using SSL
2. IIS tells client it needs client cert.
3. Client gets and sends client cert. (first prompt as we need to access
the private key)
4. IIS sees that you need to auth to get to the requested resource
5. It sends 401 and closes the connection.
6. Client sends new request with authorization header to IIS using SSL
7. IIS tells client it needs client cert.
8. Client gets and sends client cert. (second prompt as we need to access
the private key)
9. IIS auth the request and returns the data.
Now if you make new requests and PreAuthenticate is not set to true you
will get a prompt for each new request. If you set PreAuthenticate to true
then you will not get prompted after the first two prompts if you are using
the same connection. If you need to create a new connection then you will
get a prompt because you must set up a new SSL session for that connection
which means you need to access the private key.
PreAuthenticate with basic auth works like the following:
First request goes anonymous
We get 401 back
Client then sends next request with credentials.
If we authenticate then any other request that has PreAuthenticate set to
true and has the same credentials will send the credentials on the first
request.
The first request goes anonymous because we don't know if we need to
authenticate and if so how. So we need to find out first if we can do the
PreAuthenticate for subsequent requests.
All of this is by design.
Thanks
Brian [MSFT]
Microsoft Developer Support
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
| From: "Berndt Johansson" <berndt.j...@removenospamom.com>
| References: <ONvpdCgT...@TK2MSFTNGP11.phx.gbl>
<doEgDrrT...@cpmsftngxa10.phx.gbl>
<OJjLDat...@tk2msftngp13.phx.gbl>
<T7Q$$T2TEH...@cpmsftngxa10.phx.gbl>
<#NkjnpiU...@TK2MSFTNGP10.phx.gbl>
<JShKdWoU...@cpmsftngxa10.phx.gbl>
<OuGEn$pUEHA...@TK2MSFTNGP10.phx.gbl>
<A3a2$F4UEH...@cpmsftngxa10.phx.gbl>
<u2E8675U...@TK2MSFTNGP09.phx.gbl>
<c1Y87dB...@cpmsftngxa10.phx.gbl>
<op5bPA2V...@cpmsftngxa10.phx.gbl>
| Subject: Re: Client certificate private key prompt
| Date: Mon, 21 Jun 2004 22:19:47 +0200
| Lines: 26
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
| Message-ID: <Og2JX08V...@TK2MSFTNGP11.phx.gbl>
| Newsgroups: microsoft.public.dotnet.framework
| NNTP-Posting-Host: om.omgroup.com 194.213.87.193
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTFEED
01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework:74101
| X-Tomcat-NG: microsoft.public.dotnet.framework
Berndt Johansson
Thank you for your response. I had a hunch that this was the problem, but
the question still is why Peter was not able to reproduce the behaviour with
the exact same code that I was running (except if I used the extra
authentication header in the initial request). Is there some trick that we
could do to eliminate this problem. Addid the authentication header manually
sure is one, but does it have any other negative effects?
Would upgrading to IIS 6 (W2k3) solve this problem? When I tried to run our
testcode on a W2k3 server I didn't get the double prompting. Does this mean
that the SSL channel is kept between the requests in IIS6 and therefore
there is no need to read the private key again from the certificate?
/Berndt
"Brian Combs" <Br...@online.microsoft.com> wrote in message
news:InXJtoVW...@cpmsftngxa10.phx.gbl...
Brian Combs
As you stated the trick is to add your the authentication header manually.
The only issue with this is that you are now in charge of making sure it is
there for each request and that the header is correct. Many folks have used
this when they need to make sure that no request every goes as anonymous.
Upgrading the client to W2K3 will not solve the two prompt issue. I tested
my code on W2k3 and I still got the two prompts. However upgrading your
server to IIS 6.0 may keep the client from giving you two prompts. This is
because IIS 6.0 does not close the connection after the 401 for basic auth
like IIS 5.0 does. Which means that if the TCP connection is not closed
then we may be able to keep the same SSL session so we don't need to access
the private key. Remember you may not always have control over how the web
server is configured. The key for the customer to understand is that they
wanted this security, so they should not complain when it works! IE is a
different product and does not share any code base with managed code
classses. So you can't compare how IE works to how managed code classes
work. IE also cashes a lot of client info in the process like the private
key for the client cert.
Thanks
Brian [MS]
Microsoft Developer Support
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
| From: "Berndt Johansson" <berndt.j...@removenospamom.com>
| References: <ONvpdCgT...@TK2MSFTNGP11.phx.gbl>
<doEgDrrT...@cpmsftngxa10.phx.gbl>
<OJjLDat...@tk2msftngp13.phx.gbl>
<T7Q$$T2TEH...@cpmsftngxa10.phx.gbl>
<#NkjnpiU...@TK2MSFTNGP10.phx.gbl>
<JShKdWoU...@cpmsftngxa10.phx.gbl>
<OuGEn$pUEHA...@TK2MSFTNGP10.phx.gbl>
<A3a2$F4UEH...@cpmsftngxa10.phx.gbl>
<u2E8675U...@TK2MSFTNGP09.phx.gbl>
<c1Y87dB...@cpmsftngxa10.phx.gbl>
<op5bPA2V...@cpmsftngxa10.phx.gbl>
<Og2JX08V...@TK2MSFTNGP11.phx.gbl>
<InXJtoVW...@cpmsftngxa10.phx.gbl>
| Subject: Re: Client certificate private key prompt
| Date: Thu, 24 Jun 2004 08:45:03 +0200
| Lines: 125
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
| Message-ID: <#$yYJbbWE...@TK2MSFTNGP11.phx.gbl>
| Newsgroups: microsoft.public.dotnet.framework
| NNTP-Posting-Host: om.omgroup.com 194.213.87.193
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11
phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework:74296
| X-Tomcat-NG: microsoft.public.dotnet.framework
Berndt Johansson
Okej, so upgrading to IIS6 will make the problem a bit smaller, but not
completely gone...
We saw the difference in TCP behaviour between IIS5 and IIS6 using Ethereal
and the TCP connections are kept.
I can only agree with you on the fact that, if they setup certificates to
use the prompting they, that is also what they get, for good and for bad. I
have been trying to convince the customer about this all the time, but I
need a solid proof to convince them :-) I think that I have that now.
Tank you for your help.
/Berndt
"Brian Combs" <Br...@online.microsoft.com> wrote in message
news:SnMpWnj...@cpmsftngxa10.phx.gbl...