El error HTTPS 403 Forbidden indica que el servidor ha entendido la solicitud y que la conexión está correctamente cifrada con SSL/TLS, pero se niega a servir el recurso solicitado. El certificado SSL funciona correctamente: el problema no es de seguridad de la conexión sino de autorización sobre el recurso. Sin embargo, hay un grupo específico de causas del 403 que solo aparecen en sitios con HTTPS: la configuración del Cloudflare WAF, las reglas de Cloudflare SSL, los certificados de cliente (mTLS), las políticas HSTS mal aplicadas y los errores en la configuración del proxy inverso SSL. Esta guía cubre tanto las causas generales del 403 en contextos HTTPS como las causas exclusivas de entornos con SSL/TLS.

La confusión frecuente: errores SSL vs error HTTP 403

Cuando un usuario ve un error en un sitio HTTPS, la primera reacción es pensar que el problema está en el certificado SSL. En la mayoría de los casos no es así. Es importante distinguir entre dos categorías de problemas completamente distintos:

La forma más rápida de distinguirlos: si el navegador muestra la pantalla roja de advertencia de seguridad de Chrome ("Tu conexión no es privada") antes de ver ningún contenido, es un error SSL. Si el navegador muestra la página de error 403 (aunque sea genérica) después de haberse conectado, el SSL funciona y el problema es de autorización.

Causas del error 403 específicas de entornos HTTPS

Además de las causas generales del error 403 (permisos de archivos, .htaccess, IP bloqueada), los sitios con HTTPS y Cloudflare tienen causas adicionales exclusivas:

1. Cloudflare WAF bloqueando la solicitud (Error 1020)

El Cloudflare Web Application Firewall (WAF) puede bloquear solicitudes que considera sospechosas o maliciosas, devolviendo un error 403 con el código "Error 1020: Access Denied" y un Ray ID. Esto ocurre independientemente de si el sitio tiene SSL o no, pero es más frecuente en sitios con HTTPS porque Cloudflare actúa como terminador SSL y puede inspeccionar el tráfico HTTPS en detalle.

Las causas más frecuentes del Error 1020 de Cloudflare son:

• Tu IP está en la lista negra de Cloudflare (ya sea global o específica del sitio).
• El país de origen de la solicitud está bloqueado por una regla de Cloudflare del sitio.
• La solicitud coincide con una regla de firewall personalizada configurada en el panel de Cloudflare del sitio.
• El User-Agent del navegador o del bot está en la lista de bloqueo de Cloudflare.
• El modo "I'm Under Attack" de Cloudflare está activo y bloquea solicitudes sin JavaScript.

# El Ray ID en la página de error de Cloudflare te permite identificar la regla exacta:
# 1. Copia el Ray ID de la página de error (ej: 8a1b2c3d4e5f6789)
# 2. Ve al panel de Cloudflare > tu dominio > Security > Events
# 3. Filtra por el Ray ID para ver exactamente qué regla bloqueó la solicitud

# Desde la línea de comandos, ver las cabeceras de respuesta de Cloudflare:
curl -I https://tudominio.com
# Busca las cabeceras CF-Ray y CF-Cache-Status para confirmar que pasa por Cloudflare

Soluciones para el Error 1020 de Cloudflare:

• En el panel de Cloudflare, ve a Security > Events y encuentra la regla que bloqueó la solicitud.
• Si eres el administrador y tu propia IP está bloqueada, añádela a la lista blanca en Security > WAF > Tools > IP Access Rules.
• Si bloqueas países y necesitas permitir acceso desde uno bloqueado, añade una excepción en Security > WAF > Firewall Rules.
• Si el modo "Under Attack" está activo, desactívalo en Security > Settings > Security Level si el ataque ya terminó.

2. Cloudflare SSL en modo "Full (Strict)" con certificado de origen inválido (Error 526)

Cuando Cloudflare está en modo SSL "Full (Strict)", verifica que el certificado SSL del servidor de origen es válido: está firmado por una CA de confianza, no ha caducado y el dominio coincide. Si el certificado del origen tiene cualquier problema, Cloudflare devuelve un error 526 al usuario, que aparece como un error de acceso similar al 403.

# Verificar si el certificado SSL del servidor de origen está caducado:
echo | openssl s_client -connect IP-DEL-SERVIDOR:443 -servername tudominio.com 2>/dev/null | \
      openssl x509 -noout -dates

# Si el certificado de Let's Encrypt expiró en el servidor de origen:
sudo certbot certificates  # Ver estado de los certificados
sudo certbot renew          # Renovar manualmente si es necesario

# Verificar el estado de Let's Encrypt en Plesk:
# Websites y Dominios > [tu dominio] > SSL/TLS Certificates
# La fecha de caducidad debe ser mayor a hoy

3. Error 403 en el endpoint .well-known/acme-challenge (durante la renovación de Let's Encrypt)

Un caso especialmente frecuente y confuso: Let's Encrypt intenta renovar el certificado SSL accediendo a la URL http://tudominio.com/.well-known/acme-challenge/TOKEN, pero el servidor tiene configuradas reglas que bloquean ese directorio con un 403. El resultado es que la renovación automática falla silenciosamente y el certificado eventualmente caduca.

# Verificar si el directorio .well-known está accesible:
curl -I http://tudominio.com/.well-known/acme-challenge/test
# Debe devolver 404 (el archivo de prueba no existe) o 200 (si existe)
# NO debe devolver 403

# Causas comunes que bloquean .well-known con 403:
# 1. Reglas en .htaccess que bloquean directorios ocultos (que empiezan por punto):
#    
#        Require all denied
#    
#    SOLUCIÓN: añadir una excepción para .well-known

# 2. Reglas en Nginx que bloquean archivos ocultos:
#    location ~ /\. { deny all; }
#    SOLUCIÓN: añadir excepción antes de esa regla:
#    location ^~ /.well-known/acme-challenge/ { allow all; }

# Configuración correcta en Apache .htaccess:
# Para permitir .well-known pero bloquear otros archivos ocultos:
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

<DirectoryMatch "^/.well-known">
    Require all granted
</DirectoryMatch>

# Configuración correcta en Nginx:
# Añadir ANTES de la regla que bloquea archivos ocultos:
location ^~ /.well-known/acme-challenge/ {
    default_type "text/plain";
    root /var/www/html/tudominio;
    allow all;
}

4. Error 403 por restricciones de hotlinking o CORS en contexto HTTPS

Los sitios que implementan protección de hotlinking (evitar que otros sitios carguen sus imágenes o recursos directamente) a veces configuran esas restricciones de forma que bloquean las solicitudes legítimas que provienen de conexiones HTTPS a HTTP, especialmente durante el período de transición de un sitio de HTTP a HTTPS.

# Ejemplo de regla de hotlinking en .htaccess que puede generar 403 en contexto HTTPS:
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?tudominio\.com [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,L]

# Si acabas de migrar a HTTPS y el referer ahora empieza por https://
# pero la regla solo permitía http://, el resultado es un 403 en los recursos.

# Corrección: actualizar la regla para aceptar tanto http como https:
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?tudominio\.com [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,L]
# (La expresión https?:// ya cubre ambos protocolos con el ? que hace la s opcional)

Los errores CORS (Cross-Origin Resource Sharing) también pueden manifestarse como 403 en sitios HTTPS cuando las cabeceras CORS no están correctamente configuradas para el protocolo HTTPS:

# En Nginx — configurar CORS correctamente para HTTPS:
location /api/ {
    # Permitir solicitudes desde el dominio propio (con y sin www, en HTTPS):
    if ($http_origin ~* "^https://(www\.)?tudominio\.com$") {
        add_header 'Access-Control-Allow-Origin' "$http_origin" always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;
    }

    # Manejar las solicitudes preflight OPTIONS:
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' "$http_origin" always;
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;
        return 204;
    }
}

5. mTLS (Mutual TLS): certificado de cliente requerido

En configuraciones de seguridad avanzadas, el servidor puede requerir que el cliente (navegador o aplicación) presente también un certificado SSL válido para poder acceder al recurso. Esto se llama mTLS (Mutual TLS) o autenticación de cliente SSL. Si el cliente no presenta un certificado válido, el servidor devuelve un error 403 (o en algunos casos un error en la capa SSL antes de llegar al HTTP).

El mTLS se usa principalmente en:

• APIs privadas entre servicios (microservicios que se autentican mutuamente).
• Acceso a paneles de administración de alta seguridad.
• VPNs y acceso remoto corporativo basado en certificados.
• Cloudflare Access con autenticación por certificado de cliente.

# Configurar mTLS en Nginx (requerir certificado de cliente):
server {
    listen 443 ssl;
    server_name api.tudominio.com;

    ssl_certificate     /etc/letsencrypt/live/tudominio.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tudominio.com/privkey.pem;

    # Requerir certificado de cliente firmado por tu propia CA:
    ssl_client_certificate /etc/ssl/certs/mi-ca-corporativa.crt;
    ssl_verify_client on;  # Obligatorio
    # ssl_verify_client optional;  # Opcional (no devuelve 403 si no hay certificado)

    location / {
        # Si ssl_verify_client es 'on' y el cliente no presenta certificado válido,
        # Nginx devuelve directamente 400 Bad Request (o 403 según la configuración).
        proxy_pass http://backend;
    }
}

6. HSTS mal configurado que genera 403 en subdominios

Si activaste HSTS con la opción includeSubDomains pero alguno de tus subdominios no tiene certificado SSL o tiene un certificado inválido, los navegadores que ya recibieron la cabecera HSTS bloquearán el acceso a esos subdominios y pueden mostrar un error similar al 403 (aunque técnicamente es un error de política de seguridad del navegador, no un 403 del servidor).

# Verificar si HSTS está activo y qué subdominios cubre:
curl -I https://tudominio.com | grep -i "strict-transport"
# Ejemplo de salida:
# strict-transport-security: max-age=63072000; includeSubDomains; preload

# Si includeSubDomains está activo, verificar que TODOS los subdominios tienen SSL:
for subdominio in www mail webmail api blog; do
    echo -n "$subdominio.tudominio.com: "
    echo | openssl s_client -connect $subdominio.tudominio.com:443 -servername $subdominio.tudominio.com 2>/dev/null | \
          openssl x509 -noout -subject 2>/dev/null || echo "Sin certificado SSL"
done

Causas generales del error 403 que también afectan a sitios HTTPS

Además de las causas específicas de HTTPS, un sitio con SSL activo puede dar 403 por las mismas razones que cualquier sitio sin SSL:

Permisos de archivos incorrectos

Los permisos de archivos y directorios en el servidor Linux son independientes del protocolo usado (HTTP o HTTPS). Un archivo con permisos 600 que el usuario del servidor web no puede leer dará 403 tanto por HTTP como por HTTPS.

# Verificar permisos del directorio raíz del sitio:
ls -la /var/www/html/tudominio/

# Corregir permisos masivamente:
find /var/www/html/tudominio -type f -exec chmod 644 {} \;
find /var/www/html/tudominio -type d -exec chmod 755 {} \;
sudo chown -R www-data:www-data /var/www/html/tudominio/

# Usar namei para ver los permisos de cada nivel de la ruta:
namei -l /var/www/html/tudominio/index.php

Restricciones en el .htaccess después de la migración a HTTPS

Al migrar un sitio de HTTP a HTTPS, es frecuente olvidar actualizar las reglas del .htaccess que hacen referencia explícita al protocolo HTTP. Una regla que redirige todo HTTP a HTTPS puede entrar en conflicto con otras reglas y generar un 403:

# Regla problemática: solo permite acceso desde HTTPS pero la comprobación
# falla cuando hay un proxy inverso:
RewriteCond %{HTTPS} !on
RewriteRule ^ - [F]  # Devuelve 403 si HTTPS no está "on" según Apache

# Problema: con un proxy inverso (Nginx delante de Apache, Cloudflare),
# Apache recibe la solicitud en HTTP interno y %{HTTPS} es siempre "off",
# generando un 403 aunque el usuario acceda por HTTPS externamente.

# Solución: usar X-Forwarded-Proto en lugar de %{HTTPS}:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

IP bloqueada por Fail2Ban o ModSecurity después de instalar SSL

Instalar SSL y activar HTTPS puede cambiar los patrones de tráfico que Fail2Ban o ModSecurity detectan. Por ejemplo, si Certbot intentó validar el dominio varias veces con fallos (por problemas de configuración), esos intentos pueden haber activado reglas de Fail2Ban que bloquean la IP del propio servidor de Let's Encrypt, causando que las renovaciones futuras también fallen.

# Verificar si las IPs de Let's Encrypt están bloqueadas por Fail2Ban:
sudo fail2ban-client status nginx-http-auth
sudo fail2ban-client status apache-auth

# Las IPs de los servidores ACME de Let's Encrypt son dinámicas,
# pero puedes añadir el rango de IPs de Let's Encrypt a la lista de ignorados:
# En /etc/fail2ban/jail.local:
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 66.133.109.0/24

# Verificar si ModSecurity está bloqueando las solicitudes:
sudo grep "ModSecurity" /var/log/apache2/error.log | grep -i "403\|block" | tail -10

# Ver el log de ModSecurity:
sudo tail -50 /var/log/modsec_audit.log

Diagnóstico completo del error HTTPS 403

Paso 1: Confirma que el SSL funciona correctamente

# El primer paso es siempre confirmar que el problema es el 403 y no el SSL:
curl -I https://tudominio.com/url-con-403

# Si curl devuelve "403 Forbidden": el SSL está bien, el problema es de autorización.
# Si curl devuelve un error SSL (SSL_ERROR_RX_RECORD_TOO_LONG, certificate verify failed, etc.):
# el problema está en el certificado SSL, no en la autorización.

# Verificar el certificado SSL por separado:
echo | openssl s_client -connect tudominio.com:443 2>/dev/null | openssl x509 -noout -dates -subject

Paso 2: Identifica la capa que genera el 403

# Ver las cabeceras completas para identificar quién genera el 403:
curl -v https://tudominio.com/url-con-403 2>&1 | grep -E "^< |^> |HTTP"

# Si las cabeceras incluyen "CF-Ray", el 403 lo genera Cloudflare.
# Si las cabeceras incluyen "Server: nginx" o "Server: Apache", lo genera tu servidor.

# Para sitios con Cloudflare, hacer bypass del proxy para ver si el origen también da 403:
# Añade la IP del servidor en /etc/hosts:
# 195.234.56.78  tudominio.com
# Luego accede directamente:
curl -k -I https://tudominio.com/url-con-403
# (La opción -k ignora errores de certificado al conectar por IP directamente)

Paso 3: Revisa los logs del servidor

# Nginx — ver los 403 recientes con sus causas:
sudo grep " 403 " /var/log/nginx/access.log | tail -20
sudo tail -100 /var/log/nginx/error.log | grep -i "403\|forbidden\|deny\|permission"

# Apache — ver los 403 recientes:
sudo grep " 403 " /var/log/apache2/access.log | tail -20
sudo tail -100 /var/log/apache2/error.log | grep -i "403\|forbidden\|deny\|permission"

# El log de error suele indicar exactamente la causa:
# [error] ... "/var/www/html/index.php" is forbidden (13: Permission denied)
# → Causa: permisos incorrectos (error 13 de Linux = Permission denied)

# [error] ... client denied by server configuration
# → Causa: regla Deny o Require all denied en la configuración de Apache

# [error] ... No such file or directory
# → Causa: el archivo no existe (puede aparecer como 403 en algunas configuraciones)

Paso 4: Verifica la configuración del VirtualHost HTTPS

# En Apache — ver la configuración del VirtualHost HTTPS:
sudo apache2ctl -S
sudo cat /etc/apache2/sites-enabled/*.conf | grep -A 20 "VirtualHost.*443"

# Verificar que el DocumentRoot del VirtualHost HTTPS es correcto:
# A veces al instalar SSL con Certbot, se crea un VirtualHost 443 con un DocumentRoot
# diferente al del VirtualHost 80, causando 403 si el directorio correcto no está configurado.

# En Nginx — ver la configuración del bloque server HTTPS:
sudo nginx -T | grep -A 30 "listen 443"

Paso 5: Verifica las reglas del Cloudflare WAF (si usas Cloudflare)

1. Accede al panel de Cloudflare y selecciona tu dominio.
2. Ve a Security > Events.
3. Filtra por las últimas 24 horas y busca eventos de tipo "Block".
4. Identifica el Ray ID del error 403 que ves en el navegador y búscalo en los eventos.
5. El evento te mostrará exactamente qué regla lo bloqueó y por qué.
6. Si el bloqueo no es intencionado, modifica o desactiva esa regla en Security > WAF.

Errores SSL relacionados que se confunden con el 403

Aunque no son errores 403 técnicamente, estos errores SSL aparecen con frecuencia cuando los usuarios buscan información sobre el "error HTTPS 403" porque la experiencia de usuario es similar (no pueden acceder al sitio):

Cómo afecta el error HTTPS 403 al SEO

El impacto del error HTTPS 403 en el SEO es el mismo que el del error 403 en cualquier sitio, pero con una consideración adicional: en sitios con HTTPS, Googlebot accede principalmente a través de HTTPS (desde 2021, Googlebot prefiere HTTPS sobre HTTP cuando ambos están disponibles). Un error 403 que solo ocurre en HTTPS pero no en HTTP puede ser especialmente confuso para Googlebot y difícil de detectar en Google Search Console.

• 403 en URLs públicas: Googlebot no puede indexar el contenido. Si persiste, Google reduce el ranking de esas páginas y eventualmente las desindexo.
• 403 en recursos (CSS, JS, imágenes): Googlebot puede tener dificultades para renderizar correctamente la página, lo que puede afectar a la evaluación del Core Web Vitals y al posicionamiento.
• 403 en el .well-known/acme-challenge: no afecta directamente al SEO, pero impide la renovación del certificado SSL, que cuando caduca sí afecta gravemente al SEO y al tráfico.
• 403 en /wp-admin/ o recursos administrativos: sin impacto en el SEO. Googlebot entiende que esas URLs no son contenido público.

Preguntas frecuentes sobre el error HTTPS 403

¿El error HTTPS 403 significa que mi certificado SSL está mal instalado?

No. El error 403 ocurre después de que el handshake TLS se ha completado correctamente: el certificado SSL está funcionando bien y la conexión está cifrada. El problema es que el servidor, una vez establecida la conexión segura, deniega el acceso al recurso solicitado por razones de autorización (permisos de archivos, reglas de acceso, IP bloqueada, etc.). Si el certificado SSL estuviera mal instalado, verías un error SSL del navegador (pantalla roja de "Tu conexión no es privada") antes de ver ningún contenido, no un error 403.

¿Por qué apareció el error 403 justo después de instalar el certificado SSL?

Instalar el certificado SSL no causa directamente un error 403, pero puede haber varias razones por las que aparece coincidiendo con la instalación. La más frecuente es que la instalación de Certbot modificó la configuración del servidor web (Nginx o Apache) y esa modificación introdujo un conflicto con la configuración existente del sitio. Otra causa frecuente es que al activar Cloudflare con SSL, las reglas del WAF de Cloudflare bloquean solicitudes que antes pasaban sin problema. Revisa los logs del servidor inmediatamente después de la instalación para identificar el cambio que causó el 403.

¿El error 1020 de Cloudflare es lo mismo que un error 403?

El error 1020 de Cloudflare es el mensaje que Cloudflare muestra cuando su WAF bloquea una solicitud, y corresponde a un código HTTP 403 Forbidden. Desde el punto de vista del navegador y del protocolo HTTP, son equivalentes: el servidor (en este caso, Cloudflare como proxy) deniega el acceso al recurso. La diferencia es que en el Error 1020, quien toma la decisión de bloquear es Cloudflare (basándose en sus reglas de WAF), no el servidor de origen. Para resolver el 1020, hay que actuar en el panel de Cloudflare, no en el servidor.

¿Por qué Certbot falla con un error 403 al intentar renovar el certificado?

Certbot necesita acceder a la URL http://tudominio.com/.well-known/acme-challenge/TOKEN para completar el HTTP-01 challenge durante la renovación. Si el servidor devuelve un 403 para esa URL, la renovación falla. Las causas más frecuentes son: una regla en el .htaccess que bloquea todos los directorios ocultos (que empiezan por punto), una regla en Nginx que bloquea con deny all los archivos ocultos, o el proxy de Cloudflare que interfiere con el challenge. La solución es añadir una excepción explícita para el directorio .well-known en la configuración del servidor web.

¿Cómo puedo acceder a mi sitio si estoy bloqueado por Cloudflare con un error 403?

Si eres el administrador del sitio y tu propia IP está bloqueada por Cloudflare, tienes varias opciones: acceder al panel de Cloudflare desde otra IP o red (datos móviles en lugar de WiFi) y añadir tu IP a la lista blanca en Security > WAF > Tools > IP Access Rules; o conectarte al servidor directamente por SSH y acceder al panel de administración a través de un túnel SSH (sin pasar por Cloudflare). Si tu IP fue bloqueada por Fail2Ban en el servidor de origen, el bloqueo de Cloudflare desaparece al bypasear Cloudflare, y puedes acceder directamente al servidor por IP.

¿El error 403 en HTTPS afecta de forma diferente al SEO que el 403 en HTTP?

No de forma significativa. Desde 2021, Googlebot prefiere rastrear las versiones HTTPS de los sitios cuando están disponibles, pero el impacto de un error 403 en el posicionamiento es el mismo independientemente de si ocurre en HTTP o HTTPS: Googlebot no puede indexar el contenido bloqueado. La única diferencia práctica es que si tu sitio tiene redirecciones de HTTP a HTTPS y el 403 solo ocurre en HTTPS, Googlebot puede intentar la versión HTTP (sin redirección) y acceder correctamente, lo que reduciría el impacto. Verifica en Google Search Console si el 403 aparece en las URLs HTTPS o también en las HTTP para determinar el alcance real del problema.