Modos SSL

None

Solo HTTP en el puerto 80. Sin gestión de certificados de ningún tipo, a propósito, no abre ningún listener en 443. Útil para pruebas rápidas o servicios estrictamente internos donde no importa el cifrado.

nginx
server {
    listen 80;
    server_name misitio.com;
    location / {
        proxy_pass http://<forward_host>:<forward_port>;
        ...
    }
}

Ojo con dominios detrás de Cloudflare con la nube naranja activada. Si el dominio está proxied en Cloudflare (aunque no se use ese modo acá), Cloudflare, y casi cualquier navegador moderno por defecto, va a intentar conectarse por HTTPS. Como este modo no tiene nada escuchando en 443, eso devuelve un error (520 desde Cloudflare, o el navegador simplemente no carga la página). Si el dominio tiene la nube naranja activada, usá el modo Cloudflare en vez de None, aunque no te interese emitir ningún certificado real: es el modo que agrega el listener 443 que Cloudflare necesita para hablar con el origen. Reservá None para dominios sin proxy de ningún tipo (DNS-only / nube gris).

Cloudflare (orange-cloud)

El usuario prende la nube naranja en el registro DNS dentro de Cloudflare. Wings escribe:

  • Puerto 80: proxy_pass normal, confiando en los headers que manda Cloudflare (CF-Connecting-IP para la IP real del visitante, X-Forwarded-Proto heredado de Cloudflare).
  • Puerto 443 con un certificado autofirmado generado localmente por Wings (ECDSA P-256, válido 10 años, se regenera solo si quedan menos de 30 días antes de vencer).

Este segundo listener en 443 es clave: permite que Cloudflare funcione en modo Full o Full (Strict), que son los modos por defecto/recomendados en Cloudflare hoy, sin que el usuario tenga que subir ni gestionar ningún certificado. En modo Flexible (Cloudflare habla HTTP puro con el origen) ese segundo listener directamente no se usa, pero no molesta que exista.

Si tu Cloudflare está en modo Flexible y ves errores de "too many redirects", es un problema de configuración de Cloudflare (conflicto flexible + redirect a HTTPS en el origen), no de este addon.

Let's Encrypt

Requisitos: puerto 80 abierto en el nodo y el registro DNS del dominio ya resuelto a la IP del nodo (certbot no puede completar el challenge si el DNS no propagó).

Flujo interno:

  1. Wings escribe primero un bloque solo HTTP (igual al modo None).
  2. certbot certonly --nginx -d <dominio> --non-interactive --agree-tos -m <email>: esto solo emite el certificado, no toca la configuración de nginx (a diferencia del uso típico de certbot --nginx, acá se usa certonly a propósito).
  3. Wings reescribe el .conf con el bloque SSL completo: redirect 301 de 80 a 443, y el server { listen 443 ssl; ... } apuntando a /etc/letsencrypt/live/<dominio>/fullchain.pem y privkey.pem.
  4. nginx -t && nginx -s reload.

La renovación del certificado la maneja el cron/systemd-timer de certbot que ya corre en el nodo por fuera del addon; el addon no la gestiona ni la supervisa. Si certbot no está renovando correctamente a nivel de sistema, es un problema de esa instalación, no de PawProxy.

Si la emisión del certificado falla (por ejemplo DNS no resuelto todavía), el dominio queda funcionando por HTTP y el error se guarda en error_message. El proxy no se cae, solo no tiene HTTPS todavía.

Custom (certificado propio)

El usuario pega su propio certificado y clave privada (PEM), útil si ya tiene un certificado wildcard, EV, o emitido por otra CA y no quiere depender de Let's Encrypt.

Flujo:

  1. En "Add Domain", modo Custom certificate → aparecen dos campos de texto: certificado (cadena completa, PEM) y clave privada (PEM).
  2. El panel guarda ambos encriptados en la base de datos (cast encrypted de Laravel, usa el APP_KEY del panel). Nunca se devuelven por la API una vez guardados, ni siquiera al mismo usuario que los subió.
  3. ApplyDomainProxy los manda a Wings solo cuando ssl_mode = custom.
  4. proxy/manager.go los escribe en /etc/nginx/ssl/pawproxy/<dominio>/{fullchain,privkey}.pem (permisos 0600) y arma el bloque listen 443 ssl apuntando ahí.
  5. Al borrar el dominio, Revoke() borra esa carpeta junto con el resto de la limpieza.

Requiere que el nodo tenga "User-supplied certificate" en Allowed (Admin → Nodes → (nodo) → Proxy). Si está en Blocked, la creación falla con "Custom SSL certificates are not enabled for this node." antes de llegar a Wings.

No hay renovación automática: si el certificado pegado tiene fecha de vencimiento, es responsabilidad del usuario volver a cargarlo (borrar el dominio y crearlo de nuevo) antes de que expire.

Siguiente: Solución de problemas →