A security proxy creates two connections to check: the browser connects to the proxy, and the proxy connects to the hosting origin. A valid public certificate alone does not establish that the second connection is configured correctly.
01 Check the complete HTTPS route
- List the hostnames visitors use, including the main domain and any required
wwwaddress. Confirm which ones the security service is configured to handle. - Open each public HTTPS address and inspect the certificate name coverage, validity and chain. Record the exact browser error if one appears.
- In SiteLock's firewall settings, review SSL Configuration Status for the server and firewall. Confirm that the origin address still matches the current host.
- Have the authorised administrator test the origin certificate and HTTPS response using the intended hostname. Avoid treating an IP-address certificate warning as proof that hostname-based HTTPS is broken.
- If a certificate must be uploaded, use the protected dashboard and the required format. Keep any private key or PFX passphrase out of ordinary tickets.
- Test redirects, login and form submissions. Fix a redirect loop at the layer setting the incorrect scheme or redirect, then retest without cached redirects.
Common questions
Why did HTTPS fail after the hosting server moved?
The proxy may still use the previous origin, or the new origin may lack the right certificate and virtual-host configuration. Compare the migration record with the current firewall destination.
Should I remove HTTPS at the origin?
Do not use that as a routine repair. Identify the certificate or routing failure and use the supported secure configuration for both connections.
Will renewing one certificate renew both?
Only if the actual service explicitly manages both. Record the renewal owner and monitoring for every independently managed certificate.