PowerShell Scripts to Validate Your SSL Certificates

Started by davidkeller, Aug 30, 2022, 03:43 AM

Previous topic - Next topic

davidkellerTopic starter

SSL certificates should be checked regularly and carefully. In 2021, CAs stopped issuing two-year certificates. Unfortunately, at that time, many administrators did not find out about this in a very timely manner - for instance, when a re-release suddenly reduced the validity period to a year.

Now the situation is even more difficult.  At least at the moment we are talking about GeoTrust, Sectigo, DigiCert, Thawte, Rapid, but others may be added to this list. The sale of new and renewal of existing certificates for Runet domains is limited.

Checking whether the certificate is "alive" will not be difficult for the owner of one or two resources of labor. But what if you manage multiple services at once? Below I will provide four PowerShell scripts that will help you quickly check if an SSL certificate is up to date (including checking against custom ports), how many days it will expire, get information about the issuer of the certificate along the Certificate Chain, and possible issues when issuing/ certificate renewal.

Since now all SSL certificates are only valid for a year, these scripts are suitable not only for a one-time check, but also as a regular monitoring tool. Standard tools like Zabbix do not always know how to do this out of the box and require the installation of separate management packs / templates and other dances with a tambourine, for which there is not always time.

Why check certificates

First, I would like to explain what is currently happening with SSL certificates in general and why you might need the scripts below. Here are some facts about how the situation is today.

    On September 1, 2020, global certificate authorities stopped issuing two-year SSL certificates.

Since then, the maximum validity period for SSL certificates has been reduced to 398 days. I will not delve into the topic in detail - everything has already been explained here. I note that when re-issuing (for instance, to add or replace a domain, change information about an organization) an already open two-year certificate, the validity period of a new one was reduced to 397 days, and many users did not find out about it in a timely manner.

    Wildcard certificates are not suitable in all situations.

Services, as a rule, do not start at the same time (for instance, in January you launched one, and in February - the second), and some of them require the name of a specific host to be explicitly specified in the extension where DNS names are registered in order to work properly. Therefore, in some cases, certificates are required that have host names listed in the "DNS-name" extension.

What do we end up with. The administrator has a bunch of certificates that need to be managed:

    Track the validity of the certificate (check how many days are left before it expires).

    What names "closes" this or that certificate.

    Monitor if there are any problems with the certificate.

When renewing a certificate in the same certification authority, you can go through a simplified validation procedure. If you need to issue a certificate in another certification authority or change the parameters of the issued certificate, then the validation procedure will need to be completed in full, and this also takes time.

Small disclaimer. Today I'll show you how you can solve this problem with four PowerShell scripts. Of course, there are other ways to verify SSL certificates, in this article I just want to share the tools that are convenient for me and show how to use them.

I wrote these scripts based on a function that can be freely found on the Internet. In simplified terms, it works like this:

    We create a TCP connection with a remote host on a given port.
    Using these parameters, we create an SSL connection between us and the remote host.
    We establish connection.
    After the connection is established, we obtain data about the remote certificate.
    We parse the data.

Important: before using the scripts, do not forget to replace lorem ipsum with real data - substitute the necessary domain names and ports.

If desired, using these scripts, you can automate the verification of SSL certificates - for instance, leaving only the parameters you need and setting up sending emails with the results of their work.

We automate the check

You can run these scripts manually or set them up to run automatically and then send an e-mail, export to an Excel file with any other result.

To generate a report in Excel, you will need:

    Install the ImportExcel module:

import-module importexcel

    Add export to Excel, optionally specifying an array of parameters that are needed in the report:

$report | Where-Object {$_.DaysLeft -lt $triggerdays -or $_.CertChain -match "!!Blocked by this CA!!"} | Select-Object endpoint, issuer, daysleft, dnsnames |Export-Excel c:\report.xls -AutoSize -AutoFilter
The ImportExcel module has a lot of additional features - for instance, you can configure the "highlighting" of the lines you need (for instance, highlighting the lines in the DaysLeft column in red if the certificate being checked does not have long left) or other features.

And finally, a moment of positivity.

For instance, we have not yet been banned by CA Globalsign, there are also Intermediate CAs that can issue a certificate - you just need to look for them. So, not everything is so bad.


I don't remember something when issuing a certificate through LE when the field with the country is filled in.

There are companies with domains in international zones. On the contrary, there are transnational companies with a website in the .fr zone - how to unmistakably ban some without affecting others? So a global ban for some countries (not for tld) on the issuance of certificates seems to me unlikely.


Just those who are (or have been added there recently) in the list in question , may lose their certificates, almost at any time, even the beloved letsencrypt is also obliged to comply with this list. We are talking about the non-issuance of certificates, which indicate DE in the Country field. Here, for example, KB at Digicert .
Here, in addition to the Russian Federation, there are also Cuba, Iran, North Korea and Syria, as well as several TLDs

For the rest of the CA, there is no such list explicitly, it is simply written everywhere that "in accordance with the policy of the state", but nevertheless, many publishing centers (partners) have their own KB on the topic of blocking, for example GoGetSSL.