SSLScan queries SSL services, such as HTTPS and SMTP that supports STARTTLS, in order to determine the ciphers that are supported. SSLScan is designed to be easy, lean and fast. The output includes prefered ciphers of the SSL service, the certificate and is in Text and XML formats.
Where to download
SSLScan.exe [Options] [host:port | host]
--targets=<file> A file containing a list of hosts to
check. Hosts can be supplied with
ports (i.e. host:port).
--no-failed List only accepted ciphers (default
is to listing all ciphers).
--ssl2 Only check SSLv2 ciphers.
--ssl3 Only check SSLv3 ciphers.
--tls1 Only check TLSv1 ciphers.
--pk=<file> A file containing the private key or
a PKCS#12 file containing a private
key/certificate pair (as produced by
MSIE and Netscape).
--pkpass=<password> The password for the private key or
--certs=<file> A file containing PEM/ASN1 formatted
--starttls If a STARTTLS is required to kick an
SMTP service into action.
--http Test a HTTP connection.
--bugs Enable SSL implementation bug work-
--xml=<file> Output results to an XML file.
--version Display the program version.
--quiet Be quiet
--help Display the help text you are now
You can run SSLScan with either one-off by specifying host (and optionally the port number) on the command line or feed SSLScan a textfile that contains a host (and optionally a port number) per line (using the
If you are not interested in what protocols and ciphers the remote host does not support you can use the
--no-failed option to hide those results (highly recommended). If you are testing a HTTP-server you can also supply the
--http option which will send a HTTP-request to the newly created connection to see what status code your request supports (useful if server supports less secure protocols/ciphers but redirects to a page which tells the user to update their browser).
If you are testing SMTP/STARTTLS servers then you need to supply the
--starttls option instead.
Specifying protocol versions to test
In case you want to test a particular protocol version (SSLv2, SSLv3 and TLSv1 are currently supported) instead of all the protocols you can use the
--tls1 option respectively.
Using client certificates
Some servers does not want to talk with the connecting client unless it can identify itself using a client certificate. Use the
cert.p12 option to specify where to load the client certificate. If the certificate is protected by a password (which it should be) you can specify that using the
p12password option. Please note that the password will be visible to anyone on the same system due to the presence in command parameters.
Verifying server certificates
certs.pem option you can specify which root CA's you trust and want to verify the target server against. This option is still under development and only exists in the Google Code repository.
SSL implementation bugs
Not all SSL/TLS implementations are written correctly, so you might need to enable bug-workaround code using the
By default SSLScan output its test result directly to the screen using a human-friendly format. This is not always what you want/need. Human-readable format is not that good for software to parse. There is two machine-readable formats that you can use:
file.xml option writes the findings to a file in the XML-format. If you use the filename "stdout" the program will output the results to the terminal screen instead of a file. This can be very useful, especially with the --quiet option, if you call SSLScan from some other program and then want to parse the XML-file, which will be provided on stdout instead of a temporary file.
--pout is a undocumented and soon to be retired feature that outputs the collected results in a more grep-friendly format, which is inspired by nMap's greppable format.
--version tells you which version of SSLScan you are running.
--quiet just runts the test without outputting anything on the screen. Can be a useful flag when combined with
--help provides you with a help-message which basically tells you what options SSLScan supports.