Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I using SSLSCAN to check the cipher suites of my server, I found that there are three status: Accepted, Rejected and Failed. After that, I tried to disable the ciphers of RC2(40bits). I created a new key "Enabled"=dword:00000000 under [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]. The SSLSCAN showed EXP-RC2-CBC-MD5 (40bits) was "failed" but the rest of RC2 (40bits) ciphers were "Rejected".

So this made me confused: what the difference between failed and rejected? I came across all the information on the google, including SSLSCAN main page, but haven't find a clear answer.

share|improve this question

I wondered about the same thing, looked at the source code (“Use the source, Luke!” :), and it simply is the return value of SSL_connect() from the OpenSSL library. The documentation states that:

  • Accepted (1) means:

    The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been established.

  • Rejected (0) means:

    The TLS/SSL handshake was not successful but was shut down controlled and by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the return value ret to find out the reason.

  • Failed (<0) means:

    The TLS/SSL handshake was not successful, because a fatal error occurred either at the protocol level or a connection failure occurred. The shutdown was not clean. It can also occur [if] action is need to continue the operation for non-blocking BIOs. Call SSL_get_error() with the return value ret to find out the reason.

The latter two can be followed by a N/A, if https is not available.

So I think sslscan should contain a --verbose or -v option that calls SSL_get_error() and outputs the actual reason it failed (or was rejected).
That would be rather useful. Because right now, it isn’t.

For now, all I can recommend is to manually connect with a more real-world client, force the usage of a certain cipher on said client or on the server, and then have it show you the actual reason.
Unless you want to improve sslscan’s code, of course. :)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.