Комментарии 15
У сертификата есть алгоритм подписи. Он может быть разным, с разной вычислительной сложностью. Может в новом алгоритм какой-то неподдерживающийся?
Необычная статься по .NET для хабра – чаще разбирают очень странные кейсы, которые могут быть сильно упрощены стандартным функционалом .NET.
Почему в методе HttpClientHandler.SendAsync использовали .GetAwaiter().GetResult() вместо нормального await, метод же возвращает Task?
В целом не имеет особой роли что в данном кейсе использовать. Можно было написать и такой код:
protected async override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
Log.Information("-- Information about call -- " +
"\nClientCertificateOptions: " +
"{ClientCertificateOptions},\n" +
"ClientCertificates:\n{ClientCertificates}",
ClientCertificateOptions.ToString(),
ClientCertificates[0].ToString());
var response = await base.SendAsync(request, cancellationToken);
var content = await response.Content.ReadAsStringAsync(cancellationToken);
Log.Information("Response: {Content}\nStatusCode: {StatusCode}", content, response.StatusCode);
return response;
}
Данный хендлер писался как быстрый и не претендует быть красивым кодом, скорее просто информативная часть.
var cs = new RSACryptoServiceProvider(2048)
генерирует новую ключевую пару RSA каждый раз. Зачем вам это? Вы же импортируете свою
Вопрос хороший на самом деле. Этот код был новый для меня и как мне подсказывает интуиция взялся он откуда из интернета. А как в таком случае приписать приватный ключ к сертификату? Попытка использовать вот такой метод
X509Certificate2.CreateFromPem
сложилась не очень удачно..
По поводу скорости. Возможно, в новом сертификате размер ключа больше. Например, было 2048, стало 4096.
И какая конкретно ошибка с X509Certificate2.CreateFromPem()
? Обратите внимание, что в документации на метод описаны допустимые заголовки PEM.
Также можно предварительно экспортировать сертификат в PFX, и в приложении загружать уже оттуда, а не собирать из двух PEM-ов.
Ваш пример кода по генерации сертификата с помощью BC тоже неверный. Вы подписываете сертификат его же закрытым ключом, а нужно подписывать закрытым ключом издателя, которого у вас нет (если, конечно, сертификат не самоподписанный). Т.е. на выходе вы получаете другой сертификат. Если на стороне-приёмнике будет проверка такого клиентского сертификата, то он её не пройдёт.
Вообще, ситуация с BouncyCastle напоминает этот комикс. Все используют это плохо документированное нечто, но никто не найдет в себе силы написать нормальную библиотеку. Эй, фанаты криптографии, ау!
Я видел и другие варианты пакетов, но у всех в референсах лежит касл)
Поэтому думаю не скоро будет такое еще :D
Ещё одна её особенность - полностью своя managed-реализация всей криптографии. С соответствующими проблемами: низкая скорость в отличие от оптимизированных системных криптопровайдеров, ключи хранятся в памяти приложения, и далеко не всегда хотя бы зануляются. Но иногда да, в определённых случаях BC выручает, хотя отсутствие нормальной документации сильно затрудняет освоение.
Нормальную библиотеку потому и не пишут, что нет смысла, системные всё равно не переплюнуть в плане скорости и надёжности. Да и в свежих версиях .NET улучшения в плане поддержки криптографии прямо радуют, хотя и тут не без изъянов.
А что с настройками валидации сертификата, доступностью CRL и OCSP?
Статья интересная, но печально, что лексикон программистов превращается в тарабарщину... А подпись не должна содержать ГОСТ алгоритмы? Или вы не подпадает в поле действия нормативных документов.
Сейчас интересно было бы посмотреть на решения внедрения ГОСТов в .Net Core 7, там есть определенные костыли
Как я познакомился с BouncyCastle в .NET 7