Using the network and security checker

A step-by-step guide to network diagnostics using command-line tools; from SSL testing and open port scanning to ping and DNSSEC, along with interpreting results and resolving common errors.

6 min Updated 15 Oct 2026

Why is network diagnostics essential before any action?

When your website is slow, emails aren't being sent, or users see connection errors, the first step to solving the problem is network diagnostics. Many developers and server administrators jump straight to code or application settings, but the root cause is often in the network layer: a closed port, an expired SSL certificate, or an incorrect DNS record.

In this article, we provide a practical workflow for network diagnostics using command-line tools. You will learn how to perform SSL testing, scan for open ports, ping, and check DNSSEC, and how to correctly interpret the results. These methods can be run on Linux, macOS, and even Windows (with WSL or Git Bash).

Basic tools for network diagnostics

Before you start, make sure the following tools are installed on your system. Most of them are available by default on Linux distributions, but you can install them if needed:

  • ping – Check host reachability and network latency
  • nslookup or dig – DNS queries
  • openssl – Check SSL/TLS certificates
  • nc (netcat) or nmap – Port scanning
  • delv or dig +dnssec – DNSSEC validation

To install on Ubuntu or Debian, use the following command:

sudo apt update
sudo apt install dnsutils openssl netcat-openbsd nmap bind9-dnsutils

On CentOS or RHEL:

sudo yum install bind-utils openssl nmap nc

SSL testing and interpreting results

SSL certificates are one of the most common points of failure in network diagnostics. An expired or incorrect certificate causes the user's browser to show a security error and erodes customer trust.

Checking expiration date and certificate chain

The simplest method is to use openssl:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer

The output includes three important sections:

  • notBefore – Certificate validity start date
  • notAfter – Expiration date
  • subject and issuer – Domain name and issuing authority

If the expiration date is near (less than 30 days), it's better to renew the certificate before a problem occurs. To check the full certificate chain, use the -showcerts option:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

In the output, you should see at least two certificates: the main domain certificate and the intermediate certificate. If only one certificate is displayed, your server is likely not sending the full chain, and some clients will show errors.

Checking protocols and cipher suites

To ensure your server uses secure protocols, test TLS versions 1.2 and 1.3:

openssl s_client -connect example.com:443 -tls1_2 < /dev/null
openssl s_client -connect example.com:443 -tls1_3 < /dev/null

If the command fails with a no protocols available error, the server does not support that TLS version. TLS 1.2 support is the minimum requirement today, and TLS 1.3 is highly recommended.

Common mistake: Many administrators only check the expiration date and don't realize the certificate was issued for a different domain. Always compare the subject with your domain name. If you have both www and non-www domains, the certificate must have a SAN (Subject Alternative Name) that includes both.

Scanning open ports and interpreting results

Open ports are the entry points to your server. Network diagnostics to find unnecessary open ports is an important part of security.

Quick scan with netcat

To test a specific port, use nc:

nc -zv example.com 443
nc -zv example.com 22

The output succeeded means the port is open, and Connection refused means it's closed. The -z option performs the scan without sending data, and -v displays details.

Scanning multiple ports with nmap

For network diagnostics over a range of ports, nmap is a better option:

nmap -p 80,443,22,3306 example.com

The output has three states:

  • open – The port is open and a service is listening
  • closed – The port is closed but reachable (firewall is not rejecting)
  • filtered – A firewall or network filter is blocking the response

The filtered state usually means the port may be open, but the firewall is hiding it. For a more accurate diagnosis, use a TCP Connect scan:

nmap -sT -p 80,443 example.com
Troubleshooting tip: If port 80 is open but the browser shows a connection error, a software firewall (like iptables or firewalld) is likely blocking traffic. Check the rules with sudo iptables -L -n.

Ping and measuring network latency

Ping is the simplest tool for network diagnostics, but correctly interpreting its results is very important.

Testing reachability and packet loss

ping -c 10 example.com

The output includes the following statistics:

  • packet loss – Percentage of lost packets; zero percent is ideal
  • min/avg/max – Minimum, average, and maximum response time (RTT) in milliseconds
  • ttl – Time To Live; the default value is 64 for Linux and 128 for Windows

If packet loss is above 5%, the network is unstable. If the average RTT is above 150 milliseconds, the network path is likely long or congested.

Testing ping with different packet sizes

To check the impact of MTU (Maximum Transmission Unit) on the network, perform a ping with a large packet size:

ping -M do -s 1472 example.com

The -M do option prevents packets from being fragmented (Don't Fragment). If this command returns a Frag needed error, the path MTU is less than 1500, and you need to adjust it.

Common mistake: Some people think that if ping succeeds, the entire network is healthy. But ping only tests ICMP; port 443 might be closed or DNS might not be working. Always combine ping with port and DNS tests.

Checking DNSSEC and DNS validation

DNSSEC (Domain Name System Security Extensions) is the digital signing of DNS records. If DNSSEC is not configured correctly, users may receive SERVFAIL errors.

Checking DNSSEC signatures with dig

dig example.com A +dnssec +multi

In the output, look for the following:

  • RRSIG – Digital signature record for the response
  • DNSKEY – Zone's public key
  • status: NOERROR – Means the query was successful

If the output shows status: SERVFAIL, DNSSEC validation has failed. For a more precise diagnosis, use delv:

delv @8.8.8.8 example.com A +rtrace

The delv output shows which step in the validation chain failed. The most common issue is the absence of a DS record in the parent zone.

Checking basic DNS records

For network diagnostics, check the A, AAAA, MX, and NS records:

dig example.com A
dig example.com MX
dig example.com NS

If the A record points to the wrong IP, users will be directed to a different server. To check the propagation speed of DNS changes, use different servers:

dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

If the results differ, the changes are still propagating.

Summary: A complete workflow for network diagnostics

For systematic troubleshooting, follow this order:

  1. First, ping to ensure the host is reachable.
  2. Then, check DNS records with dig to confirm the correct IP.
  3. Next, test key ports (80, 443, 22) with nc or nmap.
  4. Now, check the SSL certificate with openssl.
  5. Finally, validate DNSSEC with dig +dnssec.

This method helps you isolate the problem as quickly as possible. If you see an error at any step, investigate that layer more deeply. For example, if port 443 is closed, check the server firewall; if DNSSEC returns an error, review the DNS zone settings in your domain control panel.

If you're looking for an infrastructure to run these tests on, ServerNet offers web hosting and cloud server services that you can use to practice network diagnostics. But regardless of the host, mastering these tools will turn you into a system administrator who can identify and resolve issues before they impact users.

network diagnosticsSSLopen portDNSSECnetwork troubleshootingcommand-line tools
Was this page helpful?