Built for Plesk agencies — 14-day free trial

A Plesk subdomain's "Use parent domain SSL" defaults unchecked. Plesk serves its self-signed default cert. Browsers reject it.
SSL It! reports "Enabled" in green. The subdomain's SSL panel shows "Not configured."

Plesk agencies running SSL It! (Plesk's free Let's Encrypt extension) deal with CAA records blocking Let's Encrypt issuance silently (the failure is logged to /var/log/plesk/sslit.log but the Plesk admin dashboard shows SSL It! as enabled in green), Plesk's bundled ModSecurity (OWASP CRS + Plesk vendor patches) blocking Let's Encrypt validator requests to /.well-known/acme- challenge/* paths under aggressive security profiles, and subdomain "Use parent domain SSL" inheritance toggles that default unchecked in some Plesk versions for new subdomains — causing SSL It! to attempt separate cert provisioning that fails when the subdomain DNS is still propagating. Merlonix monitors the served cert directly at every Plesk-hosted subdomain so silent SSL It! failures surface before clients see browser warnings.

No credit card for the trial. Cancel any time.

Check cadence (Agency)
5 min
SSL pre-expiry alert
30 days
Independent DNS resolvers
3
Vendors watched
11

Where Plesk agencies get caught out

Three failure modes specific to Plesk Obsidian deployments with SSL It! (Let's Encrypt extension): CAA records blocking Let's Encrypt issuance silently, Plesk Application Firewall (ModSecurity + OWASP CRS) blocking Let's Encrypt validators, and subdomain "Use parent domain SSL" inheritance defaulting unchecked.

Plesk agencies deal with CAA records added for security hardening that block Let's Encrypt issuance (SSL It! logs the failure to /var/log/plesk/sslit.log but the Plesk admin dashboard still shows SSL It! as enabled in green — per-domain failures are aggregated as counts in a sub-panel nobody opens), Plesk's bundled Application Firewall (ModSecurity + OWASP CRS with Plesk vendor patches) blocking Let's Encrypt validator requests under "thorough" security profile presets (every renewal retry hits the same WAF rule and gets a 403), and subdomain "Use parent domain SSL" inheritance toggles that default unchecked in Plesk Obsidian with standard service plan templates (SSL It! attempts separate cert provisioning that fails when the subdomain DNS is still propagating).

CAA (Certification Authority Authorization) records pin which CAs are permitted to issue certs for a domain. Agencies adding CAA records during security hardening typically pin to a specific commercial CA (Sectigo, GlobalSign, DigiCert) and forget to add letsencrypt.org. SSL It!'s Let's Encrypt integration queries the CAA record before each renewal request; when Let's Encrypt is not on the permitted list, the renewal is rejected. SSL It! logs the failure to /var/log/plesk/sslit.log on Linux Plesk or %plesk_dir%\admin\logs\sslit.log on Windows Plesk — neither location is on the Plesk admin's daily dashboard. The SSL It! panel in the Plesk UI still shows "Enabled" in green at the per-subscription level

A Plesk agency completes a security audit that recommends CAA records on high-value client domains. The agency engineer adds `0 issue "sectigo.com"` for the apex of each domain (Sectigo is the agency's primary CA for EV/OV certs that several clients have). The engineer doesn't add `0 issue "letsencrypt.org"` because the assumption is that SSL It! is using Sectigo. SSL It!'s Let's Encrypt integration queries the CAA record at the next renewal cycle, finds Let's Encrypt is not permitted, logs the failure to /var/log/plesk/sslit.log, and skips the domain. The Plesk admin dashboard shows "SSL It!: Enabled" with the green check; the existing cert continues serving for 30-90 more days before expiry triggers the next outage

A Plesk agency operates a portfolio of 30+ client websites across multiple shared-hosting Plesk subscriptions (some on Hetzner Plesk, some on IONOS Plesk, some on the agency's own self-managed Plesk VPS). The security lead completes an annual audit and recommends CAA records on high-value client domains to pin cert issuance to the agency's preferred CAs. The recommended CAA records: `0 issue "sectigo.com"` for the agency's Sectigo-based EV certs, plus `0 issue "globalsign.com"` for a few clients on GlobalSign certs. The security lead implements the CAA records across 30+ domains. The lead doesn't add `0 issue "letsencrypt.org"` to any of them because the assumption is that the EV/OV certs being pinned by CAA are also the certs SSL It! uses — a common misunderstanding because SSL It!'s panel in Plesk shows a generic "Plesk Free SSL" label without surfacing that the underlying CA is Let's Encrypt. SSL It!'s next renewal cycle (Plesk runs the SSL It! cron daily at 03:30 server time) queries the CAA record for each domain, finds Let's Encrypt is not permitted, logs "Skipping renewal for example.com: CAA policy disallows issuance by Let's Encrypt (R3)" to /var/log/plesk/sslit.log, and moves on. The log entry is one of thousands per day on a busy Plesk server (the log records every domain decision, not just failures); nobody scrolls through it during routine maintenance. The Plesk admin dashboard shows "SSL It!: Enabled" with the green check at the per-subscription level — the resource state is enabled, the per-domain decisions are aggregated as counts in a sub-panel under Tools & Settings → SSL It! that nobody opens. The existing cert continues serving for 60 more days. Then the cert expires. Browsers throw warnings. The agency engineer runs the standard Plesk SSL diagnostic in the panel; the diagnostic reports "Cert expired"; runs SSL It! manually from the panel; the manual run fails with "CAA policy disallows issuance"; the engineer realizes the CAA record is blocking it; adds `0 issue "letsencrypt.org"` to the DNS record; SSL It! succeeds on the next cycle. Total downtime: 6 hours of broken HTTPS.

Plesk ships ModSecurity as the bundled Application Firewall layer (Plesk Obsidian and later — replacing the older Tortoise Web Application Firewall). Plesk includes the OWASP Core Rule Set with Plesk-specific vendor patches as the default ruleset; admins can pick a "fast", "tradeoff", or "thorough" security profile preset. The "thorough" preset (often selected when an agency wants maximum protection) enables a broad set of OWASP CRS rules that pattern-match on automated request patterns. Let's Encrypt's validator hits the WAF; the validator's user agent and request pattern can trigger one of the CRS rules; the WAF returns 403 instead of the challenge token. SSL It! retries every 24 hours; every retry fails because the WAF rule is persistent

A Plesk agency enables Plesk&apos;s Application Firewall on a client&apos;s subscription and selects the "thorough" security profile as part of a production hardening project. The Plesk WAF enables a broad OWASP CRS ruleset. SSL It!&apos;s next renewal cycle attempts the HTTP-01 challenge; the Let&apos;s Encrypt validator requests /.well-known/acme-challenge/<token>; Plesk&apos;s WAF rule (one of the OWASP CRS rules for "request patterns suspicious of vulnerability scanning") matches the validator&apos;s request, returns a 403. SSL It! receives a 403 instead of the challenge token; logs "ACME challenge for example.com failed with HTTP 403" to /var/log/plesk/sslit.log; retries every 24 hours. The Plesk panel shows the SSL It! status as "Issuance Failed" only if the operator opens the per-domain SSL It! page directly — the main dashboard still shows the subscription as healthy

A Plesk agency operates a Plesk Obsidian VPS for a high-value client. The agency&apos;s security lead enables Plesk&apos;s Application Firewall (ModSecurity-based) across all of the client&apos;s subscriptions and selects "thorough" as the security profile preset. "Thorough" enables a broad OWASP Core Rule Set with Plesk&apos;s vendor patches — rules covering SQL injection, XSS, command injection, request smuggling, and request patterns that look like vulnerability scanning. The WAF is tested against a normal browsing session; everything works. The agency moves on to other projects. 60 days later, SSL It!&apos;s renewal cycle for the client&apos;s primary domain runs. SSL It! requests Let&apos;s Encrypt to issue a new cert; Let&apos;s Encrypt initiates an HTTP-01 challenge against /.well-known/acme-challenge/<token> on the client&apos;s domain. The Let&apos;s Encrypt validator (from one of Let&apos;s Encrypt&apos;s documented validator IPs, with the user agent "Let&apos;s Encrypt validation server") sends the GET request. Plesk&apos;s WAF processes the request: the user agent is unusual (not a real browser), the request is one-off (no session establishment), the URL path is uncommon (/.well-known/acme-challenge/ is rare in normal traffic patterns). One of the OWASP CRS rules (let&apos;s say SecRule 920420 or similar — Plesk&apos;s vendor patches may renumber it) pattern-matches on "scanner request patterns" and triggers a 403 response. The Let&apos;s Encrypt validator receives the 403; reports the HTTP-01 challenge as failed. SSL It! receives the failure; logs "ACME challenge for example.com failed with HTTP 403 (likely server-side rejection)" to /var/log/plesk/sslit.log. SSL It! retries the renewal every 24 hours; every retry triggers the same WAF rule; every retry fails with 403. The existing cert continues serving for 30 more days. Then the cert expires. Browsers throw warnings. The agency engineer runs the SSL It! manual renewal from the Plesk panel; sees the same 403 in the console output; checks Plesk&apos;s WAF logs at Tools &amp; Settings → Web Application Firewall → Logs; sees a 403 entry on every renewal retry attempt with the OWASP CRS rule ID. The fix is to add an exclusion in the WAF for /.well-known/acme-challenge/* paths; SSL It! succeeds on the next cycle.

Plesk subdomains have an "Use parent domain SSL" checkbox in the SSL panel. The default state varies by Plesk version and the subscription&apos;s service plan template. In Plesk Obsidian with default templates, the checkbox is UNCHECKED for new subdomains. When unchecked, the subdomain doesn&apos;t inherit the parent domain&apos;s cert; SSL It! treats it as a separate domain requiring its own cert provisioning. If the subdomain&apos;s DNS isn&apos;t yet propagated (typical immediately after subdomain creation), the cert provisioning fails because Let&apos;s Encrypt can&apos;t resolve the subdomain. SSL It! marks the subdomain as "Issuance Failed" in the per-domain SSL It! panel; the main Plesk dashboard shows the subscription as healthy. The subdomain serves Plesk&apos;s default self-signed cert until the issue is manually resolved

A Plesk agency adds api.example.com as a subdomain in Plesk for a client&apos;s API service. The agency engineer uses Plesk&apos;s subdomain creation flow; the SSL panel for the new subdomain has "Use parent domain SSL" unchecked by default. The engineer doesn&apos;t notice or doesn&apos;t check the box. SSL It! attempts to provision a separate cert for api.example.com; the DNS for api.example.com is still propagating (the registrar TTL is 24 hours); Let&apos;s Encrypt&apos;s validator can&apos;t resolve api.example.com; the HTTP-01 challenge fails. SSL It! logs the failure and retries every 24 hours. The DNS eventually propagates but by then SSL It! has retried so many times that it&apos;s in a longer backoff window. The subdomain serves Plesk&apos;s default self-signed cert (the one bundled with the Plesk installation) until the agency engineer manually triggers a re-issuance

A Plesk agency adds api.example.com as a subdomain in Plesk for a client&apos;s API service. The Plesk subdomain creation flow has the SSL panel default to "Use parent domain SSL: unchecked" for new subdomains (this is the default behavior in Plesk Obsidian with the standard "Default" service plan template; in custom templates the default may differ). The agency engineer doesn&apos;t check the box because (a) the subdomain creation flow has many fields and the SSL panel checkbox is buried in a "Hosting Settings" sub-section, (b) the engineer assumes the parent domain&apos;s wildcard cert would automatically cover the subdomain, (c) Plesk&apos;s UI doesn&apos;t make it clear that the parent domain&apos;s cert is NOT used unless this checkbox is checked. SSL It! attempts to provision a separate cert for api.example.com via Let&apos;s Encrypt. The Let&apos;s Encrypt validator initiates the HTTP-01 challenge; queries DNS for api.example.com; DNS hasn&apos;t propagated yet (the registrar&apos;s default TTL is 24 hours for newly-created records); the validator gets NXDOMAIN; reports the HTTP-01 challenge as failed. SSL It! logs "ACME challenge for api.example.com failed: DNS not resolving" and retries every 24 hours. The DNS propagates 18 hours later. SSL It!&apos;s next retry succeeds at DNS resolution but Let&apos;s Encrypt&apos;s issuance is rate-limited per the duplicate certificate rate limit (5 duplicate certs per week per domain for new subdomains). SSL It! continues retrying every 24 hours; some succeed, some fail. The subdomain alternates between Plesk&apos;s default self-signed cert (when the latest SSL It! attempt failed) and the new Let&apos;s Encrypt cert (when the latest attempt succeeded). Browsers see varying behavior. The agency&apos;s monitoring (if it only checks the apex) shows everything green. Discovery happens when a customer reports inconsistent behavior; the agency engineer realizes the "Use parent domain SSL" checkbox was unchecked; checks it; saves; SSL It! is no longer attempting a separate cert for the subdomain; the subdomain serves the parent domain&apos;s cert correctly.

How it works

SSL and DNS monitoring for Plesk agencies across SSL It! CAA-block silent skips, ModSecurity Application Firewall blocking Let's Encrypt validators, and subdomain "Use parent domain SSL" inheritance defaults causing separate cert provisioning failures.

Merlonix monitors SSL expiry and DNS integrity across every Plesk-hosted subdomain — app.* and api.* (SSL It!-managed), plus addon domains and aliases on the same subscription — and catches SSL It! CAA-block failures (the existing cert serves until expiry while the Plesk dashboard shows SSL It! enabled in green), ModSecurity WAF drops of Let's Encrypt validators (every renewal retry hits the same WAF rule and gets a 403), and subdomain "Use parent domain SSL" inheritance gaps (Plesk serves its default self-signed cert when SSL It! fails separate cert provisioning) — before clients see browser warnings.

01

Add Plesk-hosted domains — apex, www.*, app.*, api.* — with DNS TXT verification that catches SSL It! CAA-block failures, ModSecurity blocking Let&apos;s Encrypt validators, and subdomain "Use parent domain SSL" inheritance gaps

Verify ownership with a DNS TXT record on the apex domain. All subdomains under that apex — app.* (SSL It!-managed), api.* (SSL It!-managed), plus any addon domains or aliases on the same Plesk subscription — are added without additional verification. Monitoring every Plesk-hosted subdomain catches the SSL It! CAA-block failures (the served cert is the old cert approaching expiry while SSL It!&apos;s log records the per-domain skip), the ModSecurity WAF drops of Let&apos;s Encrypt validators (every renewal retry gets a 403 and the WAF rule is persistent), and the subdomain inheritance gaps (Plesk serves its default self-signed cert when SSL It! fails to provision a separate cert and parent-domain SSL inheritance is unchecked). Under two minutes per client.

02

CAA record monitoring across Plesk client domains — surfacing the CAA misconfiguration that blocks SSL It! renewal silently

Three independent DNS resolvers check every CAA record on every monitoring interval. When a client&apos;s domain has a CAA record that excludes letsencrypt.org (typical after security hardening that pins to commercial CAs like Sectigo or GlobalSign), the configuration is surfaced immediately as a renewal-risk alert — well before SSL It!&apos;s next renewal cycle silently skips that domain. The alert specifies which authorities are permitted in the CAA record and notes that SSL It! defaults to Let&apos;s Encrypt, so the cert won&apos;t auto-renew under the current configuration.

03

SSL monitoring 30 days before expiry across every Plesk-attached subdomain — including independent checks per-subdomain so ModSecurity WAF drops and subdomain inheritance gaps surface at the served-cert layer, not at the SSL It! metadata layer

Full SSL chain validation on every Plesk-hosted subdomain — apex, app.*, api.* — across whichever virtual host configuration Apache (or NGINX, depending on Plesk version) is actually using. Each subdomain gets the same 30-day pre-expiry alert. When SSL It! is silently failing renewal cycles (CAA-block, WAF-drop, or subdomain inheritance gap), the existing cert continues serving until expiry — Merlonix surfaces the renewal-failure state 30 days before expiry rather than waiting for the expiry event when the customer reports a browser warning.

04

Vendor status for major European Plesk hosting providers (Hetzner, IONOS, OVH, Strato), Let&apos;s Encrypt, plus DNS providers used at the registrar to distinguish hosting-provider incidents from per-tenant SSL It! configuration failures

Merlonix monitors major Plesk hosting providers&apos; status pages alongside client SSL and DNS. When a hosting provider&apos;s incident affects SSL It! operation across multiple client tenants simultaneously, you see the vendor event — not a cluster of individual SSL alerts that each require separate investigation to determine whether the root cause is a hosting-provider incident, an SSL It! CAA-block from a recent security hardening project, a ModSecurity WAF rule blocking Let&apos;s Encrypt validators after a profile change, or a subdomain "Use parent domain SSL" gap from a recent subdomain creation.

What the numbers mean for Plesk agencies

Monitoring built for Plesk agencies where one client portfolio means SSL It! managing certs across 30+ subscriptions on Hetzner / IONOS / OVH / Strato, Plesk Application Firewall (ModSecurity + OWASP CRS with vendor patches) tuned per-subscription, and subdomain "Use parent domain SSL" inheritance toggles that default differently across Plesk versions — each with independent silent-failure modes.

Plesk agencies managing SSL It!-driven portfolios across Hetzner, IONOS, OVH, Strato Plesk plans, with the Application Firewall tuned for application-specific protection, CAA records pinned to specific CAs for compliance, and subdomains where "Use parent domain SSL" inheritance defaults vary by Plesk version, need monitoring that watches the served cert directly at every Plesk-hosted subdomain — because SSL It! CAA-block failures are silent (logged to sslit.log but not the Plesk admin dashboard), ModSecurity WAF drops of Let's Encrypt validators are silent (every retry gets a 403 the same way), and subdomain inheritance gaps are silent (the parent serves correctly; the subdomain serves Plesk's default self-signed cert).

< 10 min

Time from DNS change to alert — catches CAA record additions that exclude letsencrypt.org (blocking SSL It! renewal silently), registrar nameserver changes that strip SSL It! validation, and Plesk subdomain creation with the "Use parent domain SSL" checkbox left unchecked

30 days

SSL expiry warning lead time — enough time to identify an SSL It! CAA-block (the CAA record needs letsencrypt.org added or SSL It! needs to be reconfigured to use the permitted CA), a Plesk ModSecurity WAF rule blocking the Let&apos;s Encrypt validator (the WAF needs an exclusion for /.well-known/acme-challenge/* paths), or a subdomain "Use parent domain SSL" gap (the checkbox needs to be checked in the subdomain&apos;s SSL panel) — and correct it before clients see browser warnings

11 vendors

Upstream services monitored — major European Plesk hosting providers (Hetzner, IONOS, OVH, Strato), Let&apos;s Encrypt status, plus DNS providers used at the registrar included to distinguish hosting-provider incidents from per-tenant SSL It! configuration failures

200 assets

Maximum monitored domains on the Agency plan — covers app.* and api.* across Plesk subscriptions, addon domains, aliases, and subdomains, across a full Plesk client portfolio

Pricing

Flat monthly fee. Every Plesk subscription, every subdomain, every Application Firewall configuration included.

No per-subscription charges. No per-domain fees. Pick the tier that fits your Plesk portfolio and per-subdomain check count and monitor every SSL It!-managed cert without billing surprises.

See full feature comparison →

Starter

For individual Plesk developers managing a small client portfolio on a single Plesk subscription.

$29/ month

  • 10 monitored assets
  • 1 seat
  • 15-min check cadence
  • SSL + DNS + vendor monitoring
  • Email + Slack alerts
Most chosen

Team

For Plesk agencies managing SSL It! across multiple subscriptions with addon domains, aliases, and Application Firewall tuning where ModSecurity blocks on Let&apos;s Encrypt validators are a real risk.

$79/ month

  • 50 monitored assets
  • 5 seats
  • 10-min check cadence
  • SSL + DNS + vendor monitoring
  • Email + Slack alerts

Agency

For agencies with a full Plesk client roster including CAA records pinned to specific CAs for compliance, Application Firewall rules tuned per-subscription, and subdomains across Hetzner / IONOS / OVH / Strato Plesk plans with varying inheritance defaults.

$199/ month

  • 200 monitored assets
  • 15 seats
  • 5-min check cadence
  • SSL + DNS + vendor monitoring
  • Email + Slack alerts

Know when SSL It! has been silently skipping renewal because of a CAA record — 30 days before the existing cert expires.

Add your first Plesk client domain in under two minutes. SSL It!-managed certs across subscriptions, addon domains, and subdomains are monitored from the same dashboard. 14-day trial, no card required.