A 403 Forbidden error after moving to HTTPS is usually caused by an incorrect redirect rule, a misconfigured SSL certificate blocking directory access, or a web application firewall treating the new HTTPS request as suspicious. It is one of the most common errors following an HTTP-to-HTTPS migration and can be fixed without touching file permissions. The SSL certificate itself is almost never the direct cause – the problem lies in how the server or CDN handles the transition.
Are You a Visitor or a Site Owner?
Your fastest path to a fix depends on which side of the 403 you are on.
| If You Are a Visitor | If You Are a Site Owner |
|
Skip to Section 2: Quick Fixes for Visitors
|
Skip to Section 3: Server & SSL Fixes
|
Quick Fixes for Visitors (5 Minutes)
If you are seeing a 403 on a site you do not control, the issue is likely browser-side or network-side. Work through these five fixes in order.
- Clear your browser cache and cookies. HTTPS and HTTP use separate cache keys. A stale HTTP 403 response stored in cache can persist after the site moves to HTTPS. Clear all site data, not just the cache.
- Try incognito or private mode. This bypasses cached credentials, session cookies, and browser extensions that can interfere with HTTPS connections.
- Check whether the site has a valid SSL certificate using a free SSL certificate checker – an expired or mismatched cert can trigger 403 on some server configurations.
- Try the HTTP version of the URL. If http:// loads but https:// returns 403, the redirect rule on the server is broken. This is a site-owner issue, but it confirms the cause.
- Disable your VPN or proxy. Corporate proxies and VPNs that perform SSL inspection can present substitute certificates that some servers reject with a 403.
403 Errors Caused by HTTPS Migration (Site Owners)
Most 403 errors that appear immediately after migration trace back to one of five server-side causes. Each one has a specific diagnostic step and a targeted fix.
Cause 1 – Bad HTTP to HTTPS Redirect Rule
A redirect rule that has an incorrect condition, a conflicting RewriteCond, or a missing [L] flag sends requests to an unresolvable path – and the server responds with 403 instead of 301.
The table below shows the correct redirect rule for each server platform. Compare your current rule against the correct version before making any changes.
| Server | Config File | Correct Redirect Rule | Verify Command |
| Apache | .htaccess | RewriteEngine On
RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] |
curl -I http://yourdomain.com |
| Nginx | nginx.conf | server { listen 80;
return 301 https://$host$request_uri; } |
nginx -t && systemctl reload nginx |
| IIS | web.config | <action type=”Redirect”
url=”https://{HTTP_HOST}/{R:1}” redirectType=”Permanent” /> |
curl -I http://yourdomain.com |
After updating the rule, test immediately with curl -I http://yourdomain.com and look for a 301 redirect in the response header. A 403 at this stage confirms the rule is still wrong. For full step-by-step syntax, the HTTP to HTTPS redirect guide covers every platform in detail.
Cause 2 – SSL Certificate Not Covering All Paths
A wildcard certificate covers *.domain.com but not domain.com itself unless both are listed as Subject Alternative Names (SANs). If a subdomain or path falls outside the certificate’s coverage, the server blocks the HTTPS request with a 403.
Run this command to inspect the SANs on your live certificate:
openssl s_client -connect domain.com:443 -servername domain.com.
Look for the Subject Alternative Names field in the output. Every hostname serving content over HTTPS must appear there.
If the SAN list is incomplete, reissue the certificate with the missing hostnames added and reinstall.
Cause 3 – Web Application Firewall Blocking HTTPS
A WAF terminates HTTPS connections, inspects the decrypted traffic, then re-encrypts before passing requests to the origin. During migration, the change in request patterns – new headers, changed referrers, fresh SSL handshake data – can trigger WAF rules. See the web application firewall overview for how WAFs handle SSL traffic by default.
Check the following WAF platforms if you see selective 403 errors after migration:
| WAF Platform | Where to Check | Common Fix |
| Cloudflare WAF | Security → Events → Firewall | Whitelist your IP or disable the triggered rule temporarily |
| ModSecurity | /var/log/apache2/modsec_audit.log | Add a SecRuleRemoveById exception for the flagged rule ID |
| AWS WAF | WAF Console → Sampled Requests | Create an IP set allow rule or adjust rule priority |
In each case, look for the specific rule ID that triggered, then either whitelist your domain, adjust the rule sensitivity, or add an exclusion for the path returning 403.
Cause 4 – HSTS Forcing HTTPS on Unconfigured Pages
HTTP Strict Transport Security (HSTS) tells browsers to use only HTTPS for a domain for the duration set in max-age. If you set HSTS before all pages are reachable over HTTPS, browsers refuse to fall back to HTTP – and pages that return 403 over HTTPS become permanently inaccessible in that browser until the HSTS policy expires or is cleared.
Check whether HSTS is the cause by running:
curl -I https://domain.com/page
Look for a Strict-Transport-Security header with a positive max-age value. If present, ensure every page on the domain resolves over HTTPS before setting or extending the HSTS max-age. Full guidance on correcting this is in the HSTS configuration fix guide.
Cause 5 – Mixed Content Falling Back to HTTP
Some servers switch to HTTPS-only mode after migration and actively block inbound HTTP requests with a 403. If your pages still contain hard-coded http:// resource references – images, scripts, stylesheets – browsers attempt to fetch them over HTTP, which the server now rejects.
Open your browser’s developer console (F12) and look for Mixed Content warnings on the Network tab. Every resource URL flagged as HTTP must be updated to https://. A global find-and-replace in your CMS database is the fastest way to catch them all.
How to Diagnose Your 403 Error After HTTPS
Use this table to match your symptom to the most likely cause. Start with the curl test column before changing any server configuration.
| Symptom | Likely Cause | Fix | Test Command |
| HTTP works, HTTPS gives 403 | Bad redirect rule | Fix .htaccess / nginx redirect | curl -I http://yourdomain.com |
| All pages 403 after migration | SSL cert not covering domain | Check cert SANs, reissue if missing | openssl s_client -connect domain.com:443 |
| Some pages 403, not all | WAF rule or directory permissions | Check WAF logs first, then permissions | grep 403 /var/log/apache2/access.log |
| 403 only in browser, not curl | HSTS browser policy | Clear HSTS in browser settings | chrome://net-internals/#hsts |
| 403 started after Cloudflare | Cloudflare WAF rule triggered | Check Security Events log in Cloudflare dashboard | Cloudflare → Security → Events |
Reading the table: if curl returns 200 but the browser returns 403, the cause is client-side – either HSTS policy or a browser-cached redirect. If both curl and the browser return 403, the problem is server-side and one of Causes 1–5 above applies.
Other Common 403 Causes (Not HTTPS-Related)
If you have ruled out all five HTTPS/SSL causes above and 403 errors persist, the following server-side conditions account for most remaining cases.
- File and directory permissions: Linux servers require directories to be set to chmod 755 and files to chmod 644. Permissions set below these thresholds return 403 for any request to that path.
- Missing index file: If a directory has no index.html or index.php and directory listing is disabled in server config, requesting that directory returns 403.
- IP address block in .htaccess or nginx.conf: A Deny from all or deny all directive without a matching allow rule will return 403 for every request from every IP.
- Hotlinking protection: RewriteRules that restrict image or media access to specific referrer domains return 403 to any request arriving from an external or direct URL.
- Incorrect ownership after server migration: If files were transferred with root ownership but Apache or Nginx runs as www-data or nginx, the server process cannot read the files and returns 403.
To check permissions on any path, run: ls -la /path/to/directory. The output shows the current owner and permission flags. Fix permissions with chmod -R 755 /var/www/html for directories and chmod -R 644 /var/www/html for files.
Next Steps After Fixing Your 403 Error
Once your 403 is resolved, run a full redirect test across your site’s most important pages using curl or an online redirect checker. Confirm every HTTP URL returns a clean 301 to its HTTPS equivalent, with no intermediate 302s or redirect loops.
If you are on Cloudflare, set SSL mode to Full (Strict) and enable Automatic HTTPS Rewrites. For origin servers, add an HSTS header only after every page on the domain is confirmed to return 200 over HTTPS – not before. As of 2026, Google mandates HTTPS for all indexed pages, and any 403 in your crawl data will suppress those URLs from search results. Check Google Search Console’s Coverage report weekly for the first month after migration to catch any residual 403s before they affect rankings.
Frequently Asked Questions (FAQs) About 403 Errors
Why am I getting 403 Forbidden after adding an SSL certificate?
The SSL certificate itself does not cause a 403. The redirect rule you configure during HTTP-to-HTTPS migration is the most common culprit. Check your .htaccess RewriteRule or nginx return directive first – a missing condition or incorrect flag sends requests to a path the server blocks.
Can an expired SSL certificate cause a 403 error?
No. An expired certificate produces ERR_CERT_DATE_INVALID or a browser security warning, not a 403. If you are seeing a 403 Forbidden specifically, the certificate is likely valid. The block is coming from the server configuration, not the certificate trust chain.
Why does my site return 403 with HTTPS but work with HTTP?
This is almost always a broken redirect rule. Your server has an SSL certificate installed and port 443 open, but the rewrite rule sends the HTTPS request to a directory or file path that returns 403. Compare your current redirect rule against the correct syntax for your server platform using the table in Section 3.
How do I fix 403 Forbidden on Cloudflare with SSL?
First, check Cloudflare Security Events for any WAF rules that triggered. Second, verify your SSL mode is set to Full (Strict) – not Flexible. Flexible mode sends HTTP requests to your origin server even when the visitor uses HTTPS, which can cause redirect loops that surface as 403. Set to Full (Strict) if your origin has a valid certificate installed.
Does 403 Forbidden mean my SSL certificate is broken?
Not directly. A 403 means the server received the request but refused to serve the resource. SSL certificate errors produce different codes: an expired cert shows ERR_CERT_DATE_INVALID, a mismatched cert shows SSL_ERROR_BAD_CERT_DOMAIN. If the browser reaches the 403 stage, the SSL handshake completed successfully – the block is in application or WAF logic.
How do I check if HSTS is causing my 403 in Chrome?
Navigate to chrome://net-internals/#hsts and search for your domain. If an entry exists with a positive max-age, Chrome is enforcing HTTPS for that domain. To test without this policy, click Delete for the domain entry, then reload the page. If the 403 disappears after deletion, HSTS was forcing an HTTPS request to an unconfigured path.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
