What is "realm" in IIS authentication and how is it related to SSL certificate parameters?

I'm trying to implemented custom basic authentication similar to this and one thing that confuses me is a concept of realm. For example, there's a moment when my module inserts some magic string into the reply:

void ReplyWithAuthHeader()
{
    HttpContext currentContext = HttpContext.Current;
    context.Response.StatusCode = 401;
    context.R开发者_如何学JAVAesponse.AddHeader( "WWW-Authenticate",
       String.Format("Basic realm=\"{0}\"", "myname.mycompany.com"));
}

The site is assigned an SSL certicicate created with makecert utility and is "issued" to "myname.mycompany.com". The caller creates a request:

HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create( serverUrl );
CredentialCache cache = new CredentialCache();
cache.Add( new Uri( serverUrl ), "Basic", new NetworkCredential( "UserName", "password" ) );
request.Credentials = cache;

where serverUrl starts with https:// and when the request is being processed by the server the server sends the "WWW-Authenticate" reply, then an exception is thrown on the client side with "Unable to write data to the transport connection: An established connection was aborted by the software in your host machine." text.

So clearly there's something wrong at SSL negotiation level and I can't fugure what it is. I guess it could be something dealing with the realm.

My question is - what is a realm and how is it related to the name of the party to which an SSL certificate was issued when a connection is made over SSL?

---

To answer your question "what is a realm?", some copypasta from RFC 2617:

The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms.

As to your question how it is related to your SSL certificate: it isn't. The easiest way I can think of to figure out what's going wrong, is simply by accessing the URL in your browser. You should get a pretty clear description of the problem (hostname doesn't match the certificate, untrusted CA, expired, etc.).

---

The realm indicates the scope that the client is authenticating for. A browser will cache the username, password and realm and re-send the credentials for any further server responses requiring authentication for that realm.

There's no relationship between SSL and what's going on with HTTP, if you've managed to negotiate a connection and send a request and get a response, SSL won't be your problem. You could just be trying to write to a connection that's been closed. In this instance I'd load the private key into Wireshark and take a closer look at what's going on at a protocol level, both TCP/IP and HTTP.