Trust

Public certificate checks without private-key access.

Domain Trust Watch reads public TLS handshakes. It does not need private keys, server credentials, certificate procurement accounts, or access to internal infrastructure.

Workspace preview

Certificate health

Live checks

api.domaintrustwatch.com

Valid
84 days

checkout.example.com

Warning
13 days

idp.example.com

Issuer changed
2h ago
No private keysEmail verificationSigned webhooks
01

Public handshake only

The service checks public hostnames from outside your infrastructure and reports the certificate state presented during the TLS handshake.

  • Use it for hostnames reachable from the public internet.
  • Confirm what customers and API clients can receive from the hostname.
  • Run the free checker when you need a one-time public read.
Security boundary
AreaWhat Domain Trust Watch usesWhat it does not need
Certificate checksPublic TLS handshakes and certificate metadata.Private keys, SSH access, or server credentials.
Alert deliveryConfigured email, Slack incoming webhook, or signed webhook destinations.Access to inboxes, Slack workspaces, or internal systems beyond the destination URL.
Webhook signingGenerated signing secret for receiver verification.Unsigned trust in payload source.
Workspace accessOwner, admin, and member roles.Shared passwords or unmanaged access.
SupportHostname, workspace, event, delivery, or import context.Passwords, private keys, or certificate procurement credentials.
02

No private keys or server credentials

Domain Trust Watch stores certificate metadata and snapshots, not private keys, server passwords, SSH keys, or certificate procurement credentials.

  • Certificate data comes from public TLS handshakes.
  • The product does not issue, renew, install, or replace certificates.
  • Support messages should never include passwords, private keys, or server credentials.
03

Signed webhooks

Customer webhooks are signed so receivers can verify source and reject replayed payloads before creating tickets or updating internal systems.

  • Webhook receivers should verify timestamp plus body with HMAC-SHA256.
  • Receivers should reject stale timestamps before acting on events.
  • Delivery logs help teams debug receiver and channel failures.
04

Access controls

Workspaces use owner, admin, and member roles so administrative actions can be separated from daily certificate review.

  • Use owner/admin/member roles to separate setup from review.
  • Review team membership when certificate responsibility changes.
  • Keep monitoring access aligned with the people who handle renewal follow-up.