Skip to main content
Version: 0.18

Verify the certificate in use

Record the starting public certificate, perform the operation, then make a fresh client connection. A successful job, a file on disk, a machine-store entry and a live TLS response are different evidence.

Check the actual endpoint​

On an independent Linux client, substitute the listener address and the hostname clients use:

openssl s_client -connect 192.0.2.10:443 \
  -servername www.example.com -verify_hostname www.example.com \
  -verify_return_error -CAfile /path/to/trusted-issuer-ca.pem \
  </dev/null > served.pem &&
openssl x509 -in served.pem -noout -serial -dates -fingerprint -sha256

Require a successful chain and hostname check before interpreting the certificate. SNI selects the intended listener; -verify_hostname checks its identity. The CA file must come from a trusted source, not from an unverified endpoint. For a public CA you can use the client's normal system trust configuration instead. Never use an insecure flag to manufacture a passing result.

Save a baseline before renewal, then run the command again into a different file afterward. Compare the returned serial/fingerprint and validity with the certificate installed by the job. A successful HTTPS response alone does not prove that the replacement is being served. For distribution, connect separately to each concrete consumer address; two requests through one load balancer are not proof for two hosts.

Inspect Windows and IIS​

Open Certificates (Local Computer) → Personal → Certificates. Check the replacement's validity and private-key association. Then open IIS Manager → site → Bindings → HTTPS → Edit → View. Compare the certificate selected by that binding with the replacement and the fresh TLS result. Inspect without making a second manual binding change.

Windows Thumbprint uses SHA-1; the OpenSSL example above uses SHA-256. Compare fingerprints produced with the same algorithm, or match the exact certificate serial and validity alongside the binding.

IIS renewal uses IIS rebinding, not a blanket iisreset. A certificate retained in Personal may be an older leaf; match the binding's exact thumbprint or serial rather than its subject name alone. SAN-only ACME certificates may have no subject CN.

Verify a CA trust-store installation​

On Ubuntu/Debian, check against the actual system bundle:

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt approved-root.pem

This is different from using the source root as its own -CAfile. Compare before installation, after it, and after owned removal. Applications with independent trust stores may behave differently.

On Windows, inspect Certificates (Local Computer) → Trusted Root Certification Authorities for a root or Intermediate Certification Authorities for an intermediate. Match the approved fingerprint, then inspect the chain result. These stores establish CA trust; Personal holds a server certificate and its private key. Retiring a workspace anchor does not remove those OS installations.