SSL Certificate Check API for DevOps Teams (2026)

Expired SSL certificates cause outages. Every DevOps team has a story: a certificate that nobody was tracking silently expired at 2 AM, triggering alerts, breaking customer-facing services, and sending the on-call engineer scrambling to renew it while the entire team watched the incident channel.

Certificate monitoring should not depend on someone remembering to check. It should be automated, API-driven, and integrated into the same toolchain where you manage everything else.

The DetectZeStack GET /certificate/check endpoint returns full certificate details as structured JSON — issuer, expiry, chain, TLS version, cipher suite, SAN domains, key algorithm, and more. You can integrate it into CI/CD pipelines, cron-based monitoring, Slack bots, or dashboards with a single HTTP request.

What the /certificate/check Endpoint Returns

The endpoint performs a live TLS handshake to the target domain on port 443 and returns everything about the certificate and connection. Here is what you get back:

This is not a simplified "valid or invalid" check. You get the raw data to build whatever monitoring logic your team needs.

Quick Start: Check a Certificate

Try it without authentication using the free demo endpoint:

curl -s "https://detectzestack.com/demo/certificate?url=github.com" | python3 -m json.tool

For production use, get a free API key from RapidAPI (no credit card required):

curl -s "https://detectzestack.p.rapidapi.com/certificate/check?url=github.com" \
  -H "x-rapidapi-key: YOUR_API_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" | python3 -m json.tool

Example response (truncated for readability):

{
  "domain": "github.com",
  "ip": "140.82.121.3",
  "port": 443,
  "has_tls": true,
  "tls": {
    "version": "TLS 1.3",
    "cipher_suite": "TLS_AES_128_GCM_SHA256",
    "negotiated_protocol": "h2"
  },
  "certificate": {
    "subject": {
      "common_name": "github.com",
      "organization": ["GitHub, Inc."]
    },
    "issuer": {
      "common_name": "DigiCert Global G2 TLS RSA SHA256 2020 CA1",
      "organization": ["DigiCert Inc"]
    },
    "not_before": "2024-03-07T00:00:00Z",
    "not_after": "2025-03-07T23:59:59Z",
    "days_remaining": 142,
    "is_expired": false,
    "signature_algorithm": "SHA256-RSA",
    "public_key": {
      "algorithm": "ECDSA",
      "bit_length": 256
    },
    "san_domains": ["github.com", "www.github.com"],
    "key_usage": ["Digital Signature"],
    "ext_key_usage": ["Server Authentication", "Client Authentication"]
  },
  "chain": [
    {
      "subject": "DigiCert Global G2 TLS RSA SHA256 2020 CA1",
      "issuer": "DigiCert Global Root G2",
      "is_ca": true,
      "not_after": "2031-04-13T23:59:59Z",
      "signature_algorithm": "SHA256-RSA"
    }
  ],
  "response_ms": 187
}

Use Case 1: Expiry Monitoring with Cron

Set up a daily check that alerts your team in Slack when any certificate is within 30 days of expiry:

#!/bin/bash
# cert-monitor.sh — run daily via cron
# 0 8 * * * /opt/scripts/cert-monitor.sh

DOMAINS=("app.example.com" "api.example.com" "dashboard.example.com")
API_KEY="your-rapidapi-key"
SLACK_WEBHOOK="https://hooks.slack.com/services/T.../B.../xxx"
THRESHOLD=30

for domain in "${DOMAINS[@]}"; do
  RESULT=$(curl -s "https://detectzestack.p.rapidapi.com/certificate/check?url=$domain" \
    -H "x-rapidapi-key: $API_KEY" \
    -H "x-rapidapi-host: detectzestack.p.rapidapi.com")

  DAYS=$(echo "$RESULT" | python3 -c "import sys,json; print(json.load(sys.stdin).get('certificate',{}).get('days_remaining', -1))")
  EXPIRED=$(echo "$RESULT" | python3 -c "import sys,json; print(json.load(sys.stdin).get('certificate',{}).get('is_expired', True))")

  if [[ "$EXPIRED" == "True" ]]; then
    curl -s -X POST "$SLACK_WEBHOOK" \
      -H "Content-Type: application/json" \
      -d "{\"text\":\"CRITICAL: SSL certificate for $domain has EXPIRED\"}"
  elif [[ "$DAYS" -lt "$THRESHOLD" ]]; then
    curl -s -X POST "$SLACK_WEBHOOK" \
      -H "Content-Type: application/json" \
      -d "{\"text\":\"WARNING: SSL certificate for $domain expires in $DAYS days\"}"
  fi
done

For 10 domains checked once per day, that is 300 requests per month — well within the Pro plan's 1,000 monthly limit.

Use Case 2: CI/CD TLS Verification

After deploying to staging or production, verify that TLS is properly configured and that the certificate matches what you expect:

#!/bin/bash
# ci-tls-check.sh — run after deploy in GitHub Actions / GitLab CI
DOMAIN="$1"
API_KEY="$RAPIDAPI_KEY"

RESULT=$(curl -s "https://detectzestack.p.rapidapi.com/certificate/check?url=$DOMAIN" \
  -H "x-rapidapi-key: $API_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com")

HAS_TLS=$(echo "$RESULT" | python3 -c "import sys,json; print(json.load(sys.stdin)['has_tls'])")
TLS_VER=$(echo "$RESULT" | python3 -c "import sys,json; print(json.load(sys.stdin).get('tls',{}).get('version','none'))")
DAYS=$(echo "$RESULT" | python3 -c "import sys,json; print(json.load(sys.stdin).get('certificate',{}).get('days_remaining', 0))")

echo "TLS enabled: $HAS_TLS"
echo "TLS version: $TLS_VER"
echo "Days remaining: $DAYS"

# Fail if TLS is not enabled
if [[ "$HAS_TLS" != "True" ]]; then
  echo "FAIL: TLS not configured on $DOMAIN"
  exit 1
fi

# Fail if TLS version is below 1.2
if [[ "$TLS_VER" == "TLS 1.0" || "$TLS_VER" == "TLS 1.1" ]]; then
  echo "FAIL: $DOMAIN is using deprecated $TLS_VER"
  exit 1
fi

# Warn if certificate expires within 14 days
if [[ "$DAYS" -lt 14 ]]; then
  echo "WARN: Certificate expires in $DAYS days"
fi

echo "PASS: TLS check passed"

Use Case 3: Multi-Domain Dashboard

For SRE teams managing dozens or hundreds of domains, build a Python script that produces a report:

import requests
import json

API_KEY = "your-rapidapi-key"
DOMAINS = [
    "app.example.com", "api.example.com", "cdn.example.com",
    "auth.example.com", "billing.example.com", "docs.example.com"
]

headers = {
    "x-rapidapi-key": API_KEY,
    "x-rapidapi-host": "detectzestack.p.rapidapi.com"
}

results = []
for domain in DOMAINS:
    r = requests.get(
        f"https://detectzestack.p.rapidapi.com/certificate/check?url={domain}",
        headers=headers
    )
    data = r.json()
    cert = data.get("certificate", {})
    tls = data.get("tls", {})

    results.append({
        "domain": domain,
        "has_tls": data.get("has_tls", False),
        "tls_version": tls.get("version", "N/A"),
        "issuer": cert.get("issuer", {}).get("organization", ["Unknown"])[0],
        "days_remaining": cert.get("days_remaining", -1),
        "is_expired": cert.get("is_expired", True),
        "algorithm": cert.get("public_key", {}).get("algorithm", "N/A"),
    })

# Sort by days remaining (most urgent first)
results.sort(key=lambda r: r["days_remaining"])

print(f"{'Domain':<30} {'TLS':>5} {'Days':>6} {'Issuer':<30} {'Algo':<8}")
print("-" * 85)
for r in results:
    status = "EXP!" if r["is_expired"] else r["tls_version"]
    print(f"{r['domain']:<30} {status:>5} {r['days_remaining']:>6} {r['issuer']:<30} {r['algorithm']:<8}")

Comparison: Certificate Check API vs Standalone SSL Monitoring

There are two categories of tools for certificate monitoring. Here is how they compare:

Standalone tools like SSLMate Cert Spotter, KeyChest, or Updown.io give you dashboards and built-in alerting out of the box. DetectZeStack gives you raw API data — you bring your own alerting (Slack webhooks, PagerDuty, email). The tradeoff: you get more flexibility, and you also get tech detection, DNS intelligence, and security header scanning with the same API key.

Pricing

The "Domains Monitored Daily" column assumes one check per domain per day. If you check twice daily, halve the number. All endpoints (/certificate/check, /analyze, /dns, /security, etc.) share the same monthly quota.

Why Not Just Use OpenSSL?

You can always run openssl s_client to inspect a certificate. Many DevOps teams do exactly that. But there are reasons to use an API instead:

• Structured data. openssl s_client outputs PEM-encoded text that you need to parse with openssl x509, awk, and grep. The API returns JSON with typed fields like days_remaining as an integer.
• No dependencies. OpenSSL needs to be installed and at the right version. The API is a single HTTP request from any language or CI runner.
• Network perspective. Checking from your own server only tells you what that server sees. Checking via an external API tells you what your users see — including CDN configurations, load balancer certs, and geo-specific certificate deployments.
• Batch workflows. Checking 100 domains with OpenSSL requires scripting the connection, parsing, timeout handling, and error recovery. With the API, it is a loop of HTTP requests.

OpenSSL is the right tool for debugging a single certificate on a single server. An API is the right tool for monitoring certificates across a fleet.

Combining Certificate Checks with Other Endpoints

Since all endpoints share the same API key, you can build comprehensive security monitoring by combining certificate checks with other DetectZeStack data:

• Certificate + Security Headers — check both TLS configuration and HTTP security headers. A site with a valid certificate but no HSTS header is still vulnerable to downgrade attacks. Use /certificate/check and /security together. See the Security Audit page for an interactive demo.
• Certificate + DNS Intelligence — combine certificate data with DNS records to detect CDN configurations, email providers, and infrastructure changes. The /dns endpoint reveals whether a domain uses Cloudflare, AWS, or another provider. See Certificate Scanner for details.
• Certificate + Tech Stack — know what software a domain runs in addition to its certificate status. Useful for vendor assessments where you need both security posture and technology inventory.