[C#] Could not create SSL/TLS secure channel

[_Thanatos_]

Ik probeer een website (site ja, niet service) aan te roepen met HttpWebRequest, maar ik krijg steeds een generieke exception met als melding:

"The request was aborted: Could not create SSL/TLS secure channel."

Het gaat om een https-website die in Opera gewoon te benaderen is. Gek eigenlijk, want Firefox geeft deze melding:

...uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)

Prima, ik vertrouw de boel. Het is low-risk en http-zonder-s is niet beschikbaar. Dus ik kan en wil gewoon doorgaan. Maar in .NET lukt me dat niet.

Wat heb ik al geprobeerd:

1. request.ProtocolVersion = HttpVersion.Version10;
   Dit helpt helemaal niets, ook al is de default versie 1.1.
2. Geen "Accept-Encoding: gzip,deflate" header meesturen. Standaard doe ik dat wel, omdat performance, maar weglaten helpt niet. Soort-van logisch, maar je weet maar nooit.
3. De ServicePointManager africhten met onderstaand stuk code. Je zou zeggen dat hiermee alles valid is, maar nee. Sterker nog, die AlwaysGoodCertificate methode wordt niet eens aangeroepen

C#:

private void TrustAnything() {
  ServicePointManager.Expect100Continue = true;
  ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls;
  ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
  ServicePointManager.CheckCertificateRevocationList = false;
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) {
  return true;
}

Het aanmaken van het HttpWebRequest is verder plain vanilla. Echt, echt, echt ECHT niets bijzonders aan:

C#:

HttpWebRequest request = HttpWebRequest.Create(uri) as HttpWebRequest;
request.Accept = "image/gif, image/png, image/jpeg, image/pjpeg, */*";
request.UserAgent = "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1";
request.Referer = referer;
request.Timeout = Timeout.Infinite;
request.Headers.Add(HttpRequestHeader.AcceptEncoding, "gzip,deflate");
try {
  response = request.GetResponse() as HttpWebResponse;
}
catch (WebException e) {
  response = e.Response as HttpWebResponse;
}

De uri en de referer worden elders meegegeven, en zijn keurignette fully-qualified https-uri's. Vaak wordt trouwens aangeraden een proper certificaat voor de site te kopen. Niet echt een optie, want dit is een hobbyprojectje, en het is niet mijn website die ik benader.

Iemand een idee wat ik moet doen?

Ik gebruik overigens VS2008 en .NET 2.0, en dit is een console application.

[Feanathiel]

Ik weet dat .NET connecties cached. Wat je eventueel kunt proberen, is om gebruik te maken van 'ServicePointManager.MaxServicePointIdleTime = 0', of KeepAlive op het request op false te zetten. Dat forceert een nieuwe connectie en zal, als het goed is, ook de validatie van het certificaat nog een keer opnieuw triggeren. Let dan wel op dat, als je een keer groter gaat opschalen, dit er dan ook weer uit haalt, zodat het systeem minder belast wordt.

[HeSitated]

Welke waarde krijg je in sslPolicyErrors?

[farlane]

Ik heb datzelfde gedrag een keer gehad; het werkte alleen als ik het (ongeveer) aan het begin van main deed.

[_Thanatos_]

Feanathiel schreef op vrijdag 06 september 2013 @ 21:38:
Ik weet dat .NET connecties cached. Wat je eventueel kunt proberen, is om gebruik te maken van 'ServicePointManager.MaxServicePointIdleTime = 0', of KeepAlive op het request op false te zetten. Dat forceert een nieuwe connectie en zal, als het goed is, ook de validatie van het certificaat nog een keer opnieuw triggeren. Let dan wel op dat, als je een keer groter gaat opschalen, dit er dan ook weer uit haalt, zodat het systeem minder belast wordt.

Helaas, geen van beide helpt. Het probleem blijft bestaan, en de callback wordt niet aangeroepen. Zoals ik zei trouwens, dit is een hobbyproject, (dus) opschalen is geen issue hier.

HeSitated schreef op vrijdag 06 september 2013 @ 21:55:
Welke waarde krijg je in sslPolicyErrors?

Geen idee, als de callback een keer aangeroepen wordt, laat ik het je weten

farlane schreef op zaterdag 07 september 2013 @ 10:21:
Ik heb datzelfde gedrag een keer gehad; het werkte alleen als ik het (ongeveer) aan het begin van main deed.

Heb ik

[HMS]

Dit veld al geprobeerd te setten?

MSDN: HttpWebRequest.ServerCertificateValidationCallback Property (System.Net)

Dus direct op de HttpWebRequest die je doet, en niet op de ServicePointManager

[ Voor 14% gewijzigd door HMS op 07-09-2013 23:48 ]

[_Thanatos_]

.NET Framework
Supported in: 4.5

Dat gaat me niet helpen, want dit is een .NET 2.0 applicatie (en nee, de property is er ook echt niet).

/edit
Hééél vreemd. Als ik :443 in de url opneem, dan wordt de callback wel aangeroepen, en werken de requests vervolgens zoals ik wil. Ik zou toch zweren dat 443 de standaardport is voor https

[ Voor 39% gewijzigd door _Thanatos_ op 09-09-2013 01:48 ]

[Feanathiel]

Wellicht dat er toch nog iets gecached word? Met certificaten is dat altijd lastig te verifiëren. In een niet-ssl omgeving zou je nog kunnen proberen om er een andere hostname van te maken, maar omdat de hostname in het certificaat staat, gaat dat lastig.

[pedorus]

Een mogelijkheid dat :443 wel de boel doet werken is een cache.. Wellicht helpt het om alleen ssl3 te specificeren, zoals in http://stackoverflow.com/...te-ssl-tls-secure-channel

Heb je anders een url om mee te testen?

[_Thanatos_]

Kan ik die cache dan ergens handmatig leeggooien?

Een url kan ik beter niet geven hier, dan wordt ik gebanned
Suffice to say, het is een HTTPS-website met een ongeldig certificaat.

[ Voor 23% gewijzigd door _Thanatos_ op 12-09-2013 11:26 ]

[pedorus]

[google=httpwebrequest cache]:
http://stackoverflow.com/...e-cache-of-httpwebrequest

Het is dezelfde cache als IE, dus je kan de IE cache legen.