Jeśli używasz samopodpisanych certyfikatów, jedynymi błędami, których należy się spodziewać, jest błąd łańcucha w katalogu głównym (wystawcy certyfikatu). Sugerowałbym coś takiego, że pułapki na konkretny błąd łańcucha i pozwala, aby wszystkie inne błędy wpadły.
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(
ValidateRemoteCertificate
);
private static bool ValidateRemoteCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors)
{
string trustedIssuer = "CN=www.domain.com";
string trustedDomain = "CN=www.domain.com";
bool policyErr = false;
switch (policyErrors)
{
case SslPolicyErrors.None:
policyErr |= false;
break;
case SslPolicyErrors.RemoteCertificateChainErrors:
bool chainErr = false;
foreach (X509ChainStatus status in chain.ChainStatus)
{
switch (status.Status)
{
case X509ChainStatusFlags.NoError:
chainErr |= false;
break;
case X509ChainStatusFlags.UntrustedRoot:
if (certificate.Subject != trustedDomain || certificate.Issuer != trustedIssuer)
chainErr |= true;
else
chainErr |= false;
break;
default:
chainErr |= true;
break;
}
}
policyErr |= chainErr;
break;
default:
policyErr |= true;
break;
}
return !policyErr;
}
+1 zgadzam całkowicie. O ile nie można ufać wystawiającemu CA, to reszta certyfikatu jest prawie bez znaczenia. Jeśli nie możesz użyć * prawdziwych * certyfikatów, to jak mówi Spencer, sprawdź, czy możesz skonfigurować (lub już posiadasz) swój własny ośrodek certyfikacji, któremu możesz zaufać i wydać certyfikaty swoim użytkownikom. –
Tak, to jest zła sytuacja, ale staram się ją zmniejszyć. Przynajmniej sprawdzę, czy nazwa w certyfikacie jest zgodna z podanym adresem URL. – telesphore4