I'm not sure if there's an automated way to do this.
First, I would list all the ports that are listening and match the ports to the process/executable (for example, with
netstat -t -l -p, as root to be able to see the process ID (PID)).
You'll get entries like this, where the PID is:
tcp 0 0 *:https *:* LISTEN 5221/apache2
This tells you which program is running on port
netstat -t -l -p -n if you just want the port number, in which case you'll see
*:443 instead of
*:https). This tells you that there's a socket listening on port 443. In addition, here, 5221 is the PID for apache2, so that also tells you which application is being used. Sometimes, it may not be immediately visible which application is being used (you can look at the content of
/proc/5221/cmdline to see more details for example).
I would only focus on the entries that are bound to external interfaces (and ignore the
Typically, you may see something listening on port 22 (ssh), 80 (http), 443 (https), ...
You'll then have to test them one by one depending on the method described below.
echo "" | openssl s_client -connect your.host.name:80 should show an error message, since your web server wouldn't (or shouldn't) listen to SSL/TLS requests on this port,
echo "" | openssl s_client -connect your.host.name:443 should work and show you some information regarding the certificate and the connection.
For up-front SSL/TLS, you can check whether it will accept a TLS
ClientHello (i.e. be a TLS server from the start of the connection), but using
echo "" | openssl s_client -connect hostname:port (
echo "" | is optional, it will just stop openssl as soon as it has established the connection, as you probably don't want to send anything specific).
For "upgraded" SSL/TLS connections, done after a command at the application protocol level (such as
STARTTLS), this can be trickier.
You can do this for by adding
-starttls the_name_of_the_protocol to this
openssl s_client command. According to the OpenSSL documentation, "Currently, the only supported [protocol names] are "smtp", "pop3", "imap", and "ftp"".
This won't help you for LDAP (if configured to use Start TLS and not up-front TLS), MySQL, PostgreSQL, ... For these, you may simply have to look into their respective configuration files.
Automating this process would require a tool that can understand all these protocols, which can be quite difficult.
A couple of additional points, if it's for a more general security audit:
Enabling SSL/TLS is rarely enough. You also want to make sure it's configured properly: valid certificate, SSLv2 disabled, trying to move to the higher values of SSL/TLS (SSLv3, TLSv1.0, TLSv1.1+) by disabling older versions if your user-base is sufficiently compatible, insecure renegotiation disabled if possible, reasonably strong cipher suites.
Despite using the OpenSSL library, OpenSSH (and SSH in general) is not based on SSL/TLS. You might still want to keep this one, even if your policy is to use SSL/TLS-only services.