Закрепление корневого сертификата в C # /. NET

SslStream никогда не будет отправлять всю цепочку (кроме самовыданных сертификатов). Соглашение состоит в том, чтобы отправлять все, кроме корня, потому что другая сторона либо уже имеет и доверяет корню, либо не имеет (таким образом / или не доверяет корню), и в любом случае это было пустой тратой полосы пропускания.

Но SslStream может отправлять промежуточные звенья только в том случае, если он понимает их.

var cert = new X509Certificate2(certPath, certPass);

Это только извлекает сертификат конечного объекта (тот, у которого есть закрытый ключ), он отбрасывает любые другие сертификаты в PFX. Если вы хотите загрузить все сертификаты, вам нужно использовать X509Certificate2Collection.Import. Но ... это тебе тоже не очень помогает. SslStream принимает только сертификат конечного объекта, он ожидает, что система сможет построить для него функционирующую цепочку.

Чтобы построить функционирующую цепочку, ваш промежуточный и корневой сертификаты должны быть в любом из:

• Provided as manual input via X509Chain.ChainPolicy.ExtraStore
  • Since the chain in question is built by SslStream you can't really do this here.
• CurrentUser \ Мой X509Store
• * LocalMachine \ My X509Store
• CurrentUser \ CA X509Store
• ** LocalMachine \ CA X509Store
• CurrentUser \ Root X509Store
• ** LocalMachine \ Root X509Store
• * LocalMachine \ ThirdPartyRoot X509Store
• Местоположение http (not-s), указанное в расширении идентификатора доступа к авторизации в сертификате.

Магазины, отмеченные *, не существуют в .NET Core в Linux. Хранилища, отмеченные **, существуют в Linux, но не могут быть изменены приложением .NET.

Этого также недостаточно, потому что (по крайней мере, для SslStream в Linux и, вероятно, macOS в .NET Core) он по-прежнему отправляет промежуточные звенья только в том случае, если он построил цепочку, которой он доверяет. Таким образом, серверу необходимо действительно доверять корневому сертификату, чтобы он мог отправлять промежуточные звенья. (Или клиенту необходимо доверять корню для клиентского сертификата)

С другой стороны, действуют те же правила. Разница в том, что в обратном вызове вы можете перестроить цепочку, чтобы добавить дополнительные сертификаты.

private static bool IsExpectedRootPin(X509Chain chain)
{
    X509Certificate2 lastCert = chain.ChainElements[chain.ChainElements.Count - 1].Certificate;
    return lastCert.RawBytes.SequenceEquals(s_pinnedRootBytes);
}

private static bool ValidateServerCertificate(
    object sender,
    X509Certificate certificate,
    X509Chain chain,
    SslPolicyErrors sslPolicyErrors
)
{
    if ((sslPolicyErrors & ~SslPolicyErrors.RemoteCertificateChainErrors) != 0)
    {
        // No cert, or name mismatch (or any future errors)
        return false;
    }

    if (IsExpectedRootPin(chain))
    {
        return true;
    }

    chain.ChainPolicy.ExtraStore.Add(s_intermediateCert);
    chain.ChainPolicy.ExtraStore.Add(s_pinnedRoot);
    chain.ChainPolicy.VerificationFlags |= X509VerificationFlags.AllowUnknownCertificateAuthority;

    if (chain.Build(chain.ChainElements[0].Certificate))
    {
        return IsExpectedRootPin(chain);
    }

    return false;
}

Конечно, проблема с этим подходом заключается в том, что вам также необходимо понимать и предоставлять промежуточное звено на удаленной стороне. Реальное решение этой проблемы состоит в том, что промежуточные звенья должны быть доступны на конечной точке распространения HTTP, а выданные сертификаты должны нести расширение доступа к информации о полномочиях, чтобы иметь возможность динамически их обнаруживать.