create SSL/TLS secure channel
при этом запросы, сделанные через curl работают.
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11;
уже пытался и 1.2 оставлять, и 1.1, и с SSL3 - что совой об пень, что пнём об сову - не проходят.
Куда копать, где ещё может быть ошибка?
А на той стороне какая OS?
Не знаю, подозреваю, что-то из *NIX
У меня была похожая трабла. HttpClient просто игнорил самоподписанный сертификат, так как при его генерации использован md5
домен в год стоит до тыщи рублей, а вы до сих пор ебетесь с самоподписанными сертификатами
Не, мне надо было внешнее апи дёргать с клиентским сертификатом. И вот чуваки мне выдали сертификат самоподписанный с мд5, и курлом все работало, а через хттпклиент - нет, пока ребята не сгенерили клиентский сертификат без мд5
тут же публичного домена нету, все в интранете, некуда сертификат выдавать
да это вообще не проблема, сертификат выдается на домен, домен используешь в локальной сети.
Значит домен нужен с реальным внешним именем (потому что на иные давно серты не выдают), и структура поддоменов должна быть как у нормального внешнего домена (ибо задолбаешься покупать серты на aaa.bbb.site.com) но при этом не пересекаться с уже используемыми компанией публичными доменами (иначе беда с dns и всякими внутренними sso)
Нахера для локальной сети покупать? Их давно бесплатно выдают, главное подтвердить владение доменом, мы wildcard получаем кстати.
чтобы подтвердить владение доменом, нужно чтобы домен торчал наружу! тут же сценарий сурового секьюрного интранета, который если будет наружу торчать - СБ сильно разозлится, если в ближайшнм лесу не прикопает
нет, там есть и другие способы, я использую подтверждение по ДНС (нужно в ДНС добавить txt запись), а у нас что используют хз, кажется в Digital Ocean что-то
да даже оригинальному автору это не особо надо) но для добавления dns-записи надо dns-записи домена публично анонсить, а тут сценарий полностью огороженный скорее всего
Обсуждают сегодня