ConfigurationLoadCredential failed, 0x80070057!

[savaspapadopoulos]

Hi I have a Windows build of msquic but with OpenSSL.

I've tried it on several operating systems. The same binaries work on Windows 10 and Windows Server 2022 without issues. Same settings everywhere.

When I run it on Server 2016 using a self-signed certificate (created with same Powershell command on all platforms)
it shows this error:
Quic -server -cert_hash:6B6E9F9D8515AA64A875B2B95E78CC49D92E7E38
ConfigurationLoadCredential failed, 0x80070057!

Then I tried an OpenSSL self-signed certificate and it works:
MsQuic -server -cert_file:cert.pem -key_file:key.pem

However the same call through -cert_hash works on Server 2022 and Windows 10. It doesn't work on Server 2016
the error is: ConfigurationLoadCredential failed, 0x80070057

1. Does anyone know what the problem might be?

2. Is there any way to make this build also work on Windows 7 SP1 and/or Server 2008 R2 or at least Server 2012 R2? Upon starting the executable the following error shows:
   the procedure entry point bcrypthash could not be located in the dynamic link library

Thanks

[nibanks]

Windows Schannel doesn't support TLS 1.3 before Windows Server 2022.

[savaspapadopoulos]

Thanks for the reply Nick
even though this is a Windows build, it was built with OpenSSL instead. It took quite a bit of hair loss to get there :)
Are there any other dependencies on Schannel even when it's built with OpenSSL? Because the build docs explicitly state that one could build with OpenSSL on Windows to avoid the TLS 1.3 issue.
I used the quicsample.exe for testing.

Could it be that these parameters quicsample.exe -server -cert_hash:<> somehow force the route through SChannel
while these do not: quicsample -server -cert_file:cert.pem -key_file:key.pem

[anrossi]

The cert_hash parameter uses CAPI on Windows to look up the certificate in the Windows Certificate Store, even when OpenSSL is the TLS provider. If your certificate is not created with an exportable private key, then CAPI can't give the certificate and private key to OpenSSL to do the TLS handshake.
the cert_file and key_file parameters are OpenSSL-specific, and tell OpenSSL to load the certificate and private key directly from file.

[savaspapadopoulos]

Thank you anrossi for your reply. I used the same PowerShell script on all OSes that I tested:

New-SelfSignedCertificate -DnsName $env:computername,localhost -FriendlyName MsQuic-Test -KeyUsageProperty Sign -KeyUsage DigitalSignature -CertStoreLocation cert:\CurrentUser\My -HashAlgorithm SHA256 -Provider "Microsoft Software Key Storage Provider" -KeyExportPolicy Exportable

As you can see the exportable option is set at the end. Windows 10 + Server 2019 + Server 2022 worked perfectly.
Could it be there are some breaking CAPI differences between Server 2016 and Server 2022?

The other issue, on Server 2012 R2 the sample (executable) won't even load: "the procedure entry point bcrypthash could not be located in the dynamic link library". Note it's all statically linked.

If all of this is related to CAPI, perhaps we could find a way to remove all of the CAPI references / dependencies....?

[anrossi]

I don't know for certain, but it's very likely there's been changes to CAPI between Server 2016 and Server 2022.
Regarding Server 2012 R2, we've identified a change we could make that might solve that problem.
However, if you want to load a certificate from the Windows Certificate Store into an OpenSSL build, CAPI is required. There's no way around that.
If you can have your certificate in an OpenSSL-compatible format, then CAPI can be avoided.

[bialix-electronicus]

Do you have any luck with bcrypthash problem?

"The other issue, on Server 2012 R2 the sample (executable) won't even load: "the procedure entry point bcrypthash could not be located in the dynamic link library". Note it's all statically linked."

I have similar problem with pre-Windows 10 - but strangely release build does not trigger such error. Do you have problem in release build as well?