X509Store.Add Fails On Ubuntu 22.04 in FIPS Mode

[jamesmblair]

Description

Calling X509Store.Add(X509Certificate2 certificate) in .NET 8 on Ubuntu 22.04 in FIPS Mode fails with an OpenSslCryptographicException due to 3DES/SHA-1 being unsupported in FIPS mode. It appears the underlying issue is in the OpenSslDirectoryBasedStoreProvider used by X509Store on Linux systems. Instead of delegating certificate storage to an OS-level store/keychain, it appears this implementation is storing the certificate and key on the filesystem in PFX format. This export uses 3DES/SHA-1, which to the best of my knowledge is disallowed in FIPS 140-3, which Ubuntu 22.04 complies with.

Reproduction Steps

async Task ImportWithStreams(Stream certificateStream, Stream keyStream,
    CancellationToken cancellationToken = default)
{
    // Assume both Stream parameters are for PEM-formatted text.
    var certPem = await new StreamReader(certificateStream).ReadToEndAsync(cancellationToken);
    var keyPem = await new StreamReader(keyStream).ReadToEndAsync(cancellationToken);

    var privateKey = RSA.Create();
    privateKey.ImportFromPem(keyPem);

    var certificate = new X509Certificate2(Encoding.UTF8.GetBytes(certPem))
        .CopyWithPrivateKey(privateKey);

    var store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
    store.Open(OpenFlags.ReadWrite);
    store.Add(certificate); // Fails
}

Expected behavior

X509Store.Add should succeed on Ubuntu 22.04 using a FIPS-supported algorithm like AES/SHA-256.

Actual behavior

Stack Trace:

Unhandled exception: Interop+Crypto+OpenSslCryptographicException: error:0308010C:digital envelope routines::unsupported
   at Interop.Crypto.CheckValidOpenSslHandle(SafeHandle handle)
   at System.Security.Cryptography.TripleDesImplementation.CreateTransform(Byte[] rgbKey, Byte[] rgbIV, Boolean encrypting)
   at System.Security.Cryptography.PasswordBasedEncryption.Encrypt(ReadOnlySpan`1 password, ReadOnlySpan`1 passwordBytes, SymmetricAlgorithm cipher, Boolean isPkcs12, AsnWriter source, PbeParameters pbeParameters, ReadOnlySpan`1 salt, Byte[] destination, Span`1 ivDest)
   at System.Security.Cryptography.KeyFormatHelper.WriteEncryptedPkcs8(ReadOnlySpan`1 password, ReadOnlySpan`1 passwordBytes, AsnWriter pkcs8Writer, PbeParameters pbeParameters)
   at System.Security.Cryptography.RSA.TryExportEncryptedPkcs8PrivateKey(ReadOnlySpan`1 password, PbeParameters pbeParameters, Span`1 destination, Int32& bytesWritten)
   at System.Security.Cryptography.AsymmetricAlgorithm.ExportArray[T](ReadOnlySpan`1 password, PbeParameters pbeParameters, TryExportPbe`1 exporter)
   at System.Security.Cryptography.X509Certificates.UnixExportProvider.BuildBags(ICertificatePalCore certPal, ReadOnlySpan`1 passwordSpan, AsnWriter tmpWriter, CertBagAsn[] certBags, AttributeAsn[] certAttrs, SafeBagAsn[] keyBags, Int32& certIdx, Int32& keyIdx)
   at System.Security.Cryptography.X509Certificates.UnixExportProvider.ExportPfx(SafePasswordHandle password)
   at System.Security.Cryptography.X509Certificates.OpenSslX509CertificateReader.Export(X509ContentType contentType, SafePasswordHandle password)
   at System.Security.Cryptography.X509Certificates.X509Certificate.Export(X509ContentType contentType, String password)
   at System.Security.Cryptography.X509Certificates.OpenSslDirectoryBasedStoreProvider.AddCertToStore(ICertificatePal certPal)
   at System.Security.Cryptography.X509Certificates.OpenSslDirectoryBasedStoreProvider.Add(ICertificatePal certPal)
   at **REDACTED CALLING CODE**

Regression?

No response

Known Workarounds

No response

Configuration

.NET 8
Ubuntu 22.04 in FIPS mode

Other information

See: OpenSslDirectoryBasedStoreProvider.AddCertToStore(ICertificatePal certPal)

When OpenSslExportProvider.ExportPkcs8 calls ExportEncryptedPkcs8PrivateKey on the selected algorithm, it passes in s_windowsPbe, hard-coded parameters that are disallowed in FIPS 140-3:
https://github.com/dotnet/runtime/blob/6c58f7992cfd628a53d9b90f258ac123cb803644/src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslExportProvider.cs#L42C1-L42C2

runtime/src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/UnixExportProvider.cs

Line 20 in 6c58f79

internal static readonly PbeParameters s_windowsPbe =

Possibly related issues:

• Consider FIPS testing #110625
• [API Proposal]: X509Certificate.ExportPkcs12 with PBE parameters #80314

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[bartonjs]

Instead of delegating certificate storage to an OS-level store/keychain

There isn't one.

X509Store.Add Fails On Ubuntu 22.04 in FIPS Mode

Yep. Until we figure out a path forward, you'll have to either not export in the PFX format (which this does under the covers) or get out of FIPS mode.

[jamesmblair]

Sorry if I wasn't clear. I'm aware there isn't an OS-level keychain. I'm just highlighting how this issue is arising on Linux.

I've been able to work around this and manage my certificate a different way in the app that's running on the FIPS-mode machine, so this is not causing an ongoing production issue for me. I just wanted to kick off a discussion of the issue and some possible paths forward.

I think it's probably fine that the internal store on Linux is exporting to PFX format. The trouble is the 3DES/SHA-1 parameters being used. I know there will be compatibility considerations involved, but AES/SHA-256 would be a more secure (and FIPS-compatible) default. Maybe the algorithm could also be user-parameterizable by passing it as an option in some way to the X509Store, but that would leak Linux-specific implementation details that are irrelevant on Windows and macOS.

[vcsjones]

I think it would probably be fine to just use AES+SHA256 in Linux by default only for the OpenSslDirectoryBasedStoreProvider. It's an implementation detail of how the directory store works - we don't expect people to read files from that directory, and nor do we support people writing to that directory. Reading it back will of course continue to support 3DES+SHA1 for things already persisted.

The public API Export on X509Certificate2 will need to stay on 3DES+SHA1.

Ideally #80314 would be done first, which I am pretty close barring some questions for @bartonjs about where things need to live. If we do that, then it should be a matter of changing this line:

runtime/src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslDirectoryBasedStoreProvider.cs

Line 215 in 89ef51c

byte[] pkcs12 = copy.Export(X509ContentType.Pkcs12)!;

To use the new API.

This line:

runtime/src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslDirectoryBasedStoreProvider.cs

Line 88 in 89ef51c

var cert = new X509Certificate2(filePath);

Already supports reading back in either PBES1 or PBES2 algorithms.