January 2026
If you manage infrastructure for multiple clients, you know the drill. A client calls on Monday morning: their website is showing a security warning. You check, and their SSL certificate expired over the weekend. Now you're scrambling to renew it, explaining to the client why their site was down, and hoping their customers didn't notice.
This scenario plays out across MSPs every week. SSL certificates expire. It's inevitable. But letting them expire without warning is entirely preventable.
The problem isn't that certificates expire. The problem is knowing when they will, across dozens or hundreds of client domains, without spending hours each week manually checking them.
Most MSPs handle SSL monitoring in one of three ways:
Option 1: Manual checking
A spreadsheet tracks domains. Maybe it's updated. Maybe it's not. Every month, someone on the team opens it and checks each domain manually. This works until there are 20 clients with 5 domains each. Then it doesn't work at all.
Option 2: Individual monitoring tools
Monitoring is set up for each client domain in UptimeRobot or Pingdom. This gets expensive fast. Per-monitor pricing adds up, and these tools aren't designed for MSPs managing multiple clients. The result is dozens of monitors spread across multiple accounts.
Option 3: Enterprise monitoring platforms
Datadog, New Relic, or similar. These work, but the cost is for an entire infrastructure monitoring platform when all that's needed is SSL certificate checks. It's like buying a truck to carry groceries.
None of these options scale well for MSPs.
Let's be specific about what works for MSP workflows:
The requirements are straightforward: check SSL certificates for 100+ domains daily, get clear status for each domain without parsing certificate details, integrate this information into existing systems rather than another dashboard to check, and keep costs under €50/month total, not per client.
The key insight is this: SSL monitoring for MSPs isn't a UI problem. It's an automation problem.
The key shift is thinking about SSL monitoring as an automation problem rather than a UI problem.
Instead of checking certificates manually, query an API that checks them. Instead of viewing results in a web interface, receive them in automation scripts. Instead of setting up monitors for each domain, send a list of domains and get back their status.
This is what API-first SSL monitoring looks like in practice.
Here's a Python script that can be run daily via cron to check SSL certificates and generate a report:
import requests
from datetime import datetime
API_KEY = "your_api_key_here"
API_URL = "https://ssl.easydmn.com/bulk-check"
# Your client domain structure
clients = {
"Acme Corp": [
"acmecorp.com",
"www.acmecorp.com",
"api.acmecorp.com"
],
"Smith Industries": [
"smithindustries.com",
"shop.smithindustries.com"
],
"Johnson Services": [
"johnsonservices.com",
"portal.johnsonservices.com",
"billing.johnsonservices.com"
]
}
def check_client_certificates(client_name, domains):
response = requests.post(
API_URL,
headers={
"Content-Type": "application/json",
"X-API-Key": API_KEY
},
json={"domains": domains}
)
if response.status_code != 200:
return None
return response.json()
def main():
print(f"SSL Certificate Report - {datetime.now().strftime('%Y-%m-%d')}")
print("=" * 60)
critical_issues = []
warnings = []
for client_name, domains in clients.items():
results = check_client_certificates(client_name, domains)
if not results:
print(f"\n{client_name}: API check failed")
continue
client_critical = [r for r in results if r["status"] == "CRITICAL"]
client_warnings = [r for r in results if r["status"] == "WARNING"]
if client_critical:
critical_issues.extend([(client_name, r) for r in client_critical])
print(f"\n{client_name}: {len(client_critical)} CRITICAL issue(s)")
for issue in client_critical:
print(f" - {issue['domain']}: {issue['status']}")
if client_warnings:
warnings.extend([(client_name, r) for r in client_warnings])
print(f"\n{client_name}: {len(client_warnings)} warning(s)")
for warn in client_warnings:
days = warn['days_left']
print(f" - {warn['domain']}: expires in {days} days")
if not client_critical and not client_warnings:
print(f"\n{client_name}: All certificates OK")
# Summary
print("\n" + "=" * 60)
if critical_issues:
print(f"\nACTION REQUIRED: {len(critical_issues)} critical issue(s)")
if warnings:
print(f"\nUPCOMING: {len(warnings)} certificate(s) expiring soon")
if not critical_issues and not warnings:
print("\nAll client certificates are healthy")
if __name__ == "__main__":
main()
This type of script can run every morning and provide a clear report of what needs attention. The check typically takes 30-60 seconds for 150 domains.
The real value comes from integrating SSL checks into existing workflows. Automatically creating tickets when certificates need renewal eliminates manual tracking:
def create_ticket_for_expiring_cert(client_name, domain, days_left):
"""
Create ticket in your PSA system
This example is generic - adapt to your PSA's API
"""
ticket_data = {
"client": client_name,
"subject": f"SSL Certificate Renewal Required: {domain}",
"description": f"""
The SSL certificate for {domain} expires in {days_left} days.
Priority: {"HIGH" if days_left < 7 else "MEDIUM"}
Action required:
1. Contact client about renewal
2. Coordinate with certificate provider
3. Schedule renewal before expiration
Domain: {domain}
Days remaining: {days_left}
""".strip(),
"priority": "high" if days_left < 7 else "medium",
"category": "SSL Management"
}
# Send to your PSA
# response = requests.post(PSA_API_URL, json=ticket_data)
return ticket_data
# Add this to the main script
for client_name, result in warnings:
if result['days_left'] <= 14:
create_ticket_for_expiring_cert(
client_name,
result['domain'],
result['days_left']
)
Now expiring certificates automatically become tickets in your workflow. Your team doesn't need to remember to check. The system tells them what needs attention.
Let's talk numbers because this matters for MSPs.
Traditional monitoring tools charge per monitor:
For 100 domains, you're looking at $15-30/month minimum with traditional tools.
With an API approach:
The difference becomes more stark at scale. For 500 domains:
The savings increase with scale, along with better integration into existing workflows.
The valid concern here is: what if the monitoring service goes down? You're depending on an external API to tell you about problems with your clients' certificates.
This is worth thinking about carefully. Here's a reasonable approach:
First, check the API health endpoint before running the main check. If the API is down, get notified immediately and fall back to manual checks if needed.
Second, run checks daily, not hourly. SSL certificates don't expire suddenly. If the API is down for a few hours, you're not missing critical windows.
Third, keep track of the last successful check. If there hasn't been a successful response in 48 hours, that should trigger an alert to check the API status and manually verify critical domains.
The real question isn't "what if the API goes down" but "is this more reliable than the current process?" For most MSPs, the answer is yes. Manual checking fails silently. Someone forgets to check, and there's no indication of the failure until a certificate expires.
The recommended approach is to start small. Pick one client with multiple domains (5-10 is good). Set up the basic checking script. Run it manually for a week to understand the output and verify the results.
Then automate it. Add it to cron. Set up email notifications for critical issues. Run it daily for a month.
Once the process is proven with one client, expand to the rest. Update the clients dictionary, and all domains are monitored.
The whole setup takes maybe two hours. A free API key is available for testing (10 checks/month, enough for initial testing). Production plans start at €10/month for 5,000 checks.
To be fair, this API-first approach isn't the only way to handle SSL monitoring for MSPs. Different approaches make sense in different situations.
Comprehensive infrastructure monitoring platforms (Datadog, New Relic, etc.) already include SSL checking. If these tools are already in use and paid for, adding SSL checks costs nothing extra.
For very small portfolios (fewer than 20 domains total that rarely change), manual checking might still be reasonable. A calendar reminder and 30 minutes every two weeks can work.
If you need detailed SSL configuration analysis (cipher suites, protocol versions, certificate chains), you need more than basic expiration monitoring. SSL Labs' API provides this, though with rate limits that make it challenging for bulk checking.
The API approach works best when:
A few things to understand about how SSL certificate checking works:
The API checks certificates by connecting to each domain over HTTPS and examining the certificate presented. This means it can only check publicly accessible domains. Internal domains, development environments behind VPNs, or localhost won't work.
The check happens in real-time. When a request is sent, the API connects to each domain, retrieves the certificate, and calculates expiration. This takes a few seconds per domain. For 100 domains, expect 30-60 seconds total.
The API returns three statuses: OK (more than 14 days), WARNING (1-14 days), and CRITICAL (expired or connection failed). If a domain is unreachable, returns an invalid certificate, or has expired, you get CRITICAL. The system doesn't distinguish between "expired" and "down" because from a monitoring perspective, both require immediate attention.
Rate limits exist to prevent abuse. There's a per-IP limit (60 requests per minute) and a monthly quota based on your plan. For most MSP workflows, these limits aren't restrictive. Daily checks for hundreds of domains stay well within limits.
Email reports are fine for daily summaries, but you probably want immediate notifications for critical issues. Here's a simple addition to the script that sends Slack notifications:
import requests
SLACK_WEBHOOK_URL = "your_slack_webhook_url"
def send_slack_alert(client_name, domain, status, days_left):
message = {
"text": f"SSL Alert: {client_name}",
"blocks": [
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": f"*{status}* - {domain}"
}
},
{
"type": "section",
"fields": [
{
"type": "mrkdwn",
"text": f"*Client:*\n{client_name}"
},
{
"type": "mrkdwn",
"text": f"*Days Left:*\n{days_left if days_left else 'Expired/Unreachable'}"
}
]
}
]
}
requests.post(SLACK_WEBHOOK_URL, json=message)
# In your main script, add this after finding critical issues:
for client_name, result in critical_issues:
send_slack_alert(
client_name,
result['domain'],
result['status'],
result['days_left']
)
Now critical SSL issues show up in a team Slack channel immediately. Someone sees it, creates a ticket, reaches out to the client.
SSL certificate management for MSPs comes down to this: a system that scales with client base without scaling manual effort.
Traditional monitoring tools don't scale cost-effectively for MSPs. Manual checking doesn't scale at all. API-based monitoring solves both problems.
The approach is straightforward: check certificates via API, integrate results into existing workflows, automate ticket creation for issues that need attention. The technical implementation is simple. The operational benefit is significant.
For MSPs still checking certificates manually or paying per-domain monitoring fees, an API approach is worth considering. Start with a few domains to test the workflow.
The goal isn't to eliminate all manual work. It's to eliminate unnecessary manual work, so teams can focus on SSL issues that actually require human attention: client communication, certificate renewal coordination, troubleshooting complex problems.
Automated checking handles the routine. Teams handle the exceptions. That's how it should work.