Checking TLS certificates in use

In the efforts to secure communications over TCP/IP, we often have to deal with the certificates that are the keys to the process. Checking that the correct and correctly configured certificate (or cert for short) is the one running, is an essential troubleshooting/validation step. 

The best way where possible is to check the running cert on the running service. Especially that the correct cert that is being used.  Typically, we'd be looking at the dates that it is valid, the name (subject or common name), and the Subject Alternative Name (SAN)

For Web interfaces, a browser is the ultimate testing tool, with Firefox being the (currently in 2026) most consistent to work with, but the general concepts are the same with the others even if done differently.  If there is a problem stopping you from getting to the page, you just have to pause there, because the details are already available. 

Firefox:

For some issues, it will offer you to look at the cert below the scary sounding warning, if so, that is the easy option. Otherwise, if you've accepted the risk already or it is a good cert, you should see a little shield in front of the URL. The shield shows with a checkmark in it for good, or an Exclamation mark (Not Secure) if not.

Click on that shield, and in top right of that sub-window click on "Connection {not} secure" as the case may be.  Select "More site Information" at the bottom, and then View Certificate to see a page with all the details that you can 'print' for your records (usually to pdf or such)

Chrome (and related):

If there is a cert issue stopping you with the dreaded "Your connection is not private", click on the red "Not secure" in front of the URL, where you will see the option for Certificate details to click on, and then look at. The first tab has some useful basics, but often we need to look at the details tab to expand the fields you want to look at, such as to find the Extension of 'Certificate Subject Alternative Name'. The Export option saves an actual public key that can be looked at with tools such as openssl or KeyStore Explorer that we'll discuss further down.

If the cert is accepted as a secure one, click on the slider 'tune' button in front of the URL, click on "Connection is secure", click on the "Certificate is Valid" to see the Certificate details described above. 

Other options:

If you have to do this regularly, there is a GUI tool called  https://keystore-explorer.org/  KeyStore Explorer that works with most GUI. 

For our purposes, select 'Examine', 'Examine TSL/SSL', enter the target host and port, 

With the next page not directly showing the SAN, that is one of the Extensions, where if the cert has a SAN, you see the Extension, and clicking on it shows the value(s)

Linux Systems:

If you are on a Linux system (or can shell into), we can use https://en.wikipedia.org/wiki/OpenSSL openssl from the command line without an install. Other operating systems typically need an install.

 # openssl s_client -showcerts -connect {serverIP|FQDN}:443 |openssl x509 -noout -text |less

 # openssl s_client -showcerts -connect google.com:443 |openssl x509 -noout -text |less

While the default secured web traffic set to port 443, others can readily be used and often are used for administrative interfaces.  Also, there are many other services that use TLS to secure them, and this is where the openssl command and KeyStore Explorer are our most available options to look at them. 

Direct file examination:

 #  openssl x509 -in server.crt -text -noout

or with KeyStore Explorer, 'Examine' from the menu, 'Examine File', browse to the file to be examined.

There are other options and ways, this is just the primer as I found many who need these steps don't know them off of hand, so this is an effort to make it easy. 

Why SSL(TLS) is a must for all websites.

What is SSL/TLS?

They are the evolving encryption tools that are the difference between a web page (via HTTP) that can be clearly Intercepted and ALTERED, and a page (via HTTPS) that is both encrypted with a chain of trust that makes it extremely difficult to view and even more difficult to alter in any way.  If you want to know more, you can read more here. 

To answer the questions of:

 - Why are some browsers making so much noise about why your unSSLized site is so untrustworthy?

 - Why your unsecured site is so low on the search engines?

Reason #1, the big one.

If your website doesn't have a proper TLS/SSL encryption in place, then if someone can intercept a person's browsing, it is easy to inject whatever hostile code is desired. It could be to just change what is showing on the page (this site hacked!), to silently injecting the latest ransomware or worse. 

You want your readers to get the message you so carefully crafted, not something else. You don't want them to equate you with putting malware on their system.

Reason #2
There is a pile of constant malicious scanning going on all the time, and just forcing your site to HTTPS causes a good portion of it hitting your site, to just go away.  One of my sites was getting many dozens a month of links from very dubious sites before I forced a switch to SSL, then they just went away.

There is then the whole Cyberwar part it of, where you could be caught in the middle of the big boys playing, as what was clearly happening as a part of a real hot war with the Russian Invasion of Ukraine as written up at the Internet Storm Center   where an entire block of IP addresses are redirected to another set of servers away from Twitter for a portion of the world.  Just too many ways for Man-In-The-Middle attacks.

So assuming you:

 - Don't want your readers scared away by the browser warnings

 - Don't want your readers to get used to a bad security practice because you taught them to

 - Don't want your readers' devices to become part of a hostile bot-net and/or worse.  

 - Would like (love?) your content to be more readily found by having a higher position in the search engines.

To get there

 This is done on the web-server itself, where you either pay for a certificate or use a free certificate service such as Let's Encrypt.  First you want to make sure your site works with the certificate so that you can get that lock in front of your URL (aka address) in the browser, and then you want to set it so that all attempts to come in unencrypted (port 80) get flipped/redirected to encrypted (port 443)

If you built your server, it is time to go RTFM for this as it is well documented for all Web-servers, as well as many others have written about the process. Your favourite search engine can also point you to resources.

If you are using a more typical hosted service, there is a very good chance the ability is sitting there in your control panel, just waiting to be turned on. Automatic free encryption has been a part of CPanel for a couple of years now (my hosters turned it on automatically for me), and a quick search shows that many of the others have a similar feature.  So take a look at your control panel, use the knowledge base most hosters setup, or even contact your support to see how good they are. 

There will be attempts to up-sell you to a higher grade of certificate.  If you just have a basic, low volume static site, then there is no real value in the "enhanced protections".  If you are gathering anything beyond comments and email addresses, such as e-commerce orders, then an actual purchased certificate makes some sense.  If you do go with a purchased certificate, make sure your hoster manages it and the update/renewal process, that they should have, is automated as certificates only last a year or less.

Do you require any assistance in securing your systems? Perhaps we can help.