Попадание в интересную ситуацию, когда выполнение вызова REST через WebHttpRequest приводит к двум различным сценариям аутентификации, в зависимости от того, как устроен PFX.
В любом сценарии используется один и тот же PFX.
Вот 2 сценария ассоциации сертификатов:
- PFX загружается через
new X509Store(StoreName.My, StoreLocation.LocalMachine); с последующим поиском сертификата (в данном случае по значку миниатюры) - затем сертификат присоединяется через request.ClientCertificates.Add(certificate); - Важно отметить, что в этом сценарии парольная фраза опущена, и процесс не жалуется.
- PFX загружается через
new X509Certificate2(_certPath, _passphrase); - пропуск этой парольной фразы приведет к ошибке 'The specified network password is not correct', при которой указанная парольная фраза и все поступит так, как предполагалось.
Конечная точка, к которой осуществляется доступ, выполняет своего рода инициализацию пользователя, структурированную вокруг проверки подлинности Windows (NTLM), однако непосредственное взаимодействие с процессом NTLM (моим кодом) не выполняется, так как все это обрабатывается нежелательным черным ящиком, составляющим собственность это сторонний сервис.
Результирующая разница между двумя сценариями такова:
1: (Сценарий 1) запрос принят и предоставлен полный уровень обеспечения, как и ожидалось.
2: (Сценарий2) запрос принят, но предоставлен уменьшенный, меньший уровень обеспечения.
Возможная цель : Сценарий 2 работает номинально, как Сценарий 1.
Почему бы просто не опираться на сценарий 1? : я пытаюсь контейнировать этот процесс - и для обеспечения этого приложения в многоуровневых средах я планирую, чтобы оно получало все сертификаты в работоспособном контейнере приложения делают: через ENV vars (особые секреты Docker) - как таковые, StoreName.My / StoreLocation.LocalMachine на самом деле не вариант (по крайней мере, до dotnetcore 3.0, я думаю, что я видел через проблемы corefx github?)
Мой вопрос (ы) :
Какой шаг я пропускаю в контексте WebHttpRequest, который заставляет один и тот же сертификат и конечную точку работать по-разному, является ли сертификат частью хранилища ключей локальной системы по сравнению с тем, когда он подается вручную через путь к файлу?
Можно ли использовать PFX таким образом?
Приемлемый ответ Примечания: Допустимо использование рукопожатия, я ценю, что здесь нет примера кода, я хотел бы лучше понять, как Windows, PFX-сертификаты и .net (в идеале dotnetcore 2.1) имеют некоторые более чем очевидные (для меня) рабочие отношения и какие варианты доступны для меня, с надеждами на достижение моей цели (см. непосредственно ниже).
Чего я, в конечном счете, пытаюсь избежать : заставить процесс сборки docker выполнить COPY сертификата в /etc/ssl/certs - потому что я не хочу, чтобы мое имя использовалось в образах докеров, которые поставляются в комплекте с public & privatekey PEM файлы.
Я упаковал довольно много приложений Node, Java, Php и Python, а также это приложение на C #, однако впервые приходится сталкиваться с необходимостью сделать это с PFX
I am открыт для других предложений, которые не включают размещение сертификата, содержащего закрытый ключ и доверие, к образу контейнера. Только открытый ключ / crt, будет приемлемым.
Попробованы дополнительные биты :
- Установка политики делегата на ServicePointManager
- и различные другие параметры TLS, связанные с ServicePointManager
- Создание временного хранилища X509 и его уничтожение при завершении работы приложения