BLOG
Make’s October 2026 app update says its WordPress connections now strictly validate SSL certificates. A scenario that previously connected to a WordPress site with an invalid or expired certificate may now fail instead of silently accepting the problem. For a small business, the priority is to identify the affected connection, repair the certificate, and verify whether any actions were missed before retrying a post or order.
What changed in the connection?
Make says it now checks certificates strictly for WordPress connections. It also documents a route for uploading a custom certificate when an internal or development site uses a self-signed one. This is a security-related connection change, not evidence that Make modified a site’s content. Check the current WordPress app documentation for the exact connection fields and behavior.
A valid HTTPS URL in a browser is a useful first check, but it may not prove the entire certificate chain is acceptable to an API client. Inspect the domain name on the certificate, expiration, issuer chain, and the URL configured in Make. Redirects to another hostname can also matter. Use the actual failure message before changing a scenario.
Who should review scenarios?
List every Make scenario that uses the WordPress app, the site URL, the connection owner, and the last successful execution. Prioritize workflows that create posts, receive orders, or update customer-facing pages. A scenario can appear enabled while an individual execution has failed; inspect its history and destination records.
If an execution failed after an API call, do not immediately replay it. First check whether the WordPress object exists. A retry that creates a second draft or order is a process defect even when the certificate issue is repaired. Use an external request ID or a lookup step to make the operation safe to retry.
| Signal | Next check |
|---|---|
| Expired certificate | Renew it at the host and verify the full chain |
| Wrong hostname | Match the Make URL to the certificate and site |
| Self-signed staging site | Use Make’s documented custom-certificate route |
| Unclear retry state | Read WordPress before replaying a write |
Check the site’s certificate at the host
For a public site, repair the certificate through the hosting control panel or certificate provider. Confirm that the site serves the correct certificate on the domain Make calls and that any intermediate certificates are present. WordPress HTTPS guidance explains why secure transport matters for site administration. A certificate renewal should be followed by a fresh Make connection test, not just a successful browser visit.
Do not disable validation to make production traffic pass. A broken certificate may indicate an expired renewal, wrong server, or interception risk. Fix the root cause. If the site is behind a proxy or CDN, trace which certificate Make sees from the public endpoint and whether the origin configuration is separate.
What about a self-signed development site?
Make’s update says a custom certificate can be uploaded for this case. Follow the current connection instructions and limit it to the intended development environment. A self-signed certificate can be useful for testing, but it is not a reason to treat an invalid public production certificate as acceptable. Let’s Encrypt’s localhost guidance explains why local development has different certificate constraints.
Example: a draft post scenario
A Make scenario receives an approved article and creates a WordPress draft. After the certificate change, the connection reports a failure. The operator checks the site’s certificate and corrects it. Before rerunning the failed bundle, they search WordPress for the article’s unique editorial ID and slug. If a draft already exists, they update or inspect it; they do not create another. If none exists, they replay once and read the saved draft back.
That verification matters because an error shown to the automation platform does not always prove that the destination write never happened. Logs, WordPress status, and the returned object ID should agree. Keep publication as a separate, explicitly approved action.
What should be done now?
Separate a certificate fault from other connection errors
An SSL failure may be confused with a wrong WordPress application password, blocked REST endpoint, or host firewall. Check the exact error category and timing. A certificate validation error often occurs before an authenticated WordPress response; a 401 or 403 response usually tells a different story. Test a public, harmless endpoint over HTTPS and inspect the certificate chain using trusted tooling. Then test the Make connection with its normal account. Do not rotate credentials or reinstall plugins merely because the scenario shows a generic failure banner.
After repair, verify both directions that the scenario uses. A read may succeed while a write still fails because of WordPress permissions. For a draft creation flow, save one test record with a unique editorial ID, read it back through the API, and confirm the status is draft. Remove or archive the test through the approved workflow. Record the successful certificate and connection test date. This makes the next incident easier to distinguish from the October change.
Prevent an outage at the next renewal
Identify who owns the domain, certificate renewal, and Make connection. If the host renews certificates automatically, set an alert for failures and check that the public domain still serves the renewed chain. If a CDN or proxy sits in front of WordPress, verify both the edge and origin paths that matter to your setup. Keep a simple runbook listing the URL, connection owner, last successful scenario, and safe retry procedure. The objective is to catch an expiring certificate before customer requests or editorial drafts stop moving.
Audit WordPress connections, fix invalid public certificates, handle self-signed development endpoints through Make’s documented route, and inspect failed executions for missed or duplicate writes. Record the date of the certificate repair and test a harmless read before resuming writes. The October update is a useful trigger for a connection review, not a reason to turn off HTTPS checks.
