This is part of a series of articles about IT Mapping
Managing SSL certificates on your network can be challenging. As more and more software today uses encryption, you have more and more certificates you need to keep track of. These certificates can come in many shapes and forms which can make finding them difficult. They can be encoded in Base64 or DER, they can be in various key stores such as JKS stores or the windows certificate store, or they can be encrypted files somewhere on your file system. There is only one place where all certificates look the same no matter in which format they are stored – the network.
SSL Certificates over the network
Contrary to popular belief, when traffic between servers is encrypted using TLS or SSL, the certificates themselves are actually not encrypted. If you think about this, it isn’t too surprising. Before establishing a secure connection between a client and a server, the client needs to read the certificate information to make sure that it trusts the server. The full certificate information is sent over the network by the server to the client as part of the SSL Handshake protocol. (For more information, see our Guide to Microsegmentation.)
The format of this information is dictated by the SSL protocol which makes the data that is sent identical no matter how and where the certificate is actually stored on the server. We can use this to answer some basic questions for any SSL certificate:
-
- Which SSL certificates are actually in use – The fact that a certificate file exists somewhere on a server does not necessarily mean that certificate is actually being used. If it is sent over the network to a client, it is definitely in use.
-
- Where a certificate is being used – SSL certificates, especially those using wildcard common names, may be copied and used in more than one server. Using the serial number of a certificate, we can track all the servers use a specific certificate.
-
- When the certificate is expiring – One of the most important thing to keep track of with SSL certificates is when they expire. An expired certificate can break applications and can cause significant downtime until the certificate is found and replaced. Knowing ahead of time when a certificate will expire can save us from this.
(Need to find and manage all your SSL certificates? Start a free trial of our SSL certificate mapping feature to the right!)
Lanir specializes in founding new tech companies for Enterprise Software: Assemble and nurture a great team, Early stage funding to growth late stage, One design partner to hundreds of enterprise customers, MVP to Enterprise grade product, Low level kernel engineering to AI/ML and BigData, One advisory board to a long list of shareholders and board members of the worlds largest VCs
Tips from the Expert
In my experience, here are tips that can help you better manage and monitor SSL certificates on servers:
- Automate SSL certificate discovery
Use automated tools that continuously scan your network for SSL certificates. This reduces the risk of missing any certificates, especially those on non-standard ports or in less obvious locations. - Implement certificate expiration monitoring
Set up automated alerts for certificate expiration dates. Ensure that your system notifies you well in advance, such as 30, 60, and 90 days before expiration, to avoid unplanned downtime. - Use centralized certificate management
Implement a centralized certificate management platform that can store, track, and deploy SSL certificates across your network. This helps in maintaining consistency and reduces the complexity of managing certificates manually. - Leverage certificate transparency logs
Regularly monitor certificate transparency logs to detect any unauthorized issuance of SSL certificates for your domains. This helps in identifying potential security breaches early. - Enforce strict certificate policies
Implement strict policies for SSL certificates, such as mandatory use of strong encryption algorithms and minimum key lengths. Regularly audit certificates against these policies to ensure compliance.
How to find SSL Certificates using Wireshark
Wireshark is one of the more popular network protocol analyzers and it is available for free from https://www.wireshark.org/.
There are many different methods we can use to get network traffic for the relevant servers depending on the environment. For some examples, you can see our blog post on getting network traffic in VMware environments here: https://staging-faddomnew-staging.kinsta.cloud/network-visibility-in-virtual-environments-1/.
Wireshark has advanced traffic filtering capabilities for finding the information we want. In our case, we can use the filter: tls.handshake.certificate. If needed, we can also filter out the servers based on subnets to exclude any certificates we may be getting from other servers that are not in our environment. This can be done using the filter:
tls.handshake.certificate && ip.src == [Subnet CIDR Notation]
Each of the packets returned by this filter should have SSL certificate information like the following:
In the certificate details, we can find information such as the validity, subject, algorithm and any other details for this certificate. We can also see which server it is on and what port that server is listening on in the Source field of the Internet Protocol header and the Source Port of the Transmission Control Protocol header. This information can help us locate the certificate file on the server.
Finding the certificate file on the server
Once we have the server and port for the certificate, we can move on to try to identify the location of that certificate.
Connect to the server using RDP for windows or SSH for Linux and use the netstat command to find which process is listening on the port we found earlier (replace <Port Number> with the port we found earlier):
Windows: netstat –nao | find “LISTEN” | find “<Port Number>”
Linux: netstat -nap | grep LISTEN | grep <Port Number>
On both operating systems, the right most column will be the process id of the process that is listening on that port.
Once the process is identified, you can use either task manager on Windows or the ps -ef command on Linux to identify the process and use that information along with the documentation of whatever service is running in order to find the configuration file that points to the SSL certificate file.
Conclusion
Finding SSL certificates in order to manage or upgrade them can be a real challenge. Here we have shown an alternative way to find and track the usage of these certificates. Because the solution is based on network traffic, we can use it to find the certificates in use on multiple servers at once without needing to run or install anything on those servers. If we can get the network traffic for those servers, we can find the details on the certificates. In addition, this will also work for finding SSL certificates in use on non-standard ports and not just on port 443 which is usually used for HTTPS traffic.
(Don’t forget! Need to find and manage all your SSL certificates? Start a free trial of our SSL certificate mapping feature to the right!)
