For a long time, discussions about the security of domains and web services have been reduced to a handful of buzzwords: SSL certificate, HSTS, HTTPS redirection, possibly preload analysis. In practice, however, anyone maintaining production environments knows that the real state of “trust” of a domain or service is much broader. It’s not just about the certificate itself, but also its correctness, hostname matching, completeness of the trust chain, DNS consistency, presence of CAA, and increasingly also basic hygiene of mail records such as SPF, DMARC, and DKIM.

It was precisely from this assumption that we developed hexssl-cli. The tool started as a practical CLI for diagnosing HSTS and HTTPS behavior. In version 0.2.0, however, it moves to the next level. It is no longer just a utility for checking the HSTS header. It is the first real step toward a broader set of checks covering trust, TLS, DNS, and mail security, which can be run manually, automated in scripts, or integrated into a simple operational pipeline.

Why did we expand hexssl-cli?

In the daily work of an administrator, DevOps engineer, technical support, or hosting provider, the problem almost never ends with the question: “does the certificate exist?”. Much more often, the questions are more specific and operational. Is the certificate still valid? Does the hostname match the SAN? Is the chain trusted? Do apex and www resolve consistently? Does the domain have CAA? Does mail have SPF and DMARC? Does DKIM even exist for a given selector?

These are exactly the kinds of everyday, practical questions we wanted to encapsulate in a lightweight CLI tool that provides a human-readable result while also being suitable for automation. That’s why in v0.2.0, hexssl-cli goes beyond HSTS and introduces three new areas: certificates, DNS, and mail trust.

What does version 0.2.0 bring?

The most important change is the extension of the tool with three new groups of checks. The first is cert check, a quick inspection of the certificate for a given host. The command returns information about the issuer, expiration date, number of days remaining, hostname matching, SAN fields, and a basic verdict on the trust chain. It’s a simple but highly useful check that immediately shows whether the issue is expiration, a self-signed certificate, hostname mismatch, or a chain validation error.

The second new area is dns check. The goal here was not to build a full DNS auditor, but a lightweight operational check. The command verifies A, AAAA, CNAME, and CAA records and provides a simple assessment of consistency between apex and www. In practice, such a check quickly identifies domains that technically “work” but lack basic hardening elements, such as missing CAA.

The third addition is mail check, the first step toward mail trust validation. The tool analyzes SPF, DMARC, and DKIM records for a given selector. This is particularly important in environments where the domain is not just a website address but also a carrier of email reputation, spoofing protection, and overall communication security maturity.

Usage examples.

The new commands are designed to be simple and readable from the very first run.

Certificate check:

hexssl-cli cert check example.com

DNS check:

hexssl-cli dns check example.com

Basic mail trust check for a selected DKIM selector:

hexssl-cli mail check example.com --selector default

Each of these commands can also return JSON output, which is essential if the result is to be consumed by a script, pipeline, or another tool:

hexssl-cli cert check example.com --json
hexssl-cli dns check example.com --json
hexssl-cli mail check example.com --selector default --json

This is important because one of the goals behind hexssl-cli was not to create yet another “nice-looking terminal checker,” but a tool suitable both for ad hoc use and simple automation scenarios.

What does this mean in practice?

The value of such commands does not come from the number of fields they can read. What matters is that they provide a fast, operational verdict. For example, a domain may load correctly in a browser but still lack CAA, have a weak DMARC policy, or be missing DKIM for the selector in use. From an end-user perspective, “everything works.” From a security and operations perspective, however, this represents concrete gaps in configuration maturity.

hexssl-cli is meant to shorten the path from “something is wrong” to “I know exactly what to check and fix.”

This approach is particularly useful in several scenarios. First, in operational work for administrators or support teams needing to quickly verify the state of a domain. Second, during onboarding or migration, when checking certificate, DNS, and mail trust consistency. Third, in hosting or partner environments where similar checks are repeated across many domains. Fourth, in simple CI/CD or periodic scripts, where JSON output and meaningful exit codes are far more valuable than colored terminal output.

This is not yet a full suite and that’s a good thing.

Version 0.2.0 does not attempt to be everything at once. It is not yet a full platform for fleet scanning, certificate lifecycle management, or large-scale mail record analysis—and that is intentional. It is far better to evolve such a tool incrementally, building a small, stable core and useful modules, rather than creating a heavy all-in-one system that no one wants to maintain. As of now, hexssl-cli has a solid foundation: existing HSTS commands, a certificate module, a DNS module, a mail trust module, and a shared mechanism for results, formatters, and exit codes. This means future development can build on a coherent structure rather than a set of ad hoc commands.

What’s next?

The natural next step is the development of an aggregation layer—a report that allows running multiple checks at once and receiving a single consolidated result for a domain. This is particularly valuable for partners, hosting providers, MSPs, and anyone who wants a unified view of certificates, DNS, HSTS, and mail trust. Another key area is improving the developer experience: release workflows, changelog automation, documentation refinement, and additional testing. In practice, the maturity of such a CLI depends not only on the number of commands, but also on predictability, output stability, and ease of integration.

Version 0.2.0 marks the moment when hexssl-cli stops being just an HSTS tool and starts becoming a lightweight trust toolkit for administrators, DevOps, and technical teams. The new commands cert check, dns check, and mail check do not solve every problem, but they address the area that most often matters in practice: fast, technical, and actionable diagnostics of a domain’s trust posture.

For us, this is also an important directional signal. We aim to develop not only products and educational content, but also our own tools with real operational value. hexssl-cli 0.2.0 is exactly such a step.