Если попытаться соединиться с HTTPS-сервером, имеющим самоподписанный сертификат, то HttpWebRequest сгенерирует исключение WebException Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS. (The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.). Оно и понятно, HttpWebRequest не смог проверить сертификат узла и закономерно нас послал.

Решение заключается в переопределении глобального обработчика System.Net.ServicePointManager.ServerCertificateValidationCallback.

Внимание! Изменение ServerCertificateValidationCallback повлияет на все соединения в программе, пока обработчик не будет установлен по умолчанию, надо не забывать это, и возвращать обработчик к стандартному значению, после того, как работа с сервером, имеющим самоподписанный сертификат, завершена.

Предположим, есть класс-обертка над HttpWebRequest, надо его дополнить так, чтоб можно было работать с серверами с self-signed сертификатами.

Самый простой способ, но не самый безопасный. ServerCertificateValidationCallback передается делегат, который всегда возвращает true. Добавляем в класс функцию:

public void EnableIgnoreCertError()
{
    ServicePointManager.ServerCertificateValidationCallback =
        delegate { return true; };
}

И функцию, которая возвращает ServerCertificateValidationCallback к значению по умолчанию:

public void DisableIgnoreCertError()
{
    ServicePointManager.ServerCertificateValidationCallback = 
        null;
}

Начали работать с сервером — вызвали первую, закончили — вызвали вторую.

Немного более сложный, но более безопасный способ. Необходимо заранее либо иметь сам сертификат, либо знать его хэш. В следующем примере будем проверять как раз хэш SHA1 сертификата.
1. Подключим в References’ах System.Security.Cryptography.
2. Подключим необходимые пространства имен:

using System.Net.Security;
using System.Security.Cryptography.X509Certificates;

3. Заведем в классе поле, куда из вызывающей программы будем передавать заранее известный хэш сертификата:

public string CertHashString { get; set; }

4. Заведем две функции, для включения и выключения самостоятельной проверки сертификата:

public void EnableValidateCert()
{
    ServicePointManager.ServerCertificateValidationCallback =
        ValidateCert;
    
}

public void DisableValidateCert()
{
    ServicePointManager.ServerCertificateValidationCallback =
        null;
}

В первой функции вместо делегата, возвращающего true, указываем нашу функцию проверки.

Функция проверки сертификата обязательно должна иметь следующий заголовок:
bool FunctionName (object, X509Certificate, X509Chain, SslPolicyErrors), т.е., например:

private bool ValidateCert(object sender, X509Certificate cert,
    X509Chain chain, SslPolicyErrors sslPolicyErrors)

В функции:
1. Проверяем наличие ошибок SSL, если их нет, значит сертификат уже был опознан:

if (sslPolicyErrors == SslPolicyErrors.None)
{
    return true;
}

2. Если известный хэш сертификата не был передан вызывающей программой, значит и проверять нечего:

if (string.IsNullOrEmpty(CertHashString))
{
    return false;
}

3. Получаем хэш сертификата сервера в виде строки:

string hashstring = cert.GetCertHashString();

4. Если хэши полученного и известного сертификата совпадают — все ок, возвращаем true, иначе false.

if (hashstring == CertHashString)
{
    return true;
}

return false;

Функция целиком:

private bool ValidateCert(object sender, X509Certificate cert,
    X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
    //все и так хорошо
    if (sslPolicyErrors == SslPolicyErrors.None)
    {
        return true;
    }

    //не передан хэш сертификата
    //значит и проверять нечего
    if (string.IsNullOrEmpty(CertHashString))
    {
        return false;
    }

    //получаем хэш сертификата сервера в виде строки
    string hashstring = cert.GetCertHashString();

    //если хэши полученного и известного 
    //сертификата совпадают - все ок.
    if (hashstring == CertHashString)
    {
        return true;
    }

    return false;
}

Класс целиком на PasteBin
На GitHub

Источник

Понадобилось проверить сертификат X509 на целостность и подлинность. Поставщик сертификата отдельно передает его fingerprint и алгоритм хэширования по которому тот вычисляется.

Судя по документации от MS, получить fingerprint, он же хэш, можно функцией GetCertHashString() (или GetCertHash() в виде массива байт) класса X509Certificate2, однако, в .NET 2.0 отсутствует перегрузка функции GetCertHashString(HashAlgorithmName), которая позволяет выбрать алгоритм хеширования (GetCertHashString() возвращает хэш SHA1). Потому сделаем руками, благо ничего сложного в этом нет.

1. Подключаем в References System.Security.Cryptography
2. Подключаем необходимые пространства имен в классе:

using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

3. Загружать сертификат будем из файла, потому проверяем его наличие:

if (!File.Exists(CertFile))
{
    Console.WriteLine("File not found.");
    return null;
}

4. Загружаем сертификат (создаем экземпляр класса X509Certificate2). Если вдруг файл сертификата поврежден, то конструктор X509Certificate2 вызовет Exception Требуемый объект не найден. Поэтому конструктор надо обернуть в try...catch:

try
{
    X509 = new X509Certificate2(CertFile);
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
    return null;
}

5. Получаем загруженный сертификат в виде массива байт:

byte[] cert = X509.GetRawCertData();

6. Создаем объект HashAlgorithm, который и займется вычислением хэша/fingerprint’а. Я завел в функции входную переменную AlgName, куда записывается строка с названием алгоритма, что бы иметь возможность выбора алгоритма хэширования если что:

HashAlgorithm alg = null;
switch (AlgName.ToUpperInvariant())
{
    case "MD5": alg = MD5.Create(); break;
    case "SHA1": alg = SHA1.Create(); break;
    case "SHA256": alg = SHA256.Create(); break;
    case "SHA384": alg = SHA384.Create(); break;
    case "SHA512": alg = SHA512.Create(); break;
    default:
        {
            Console.WriteLine("Unknow algorithm.");
            return null;
        }
}

7. Получаем хэш в виде массива байт:

byte[] hash = alg.ComputeHash(cert);

8. Преобразуем массив байт в строку шестнадцатеричных чисел:

string hex = BitConverter.ToString(hash).ToLowerInvariant().
    Replace("-", "");

ToLowerInvariant() преобразует буквы в строке, полученной BitConverter в строчные, а Replace("-", "") удаляет разделители (-) между значениями байтов, которые BitConverter вставляет в строку.

Код функции целиком
Тестовый пример на GitHub

Понадобилось достать несколько значений из JSON-файла, искал, чем это сделать и нашел просто офигенную библиотеку Json.NET. Это не просто парсер, это целый набор инструментов: парсер, сериализаторы, десериализаторы, конвертеры. Кроме банального вытаскивания значений, можно формировать JSON, конвертировать его в XML и XML в JSON, обращаться к объектам JSON через запрос SelectToken или LINQ. А можно и просто вытащить нужное значение, обращаясь к полям JSON, используя встроенные функции объектов.

Несомненный плюс библиотеки в том, что даже в последней версии она поддерживает .NET Framework 2.0 Правда нельзя будет использовать синтаксис LINQ, но и без него инструментов хватает.

С помощью JObject и JToken

1. Подключаем библиотеку для своего Framework’а через References и в исходнике:

using Newtonsoft.Json.Linq;

2. Загружаем JSON в переменную, например из файла.

3. Парсим JSON в JObject:

JObject JSONObj = JObject.Parse(JSONBuf);

JObject.Parse может вызвать exception, если есть синтаксические ошибки в JSON, так что лучше поместить его в try...catch:

public static JObject ParseJSON(string JSONBuf)
{
    JObject JSONObj = null;
    try
    {
        JSONObj = JObject.Parse(JSONBuf);
    }
    catch (Exception ex)
    {
        Console.WriteLine("ERROR: " + ex.Message);
        return null;
    }
    return JSONObj;
}

Пример реакции на ошибку синтаксиса:

Invalid character after parsing property name. Expected ':' but got: {. Path description.languages', line 15, position 9.

4. Далее, можно вытащить значение поля JSON в объект JToken помощью функции JSONObj.GetValue(FieldName);, если поле со значением находится сразу в корне JSON, как, например, api_uri в этом примере, то JToken можно сразу преобразовать в строку с помощью функции .ToString:

JToken tok = JSONObj.GetValue("api_uri");
tok.ToString();

Однако, если поле отсутствует, то это вызовет exception:

В экземпляре объекта не задана ссылка на объект.

Этого можно избежать, отловив исключение в try...catch, либо проверив наличие поля функцией JObject.ContainsKey("имя_поля") перед вызовом GetValue, либо воспользовавшись функцией TryGetValue вместо GetValue

Примеры кода на PasteBin
Тестовый проект

Если же нужное значение находится где-то глубоко в недрах JSON, то необходимо воспользоваться функцией JObject.SelectToken() Пример в официальной документации Копия

Как я уже говорил, инструмент очень мощный, так что лучше начать с изучения официальной документации

Json.NET с официального сайта
Копия библиотеки v 120r3

Или небольшая заметка про странный глюк (на самом деле фичу) MS и кривофикс к ней.

Словил странный баг при поиске файлов по маске, функцией Directory.GetFiles();

Оказалось, что при задании маски вида *.htm, в выборке окажутся все файлы с расширением, длина которого больше трех совпадающих символов, т.е. и *.htm и *.html и *.htmепрст, и т.д. Срабатывает это для файлов с расширениями размером три символа и больше.

Т.е. на *.ph оно найдет только файлы с расширением ph, а на *.a — только файлы с расширением a

Этот баг распространяется только на последнее расширение. Если в имени файла есть конструкция типа *.tmp.php, например admin.tmp.php, то при задании маски *.php расширение tmp будет, слава Ктулху, проигнорировано.

Оказалось, что это не баг, а фича, и об этом прямо написано в MSDN:

Если указанное расширение имеет длину ровно три символа, метод возвращает файлы с расширениями, которые начинаются с указанного расширения. Например, «*. xls» возвращает оба значения: «Book.xls» и «Book.xlsx».

Не знаю, как создатели DOS смогли заговнять и испортить самую простую операцию, которая работала у них, как минимум, с 1989 года, но факт. Заговняли.

В общем, я теряюсь в догадках.

Это, конечно же, довольно коряво. Наверное, можно было бы решить с помощью регулярных выражений, но я поступил следующим образом:

1. Создал функцию, которая будет вытаскивать однозначное расширение и из заданной маски, и из поданного на вход файла:

private string GetExtension(string FileName)
{
    FileName = FileName.Replace('*', '_');
    FileName = FileName.Replace('?', '-');
    FileInfo fi = new FileInfo(FileName);
    return fi.Extension;
}

Замены Replace(...) тут для того, чтобы класс FileInfo не выпал в Exeption, если ему подать что-то вида *.html, т.к. FileInfo не принимает имен с недопустимыми символами, к которым относятся и маски подстановки. В определении расширений класс FileInfo такого глюка не имеет, и отличает file.html от file.htm. И тоже не признает двойные расширения, учитывая только последнее.

2. В функции, где будем вызывать поиск файлов, вызываем, собственно, функцию поиска:

string[] files = Directory.GetFiles(Path, Mask, SearchOptions);

3. Получаем расширение маски:

string MaskExt = GetExtension(Mask);

4. Далее обрабатываем выходной массив. Например, тут я добавлял его в List<string> с именем FoundFiles. Мне надо было искать файлы по маскам, и нужно было, чтоб *.htm и, например, *.html различались.

Например, я просто сравнивал расширение от маски файла с расширением от имени файла, и если оно совпадало — добавлял в результирующий список FoundFiles:

string FileExt = GetExtension(filename);
if (FileExt == MaskExt)
{
    FoundFiles.Add(filename);
}

Или относительно полностью:

string MaskExt = GetExtension(Mask);
//[...]
string[] files = Directory.GetFiles(Path, Mask, SearchOptions);
foreach (string filename in files)
{
    string FileExt = GetExtension(filename);
    if (FileExt == MaskExt)
    {
        FoundCtr++;
        FoundFiles.Add(filename);
    }
}