Common Windows Security Errors

There are many posts online listing many different possible causes for these errors, so it's not possible for this article to encompass all the solutions. These are just solutions to common causes for these errors. If the suggestions listed here don't work for you, please email support at support@nsoftware.com

Errors

• 80090302
• 8009030D
• 8009030E
• 80090304
• 80090308
• 80090325
• 80090326
• 80090327
• 80090331
• 8009035D
• 8009030F and 80090321

0x80090302

This error can occur when the component is using an older version of TLS, but the server requires a newer version. For instance if the component is using TLS 1.0, but the server requires TLS 1.2, you can see this error. Older versions of the components may not have the newer protocols enabled by default. In the current versions TLS 1.2 is enabled by default.

Possible Solutions

• Enable Supported Protocol Versions

  This can be done on any of the components that support SSL by using the SSLEnabledProtocols configuration setting. As an example setting the Icharge component to use TLS 1.2 would look like this

  icharge1.Config("SSLEnabledProtocols=4032");

  Please note the documentation linked above is specifically for the current .NET Editions. For other editions or older versions please reference the help file included with the product.

0x8009030D

This error is often seen when using PEM keys, and translates to "The credentials supplied to the package were not recognized".

Possible Solutions

• Translate the PEM file into a PFX file.

  Using OpenSSL, the certificate can be converted with the command:

  openssl pkcs12 -export -passout pass:"" -in cert_key_pem.txt -out cert_key_out.pfx -name "My Certificate"

  Then change the SSLCertStoreType to PFXFile in your code, before setting the SSLCertSubject.

• Ensure the Network Service account has access to "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA."
• If using a certificate from a Windows certificate store verify the certificate was imported wit the "Mark this key as exportable" option checked.
• If you are running the components from IIS, ensure that the Application Pool has Load User Profile set to true.

0x8009030E

This error translates to "No credentials are available in the security package".

Possible Solutions

• When using a certificate for client authentication, ensure the certificate's private keys are accessible. The certificate in the Windows certificate store must contain the corresponding private keys, and be marked as exportable.
• Ensure that the current user and administrators have full access to "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys".
• Import the certificates directly into both LOCAL_MACHINE\Personal and ADAM\Personal if ADAM is installed.

0x80090304

This error translates to "The Local Security Authority cannot be contacted ".

• This error may to be related to Windows rejecting weak security. Microsoft KB 3061518 explains the issue. To summarize the article, simply set the ClientMinKeyBitLength DWORD value at the following location to 00000200.

  
  HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman

  After a restart, if this corrects the issue, then it is an indication that the server's certificate uses a DHE Key length that is too small and should be updated.
• Additional reasons and solutions for this problem are detailed in Microsoft KB 813550

0x80090308

This error translates to "The token supplied to the function is invalid ".

Possible Causes

• The server is using a certificate with an outdated signature algorithm. See this MSDN Article
• The server doesn't expect SSL over this port. Set the SSLStartMode property to sslExplicit.
• FileZilla and other FTP servers require a PROT P command to be sent for the data connection when using implicit SSL. Set the UseProtWhenImplicit configuration setting to True.
• The server returns a large number of CA's in the handshake.

Also see this Knowledge Base article about this error: SSL: Error During Handshake: 80090308

0x80090325

This error translatest to "The certificate chain was issued by an authority that is not trusted."

The SSL client certificate specified in the request was not accepted by the server. During the SSL handshake the issuer certificates of the SSL client certificate are not included. In Linux the OpenSSLCADir configuration setting must be set to the directory where the hash files exist so the chain is included. In Windows the issuer certs must be in the Personal store. In Java, the issuer certificates are read from the PEM file.

0x80090326

This error translates to "The message received was unexpected or badly formatted."

Possible Solutions

• This error may also happen if the server and client don't posses a common supported cipher suite. This can be the case if you're connecting from Windows XP to a site that has recent/strict security requirements. Here is a list of ciphers supported in XP. Setting UseInternalSecurityAPI to true may help with this error as it supports many newer protocols not supported on older systems.
• Client authentication is required. Ensure that you are loading the certificate correctly.
• The server does not support the SSL Client Hello version being used. Set the SSLEnabledProtocols configuration setting to an appropriate value.
• The server does not support SSL session re-use. You can disable this by setting the ReuseSSLSession and/or ReuseSSLSessionInDI configuration setting to false.
• The server returns SSL handshake packets larger than 16K. This is a CryptoAPI limitation.

In ThreeDSecure, this error is typically related to a problem with client authentication.

0x80090327

This error translates to "An unknown error occurred while processing the certificate."

This usually means that the server requires SSL client authentication and a new certificate is specified. Check the SSLStatus Event for details.

0x80090331

This error translates to "The client and server cannot communicate, because they do not possess a common algorithm".

Most commonly, especially with Windows XP/Windows Server 2003, the client is probably old and doesn't support the newer ciphers required by the server. Here is a list of ciphers supported in XP.

0x8009035D

This error translates to "One or more of the parameters passed to the function was invalid."

Possible Solutions

• Similar to 80090304, this error may to be related to Windows rejecting weak security. Microsoft KB 3061518 explains the issue. To summarize the article, simply set the ClientMinKeyBitLength DWORD value at the following location to 00000200.

  
  HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman

  After a restart, if this corrects the issue, then it is an indication that the server's certificate uses a DHE Key length that is too small and should be updated.
• The below Windows updates have been known to cause the issue:
  • KB3172605
  • KB3175024
  • KB3177186
  • KB3184122
  • KB3185911
• Additional reasons and solutions for this problem are detailed in Microsoft KB 813550

0x8009030F or 0x80090321

These errors are known to occur on Windows 8.1 and Windows Server 2012 R2 when using TLS 1.2 and one of the following cipher suites:

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

The aforementioned versions of Windows have a bug in their internal security implementations which, under very specific circumstances, can produce either the 0x80090321 (SEC_E_BUFFER_TOO_SMALL) error or the 0x8009030F (SEC_E_MESSAGE_ALTERED) error.

Due to the nature of the issue, we cannot provide a direct fix. However, you can work around these errors by doing one of the following things:

• Use our internal security API by passing the string "UseInternalSecurityAPI=True" to the Config() method. Our internal security API does not rely on the Windows security APIs, so it is not affected by the bug.
• Disable the two cipher suites mentioned above
• Disable support for TLS 1.2
• Upgrade your machine to a newer version of Windows