Отладка неудачного HTTPS WebRequest

Question

Я пишу небольшую программу, которая отправит GET-запрос на сервер, используя HTTPS и класс HttpWebRequest. Сервер (очевидно) имеет сертификат сервера. Также ожидается, что клиент предоставит сертификат.

Однако при выполнении запроса я получаю исключение System.Net.WebException, в котором говорится, что установить безопасное соединение TLS / SSL невозможно. Я быстро обнаружил, что сертификат сервера недействителен. Предполагая, что это было причиной исключения, я попытался принять недействительный сертификат (обновление сертификата, к сожалению, не вариант), используя код ниже:

ServicePointManager.ServerCertificateValidationCallback += delegate {
    return true;
};

Однако это не решило проблему.

Поскольку исключение не дает какой-либо детали, на самом деле трудно определить, что его вызывает. Моя попытка переопределить недействительный сертификат сервера не работает? Является ли предоставленный мной сертификат клиента ненадежным для сервера? Я не загружаю сертификат клиента надлежащим образом?

Мне бы очень хотелось, чтобы советы по устранению подобных проблем. У меня нет доступа к серверу или его журналам, к сожалению.

Ниже приведены важные части кода:

ServicePointManager.ServerCertificateValidationCallback += delegate {
    return true;
};
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url); // url is an HTTPS URL.
X509Certificate clientCert = new X509Certificate("certificate.crt", "password");
req.ClientCertificates.Add(clientCert);
WebResponse resp = req.GetResponse(); // This fails!

Answer 1

Пощечину! Следы - ваш лучший друг при отладке этих вещей. Однажды у меня был один клиент, который не смог подключиться к нашей службе с поддержкой SSL. Используя трассировку, я обнаружил, что кто-то перенес системные часы после даты истечения срока действия нашего сертификата. Но я отвлекся.

Включите все применимые источники трассировки и посмотрите, не появилось ли что-нибудь интересное в журналах.

Есть старый (2005), но отличный пост от Durgaprasad Gorti, который вы должны проверить. Он точно покажет, какие источники нужно добавить, и в нем он также покажет некоторые трассировки SSL с помощью пользовательского обратного вызова проверки.

Пример app.config из того же сообщения в блоге:

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
  <system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.Net">
        <listeners>
          <add name="MyTraceFile"/>
        </listeners>
      </source>
    </sources>

    <sharedListeners>
      <add
      name="MyTraceFile"
      type="System.Diagnostics.TextWriterTraceListener"
      initializeData="System.Net.trace.log"
    />
    </sharedListeners>

    <switches>
      <add name="System.Net" value="Verbose" />
    </switches>

  </system.diagnostics>
</configuration>

Надеюсь, это даст вам еще немного данных.

Answer 2

Некоторые мысли:

1. TLS определяет некоторые коды ошибок и оповещений. Библиотеки SSL / TLS часто предоставляют этот код при возникновении исключения. Может быть, вы могли бы найти эту информацию в журнале сервера.

2. Возможно, некоторые сертификаты отсутствуют, когда сервер отправляет свою цепочку сертификатов. Например, если сервер отправляет только свой сертификат, клиент может не иметь возможности присоединить этот сертификат к корневому сертификату, если существует какой-либо промежуточный сертификат CA.

3. Если ожидается, что клиент будет использовать сертификат для аутентификации, сервер должен отправить имена принятых корневых сертификатов. Мой предыдущий пункт также действителен здесь, если некоторые промежуточные сертификаты отсутствуют, невозможно построить цепочку между его сертификатом и корнем, отправленным сервером. Клиент не находит подходящий сертификат (поскольку закрытый ключ недоступен) - это еще одна возможная проблема.

Answer 3

Я согласен с решением Маркуса выше.Однажды у меня возникла похожая проблема, и я обнаружил, что лучше всего сделать это исключение в отладчике.

Если вы можете запустить сборку локально и посмотреть на это исключение в отладчике, вам нужно детализировать несколько уровней, прежде чем вы получите реальную суть проблемы.

В случае IЯ думаю о том, что мне пришлось просмотреть 4 или 5 внутренних исключений, прежде чем я получил сообщение, в котором конкретно говорилось, что было не так.

Я обнаружил, что во многих случаях в .Net это обычно имеет место.вы получите исключение, которое имеет очень общее сообщение об ошибке, и вам нужно опуститься на несколько уровней «innerException», прежде чем вы дойдете до сути проблемы.

Надеюсь, это поможет.