TLS 1.2 - The token supplied to the function is invalid

.net, cryptoapi, cryptography, ssl, tls1.2

Solution

I finally figured this out. "The token supplied to the function is invalid" in this context means a "Certificate on the chain is signed with an unsupported or disabled algorithm."

It turns out in practice this almost always means disabled. The list of enabled algorithms is found in `HKEY_LOCAL_MACHINE` `SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003` `Functions`. This is a `REG_MULTI_SZ` with one string per supported algorithm.

I found these values on my Windows 10 machine:

RSA/SHA256
RSA/SHA384
RSA/SHA1
ECDSA/SHA256
ECDSA/SHA384
ECDSA/SHA1
DSA/SHA1

And I added

RSA/SHA512
ECDSA/SHA512

Your key would start working if you added `RSA/MD5` however it cannot be emphasized enough this is a bad idea and will open your system up to accepting forged certificates because `MD5` has been broken.

Filezilla is working because Mozilla distrusts the host cipher suite.

Problem

I have this strange problem, SslStream.AuthenticateAsClient() throws following exception: ``` System.Security.Authentication.AuthenticationException : A call to SSPI failed, see inner exception. ----> System.ComponentModel.Win32Exception : The token supplied to the function is invalid ``` It happens only when Tls12 is required by the client: ``` SslStream.AuthenticateAsClient(..., ..., SslProtocols.Tls12); ``` Code works properly for Ssl3, Tls11 and Tls. Server certificate is self-signed and 'old'. It uses md5RSA signature and 1024 bits, and innitially I thought that is the problem, as re-generating the certificate makes the exception go away (I tired both SHA1 and SHA512 - both ok). However, to my surprise FileZilla client is able to connect to this server using this 'old' md5RSA-signed cert and using TLS 1.2: Here is the certificate: ``` -----BEGIN CERTIFICATE----- MIICejCCAeOgAwIBAgIQzbvZdHHAV49D7R8OE2mEaDANBgkqhkiG9w0BAQQFADBA MSswKQYJKoZIhvcNAQkBFhxlbWFpbEBpbi10aGUtY2VydGlmaWNhdGUuY29tMREw DwYDVQQDEwhKb2huIERvZTAeFw0xMTAxMjAyMDAzNDFaFw0zOTEyMzEyMzU5NTla MEAxKzApBgkqhkiG9w0BCQEWHGVtYWlsQGluLXRoZS1jZXJ0aWZpY2F0ZS5jb20x ETAPBgNVBAMTCEpvaG4gRG9lMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0 s5RAKYdw2AYk3t0oH5jDo6RQRRfabkOLfKvR8kOiYbqjtgblx7JhSZJHX/r6KLoc hGgYkQPOSKnl8TdgEkzPxWHECV/iMdOxTsTv2P//ZM2INjb4H8JjDS16PYFwHP3w /9RU6PjppK+mPdWP1pezBzebSM0QQwpmXlSmfe2ULQIDAQABo3UwczBxBgNVHQEE ajBogBA4WNgTvhkmRD8DhHeRvAJcoUIwQDErMCkGCSqGSIb3DQEJARYcZW1haWxA aW4tdGhlLWNlcnRpZmljYXRlLmNvbTERMA8GA1UEAxMISm9obiBEb2WCEM272XRx wFePQ+0fDhNphGgwDQYJKoZIhvcNAQEEBQADgYEAFX6MM/E97hC6t1TAFBmM3tWr fQ2cB0LFCe6J0I8phKQecpSYCkMdvaHdsT+sdzXNW4bgL064r731r8l/47VgfgIR oRmsQYnwJ55nqZpEW2zL3vioedWiCVto8X9/dVC8jqPpcmMP5NWBHh88o7nkPBxe C8iucrQvHnjYwaz1o/M= -----END CERTIFICATE----- ``` My questions are: Why `SslStream.AuthenticateAsClient` throws, whereas Filezilla client is able to connect? Are there any .NET/Windows 10/CryptoAPI certificate restrictions when TLS 1.2 is used? If there are restrictions, why FileZilla is not enforcing them? Why so cryptic error message: 'The token supplied to the function is invalid'?

Original source