A deployment is complete when public responses match the release contract, not when the last upload exits zero. Two read-only helpers from the operator kit expose useful evidence, but they do not prove the whole artifact was published correctly.

Illustrative source excerpts show HTTP_STATUS 200 and FINAL_URL, then a full 2026 certificate expiry timestamp and a 30-day expiry-only result. Annotations distinguish shell success from HTTP status and expiry from notBefore, hostname and trust checks. Body comparison and SAN identity policy remain separate.
These are illustrative excerpts. Evaluate HTTP status and expiry separately; verify hostname, trust and body equality with the checks that actually test them.

Inspect the response headers

check-http-headers.sh performs a GET, discards the body, follows redirects, and prints the response headers for each hop plus the final status and URL:

check-http-headers.sh https://www.xbcatm.com/

This illustrative output shows the fields to inspect. It is not a fresh production observation:

HTTP/2 200
accept-ranges: bytes
content-security-policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:
content-type: text/html; charset=utf-8
last-modified: Mon, 24 Aug 2026 11:20:54 GMT
permissions-policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), microphone=(), payment=(), usb=()
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
x-frame-options: DENY

HTTP_STATUS 200
FINAL_URL https://www.xbcatm.com/

Check the expected status, final host and path, and the policy on the final response. The helper does not use curl’s --fail: an HTTP 404 or 500 can still leave the shell command successful. Treat its printed status as data to evaluate. A header mismatch warrants investigation of server, proxy, or cache configuration; it does not by itself prove the wrong output directory is live.

Inspect the certificate dates

check-tls-expiry.sh HOST [DAYS] extracts the certificate presented with SNI and checks whether its expiry is at least the requested number of seconds away:

check-tls-expiry.sh www.xbcatm.com 30

An illustrative excerpt, with the fingerprint line omitted:

subject=CN=www.xbcatm.com
issuer=C=US, O=Let's Encrypt, CN=YE1
notBefore=Aug 21 08:37:13 2026 GMT
notAfter=Nov 19 08:37:12 2026 GMT

certificate remains valid for at least 30 day(s)

The helper prints subject, issuer, dates, and SHA-256 fingerprint. It does not print the remaining day count. Its success message describes the expiry test only: the script does not enforce hostname or trust-chain validation, and -checkend does not validate notBefore. The subject CN is not sufficient hostname evidence; service identity is matched against the certificate’s subject alternative names. A valid wildcard may legitimately cover the host.

Use a separate verification when those properties matter:

openssl s_client -connect www.xbcatm.com:443 -servername www.xbcatm.com \
  -verify_hostname www.xbcatm.com -verify_return_error </dev/null

This uses the configured trust store and fails on certificate verification errors under OpenSSL’s matching rules. In OpenSSL 3.0, hostname verification can fall back to the subject CN when no suitable DNS subject alternative name is present. A successful command therefore does not by itself establish RFC 9525’s SAN-only identity policy: inspect the SAN extension and verify the intended client’s policy separately. Keep a job-level timeout around the TLS helper, which does not impose its own network deadline. Certificate inspection and automatic renewal configuration remain separate checks.

Use both around a release

  1. Before: save the expected policy, final URL, validators, and certificate dates with a UTC collection time.
  2. Deploy the already validated artifact.
  3. After: repeat the probes and fetch representative bodies for comparison with that artifact.

Headers and certificate dates cannot establish byte equality. Last-Modified may stay unchanged or be rewritten during copying. The release smoke test saves bodies and compares them directly; a complete manifest extends that check beyond one page. Browser behavior, geographic edge differences, and load-dependent failures need separate tests. Record which paths and observation points were actually checked.

Sources