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

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

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

var cert = new X509Certificate2(certPath, certPass);

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

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

• Предоставляется как ручной ввод через X509Chain.ChainPolicy.ExtraStore
  • Поскольку рассматриваемая цепочка построена SslStream, вы не можете сделать это здесь.
• ТекущийПользователь\Мой X509Store
• *LocalMachine\Мой X509Store
• CurrentUser\CA X509Store
• **LocalMachine\CA X509Store
• CurrentUser\Root X509Store
• **LocalMachine\Root X509Store
• *LocalMachine\ThirdPartyRoot X509Store
• Расположение http (не-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, а выданные сертификаты должны содержать расширение доступа к информации о полномочиях, чтобы можно было найти их динамически.