Fix Urlwatch SSL Certificate Verification Errors

To fix urlwatch SSL certificate verification errors, keep verification enabled. Update the operating system’s trusted root certificates and the Python packages in the same environment that runs urlwatch. Then check whether the error affects one host or many, and investigate the affected server’s certificate chain, hostname, proxy, or private CA configuration. urlwatch has a per-job ssl_no_verify option, but disabling verification is a security-weakening bypass, not a general fix.

1. Capture the details and scope

Before changing configuration, record the complete error, the affected job URL, operating system, and urlwatch, Python, Requests, and certifi versions if known. Confirm which Python environment actually runs urlwatch: a system installation, virtual environment, container, scheduled task, or service may use different packages and trust settings than your interactive shell.

If several unrelated HTTPS hosts fail, first investigate a stale or altered local CA store, Python environment, or shared proxy.
If one host fails, investigate that host’s certificate chain, hostname, validity, and any host-specific proxy or private CA path.
These are diagnostic heuristics, not guarantees. A successful browser visit does not prove that urlwatch sees the same certificate chain or network path.

Requests verifies HTTPS certificates by default. Verification errors can indicate that the certificate cannot be trusted or that its hostname does not match the requested host. See the Requests SSL certificate verification documentation.

2. Update the trust sources in use

Update your operating system’s CA certificates using its documented package-management process. OS updates generally update trusted root certificates; the exact procedure varies by operating system and distribution. See GitHub’s guidance on certificate troubleshooting.
Upgrade urlwatch and the related Python packages in the same environment that executes the job. urlwatch documents python -m pip install --upgrade urlwatch for upgrading urlwatch itself. Use the interpreter and package manager belonging to the actual runtime environment.
Requests uses certifi’s certificate bundle and recommends keeping certifi updated. Upgrade it in that same environment if it is installed and used there. Package and platform behavior can differ by versions, so updating only a different Python installation may have no effect.

# Run these with the Python interpreter/environment used by urlwatch.
python -m pip install --upgrade urlwatch requests certifi

If your environment uses another package manager or locks dependencies, apply the equivalent update through that tool and preserve the project’s dependency-management process. Do not assume this command changes the operating system CA store.

3. Check the target certificate and hostname

If the failure persists for one URL, check that the certificate is valid for the exact hostname in the job URL and that the server supplies a chain clients can validate. Also check whether the URL redirects to another hostname with a separate certificate. Correct a server-side chain or hostname problem at the server or with its operator; changing urlwatch’s verification setting cannot repair it.

Consider whether a corporate proxy, TLS inspection device, VPN, or container network changes the certificate presented to Python. If the network uses a private CA, obtain the correct CA certificate through a trusted administrator or internal process. Do not download a CA certificate from an unverified source and add it to your trust store.

4. Configure a private CA when required

Requests supports an explicit CA bundle path through its verify parameter and the REQUESTS_CA_BUNDLE environment variable. For a Requests-based client, a bundle can be selected like this:

export REQUESTS_CA_BUNDLE=/path/to/approved-ca-bundle.pem

Use the path and configuration mechanism appropriate to the process that runs urlwatch. The environment variable is documented by Requests, but whether a particular urlwatch setup uses it depends on its client stack and versions. A CA bundle directory must be prepared using OpenSSL’s c_rehash utility. See the Requests documentation and Requests API reference.

Prefer adding the approved private CA to the correct trust configuration over disabling validation. Keep the trust change scoped to the environment that needs it, and follow your organization’s certificate-rotation process.

5. Understand urlwatch’s verification switch

urlwatch 2.29 documents ssl_no_verify as an optional per-job true/false setting. It disables SSL certificate verification for that job. Example syntax:

name: Example monitored page
url: https://example.com/
ssl_no_verify: true

Use this only as a tightly controlled temporary diagnostic choice when the security consequence is understood, then remove it and restore verification. Requests warns that disabling verification accepts any presented TLS certificate, including expired certificates and hostname mismatches, and can expose the connection to man-in-the-middle attacks. Do not use ssl_no_verify: true as the routine remedy or as a permanent workaround. See the urlwatch job reference and Requests security guidance.

6. Troubleshooting common failures

Symptom	Likely cause to investigate	Next step
Many unrelated sites fail verification	Outdated system roots, outdated certifi, a changed Python environment, or a shared proxy/private CA.	Update OS roots and Python packages in the runtime environment; check proxy and CA configuration.
Only one monitored host fails	That host may have an invalid or incomplete chain, hostname mismatch, expired certificate, or a host-specific network path.	Verify the exact URL hostname and investigate the server chain, redirects, and proxy path.
It works in a browser but fails in urlwatch	The browser and Python process may use different trust stores, certificate chains, proxy settings, or network routes.	Compare the runtime environment and network path. Update the CA sources used by the urlwatch process.
Updating packages changed nothing	The command may have updated a different interpreter/environment, or the issue may be OS-level or server-side.	Confirm the interpreter, environment, scheduled-task/service context, OS trust store, and affected host.
Private CA or enterprise proxy errors	The presented certificate chain may terminate at an organization-specific CA Python does not trust.	Obtain the approved CA from the administrator and configure the client’s supported CA bundle path.
Hostname mismatch remains after CA updates	Trusting a CA does not make a certificate valid for a different hostname.	Check the job URL, redirects, and server certificate names; have the server operator correct the certificate.
A directory is configured as the CA bundle and is ignored or fails	Requests requires a CA bundle directory to be processed with OpenSSL’s `c_rehash`.	Use a correctly prepared directory or a PEM bundle, following Requests’ documentation.

7. Reliability, performance, and cost considerations

Certificate verification is a security control, so restoring a valid trust chain is the reliable long-term repair. Updating root certificates and Python packages can address stale trust data, but neither can fix a server presenting the wrong hostname or an incomplete chain. A private CA configuration also needs maintenance when that CA rotates. Disabling verification may make a failing request proceed, but it removes checks that distinguish a trusted server from an invalid or intercepted connection.

This is generally a trust and configuration problem rather than a reason to repeatedly retry the same request. Retries will not repair a bad hostname or missing trust anchor. No measured performance or cost figures are established for this troubleshooting issue; avoid treating a bypass as a performance optimization.

8. Or skip the browser setup

If your next task is capturing a page rather than monitoring it with urlwatch, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. Its capture flow accepts cookie/consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server provides screenshot, page-info, and PDF tools for AI agents.

For a URL capture, the API key is supplied as access_key. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await (await import('node:fs/promises')).writeFile('shot.webp', bytes);

Free includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots. Sign up for 1,000 free screenshots a month, no card required.

FAQ

Does a certificate error mean urlwatch’s TLS verification is broken?

No. It means the client could not validate the certificate for that connection. The cause may be local trust configuration, a proxy or private CA, or the server’s chain or hostname.

Will upgrading urlwatch alone always fix it?

No. The operating system CA store, certifi bundle, active Python environment, network path, or target server may be the source of the problem.

Can I leave `ssl_no_verify` enabled for a public website?

That is unsafe as a routine setting because it removes certificate and hostname validation. Restore verification and fix the trust or server configuration.

Where should I get a private CA certificate?

From the trusted administrator or organization that operates the proxy or private PKI. Verify its provenance before configuring it as trusted.