Мы интегрируемся со службой, которая использует клиентские сертификаты для проверки соединения https между нами и сервером поставщика. Мы создали CSR, и поставщик предоставил нам файл p7b с 2 промежуточными сертификатами и доверенным корневым сертификатом. Затем мы создали двоичный файл pfx с закрытым ключом из CSR (мы можем сопоставить сертификаты и ключи, поэтому мы знаем, что они правильны с этой точки зрения).
Мы используем Vault для хранения наших общихсертификаты аутентификации, поэтому pfx не установлен на Windows Server 2012r2.
В нашем клиентском коде мы делаем следующее:
var myBinding = new WSHttpBinding();
myBinding.Security.Mode = SecurityMode.Transport;
myBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate;
var client = new ServiceClient(myBinding, new EndpointAddress("https://example.org"));
client.ClientCredentials.ClientCertificate.Certificate = new X509Certificate2("cert.pfx", "****");
client.create(new model());
При вышеуказанной настройке мы имеем следующие эффекты:
- Машина разработки Windows 10 - соединение TLSуспешно выполнено
- Windows Server 2012r2 - сбой подключения TLS
Затем мы добавили обратный вызов проверки:
ServicePointManager.ServerCertificateValidationCallback += ValidateServerCertificate;
private static bool ValidateServerCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
// ...
}
На данный момент sslPolicyErrors
равно System.Net.Security.SslPolicyErrors.RemoteCertificateChainErrors
.
Если мы попытаемся построить нашу собственную цепочку SSL:
using (var chain = new X509Chain())
{
var flag = X509VerificationFlags.NoFlag;
chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck;
chain.ChainPolicy.VerificationFlags = flag;
var primaryCert = new X509Certificate2(certificate);
var n = chain.Build(primaryCert);
Console.WriteLine($"Flag: {flag} - {string.Join(",", chain.ChainStatus.Select(x => $"{x.StatusInformation.Trim()} ({x.Status})"))}");
return n;
}
Мы получим отпечаток - Flag: NoFlag - A certificate chain could not be built to a trusted root authority. (PartialChain)
Поэтому мы изменили флаг на X509VerificationFlags.AllowUnknownCertificateAuthority
.
Это привело к правильной проверке цепочки сертификатов.
У нас есть следующие вопросы:
У нас разные эффекты на разных машинах, поэтомумы пришли к выводу, что Win 10 не так строги с проверкой. Есть ли какая-либо причина, по которой Server 2012r2 отклонил бы цепочку?
Существуют ли проблемы с безопасностью, если мы используем флаг проверки X509VerificationFlags.AllowUnknownCertificateAuthority
?
Можем ли мы установить этот флаг в настройках клиента или он должен быть частью обратного вызова проверки?