Schannel errors and the alert codes - What does the alert code mean

SSL / TLS  Alert Protocol and the Alert Codes.

When a schannel error is logged in the system eventlog there will be an alert code as well.
The table below shows what the alert code means.
Now this isn't going to help you fix your issue but it will point you in the direction you need to investigate.

Alert Code	Alert Message	Description
0	close_notify	Notifies the recipient that the sender will not send any more messages on this connection.
10	unexpected_message	Received an inappropriate message This alert should never be observed in communication between proper implementations. This message is always fatal.
20	bad_record_mac	Received a record with an incorrect MAC. This message is always fatal.
21	decryption_failed	Decryption of a TLSCiphertext record is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were not correct. This message is always fatal.
22	record_overflow	Received a TLSCiphertext record which had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14+1024 bytes. This message is always fatal.
30	decompression_failure	Received improper input, such as data that would expand to excessive length, from the decompression function. This message is always fatal.
40	handshake_failure	Indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. This is a fatal error.
42	bad_certificate	There is a problem with the certificate, for example, a certificate is corrupt, or a certificate contains signatures that cannot be verified.
43	unsupported_certificate	Received an unsupported certificate type.
44	certificate_revoked	Received a certificate that was revoked by its signer.
45	certificate_expired	Received a certificate has expired or is not currently valid.
46	certificate_unknown	An unspecified issue took place while processing the certificate that made it unacceptable.
47	illegal_parameter	Violated security parameters, such as a field in the handshake was out of range or inconsistent with other fields. This is always fatal.
48	unknown_ca	Received a valid certificate chain or partial chain, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known, trusted CA. This message is always fatal.
49	access_denied	Received a valid certificate, but when access control was applied, the sender did not proceed with negotiation. This message is always fatal.
50	decode_error	A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This message is always fatal.
51	decrypt_error	Failed handshake cryptographic operation, including being unable to correctly verify a signature, decrypt a key exchange, or validate a finished message.
60	export_restriction	Detected a negotiation that was not in compliance with export restrictions; for example, attempting to transfer a 1024 bit ephemeral RSA key for the RSA_EXPORT handshake method. This message is always fatal.
70	protocol_version	The protocol version the client attempted to negotiate is recognized, but not supported. For example, old protocol versions might be avoided for security reasons. This message is always fatal.
71	insufficient_security	Failed negotiation specifically because the server requires ciphers more secure than those supported by the client. Returned instead of handshake_failure. This message is always fatal.
80	internal_error	An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue, such as a memory allocation failure. The error is not related to protocol. This message is always fatal.
90	user_cancelled	Cancelled handshake for a reason that is unrelated to a protocol failure. If the user cancels an operation after the handshake is complete, just closing the connection by sending a close_notify is more appropriate. This alert should be followed by a close_notify. This message is generally a warning.
100	no_renegotiation	Sent by the client in response to a hello request or sent by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert; at that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate would be where a server has spawned a process to satisfy a request; the process might receive security parameters (key length, authentication, and so on) at start-up and it might be difficult to communicate changes to these parameters after that point. This message is always a warning.
255	unsupported_extension

 Source

Enable Exchange 2013 Remote PowerShell over SSL

I ran in to this super clear explanation from Damian Scoles on how to configure remote PowerShell over SSL when my remote PowerShell wasn't working.

I covered the same subject once before here - remote-powershell-sessions-for-ad

This goes on step further in securing the session:

For Office365 an SSL connection to remote PowerShell is default.

$LiveCred = Get-Credential
$Session = New-PSSession -name ExchangeOnline -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Also note that the authentication type is BASIC.

If you try to force the PowerShell virtual directory to only accept SSL, you break local PowerShell access:

Set-PowerShellVirtualDirectory -Server ex01 -RequireSSL $true

Now that PowerShell access is broken we cannot run PowerShell commands to fix the PowerShell Virtual Directory? So switch to IIS Manager. At the PowerShell virtual directory ‘Require SSL’ is checked:


Uncheck the box and click apply.

Local Exchange PowerShell is working again.
Now how do we enable SSL remote PowerShell?
Lets make sure we can do PowerShell remoting over HTTP:

Verify it’s enabled:

Enter-PSSession -ComputerName localhost

If you receive an error, then PowerShell remoting can be enabled with this command:

Enable-PSRemoting

Choose ‘A’ for the answer to the two questions:



Now that we have PowerShell enabled, verify the user account you want to connect with has access:

Get-User <alias> |ft displayname,*power*,

If the result is True, then the user has permission to connect remotely via PowerShell.

What about SSL? Let’s see what happens by default:

New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<exchange server FQDN>/PowerShell/ -Credential (Get-credential) -Authentication Kerberos

** Note ** Using Basic for Authentication method will cause the connection to fail. Either have no

Authentication defined, or choose something like kerberos in our example.

You will be prompted for credentials and allowed to connect. If however the connectionURI contains HTTPS and not HTTP, it will fail.

New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://<exchange server FQDN>/PowerShell/ -Credential (Get-credential) -Authentication Kerberos

So what is the fix? IIS Authentication. The PowerShell virtual directory has no authentication settings configured

Get-PowerShellVirtualDirectory -Server <Exchange Server> | fl *auth*

Notice that no authentication is configured by default. Let’s enable Basic Authentication as this will allow us to use an SSL connection to remotely connect via Powershell.

Get-PowerShellVirtualDirectory -Server <exchange server> | Set-PowerShellVirtualDirectory -BasicAuthentication $true

Now that we have verified PowerShell Remoting is enabled, that our user account has access and that Basic Authentication is enabled, we should be able to connect via HTTPS:







We now have a successful connection to our remote Exchange 2013 server over HTTPS.

Source