One of sites started to report this exception from a DotnetOpenAuth powered OAuth2 token endpoint:
Parameter name: value
at System.Net.WebHeaderCollection.CheckBadChars(String name, Boolean isHeaderValue)
at System.Net.WebHeaderCollection.Set(String name, String value)
at DotNetOpenAuth.Messaging.Channel.ReadFromRequest(HttpRequestBase httpRequest)
at DotNetOpenAuth.Messaging.Channel.TryReadFromRequest[TRequest](HttpRequestBase httpRequest, TRequest& request)
at DotNetOpenAuth.OAuth2.AuthorizationServer.HandleTokenRequest(HttpRequestBase request)
Upon further investigation it turned out that following snippet from the ReadFromRequest method fails:
foreach (string name in httpRequest.Headers)
httpDirectRequest.Headers[name] = httpRequest.Headers[name];
This seems to use the [string, string] indexer on the Headers collection which in turn tries to validate both header name and value in CheckBadChars.
The ARR turned out to be the culprit, when it acts as a reverse proxy, it adds a couple of headers, including the X-ARR-SSL header that contains the information on the actual SSL cert used by ARR. And one of our development sites apparently used a certificate generated by hand from an internal cert authority with an invalid character in the cert’s Subject name.
Lesson learned, the cert should never contain any non-ASCII chars in the subject name.
Post a Comment