Todas las guías

Tu propio sitio en un nombre .lopux

Tienes un nombre en Lopux-Internet; esta guía pone detrás un sitio web de verdad, accesible para cualquiera que use la aplicación. Si aún no tienes nombre, reserva uno primero.

Da por hecho que sabes levantar un servidor web y nada más. Todo lo que es propio de Lopux-Internet está aquí: por qué el certificado es autofirmado, qué tiene que funcionar junto a tu sitio y cuáles son los dos registros que hacen que el nombre funcione.

Las capturas muestran la interfaz en inglés. El portal habla seis idiomas: elige el tuyo con el botón EN de la esquina superior derecha.

1. Qué necesitas y qué no sirve

Una máquina donde tú controles el TLS del puerto 443. Un VPS, un servidor dedicado, un equipo en casa con una dirección accesible. Ese es todo el requisito, y es real.

Las plataformas gestionadas no pueden alojar esto, por dos razones independientes. Vercel, Netlify, Cloudflare Pages, la mayoría de PaaS: añades un dominio propio y el certificado lo obtienen y lo sirven ellos. Aquí todo se basa en que tu servidor demuestre que tiene la clave que publicaste tú; una plataforma que sirve su propia clave no puede dar esa prueba, y la aplicación del visitante rechazaría el sitio, con razón. Tampoco aceptarían el nombre: la configuración de dominios propios valida la propiedad a través del DNS de siempre, donde mysite.lopux no existe ni existirá.

Poner un CDN delante tampoco ayuda: termina el TLS, o sea, el mismo problema.

Las plataformas que permiten subir tu propio certificado y tu clave funcionarían mecánicamente, pero entonces esa parte puede hacerse pasar por tu sitio ante cada visitante, en silencio, y nada en este diseño puede detectarlo. Míralo como lo que es: entregar tu clave privada a un tercero.

2. Por qué el certificado es autofirmado

Ninguna autoridad de certificación puede emitir para un nombre de Lopux-Internet. No porque sea difícil, sino porque está prohibido: una autoridad solo puede emitir para nombres bajo la raíz del DNS de siempre, y estos nombres quedan deliberadamente fuera.

Así que en lugar de pedirle a un desconocido que responda por ti, publicas la huella de tu propia clave en la zona de tu nombre, y la aplicación de cada visitante compara el servidor al que llegó con ese registro. El registro es la autoridad.

En un aspecto concreto eso es más estricto que una autoridad: con una autoridad, cientos de organizaciones podrían emitir cada una un certificado para tu nombre y a cualquiera se le creería. Aquí solo funciona la clave que publicaste tú.

3. Crea el certificado

Diez años, sin contraseña, y todos los nombres que sirvas listados en subjectAltName:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
  -keyout site.key -out site.crt -days 3650 -nodes \
  -subj "/CN=mysite.lopux" \
  -addext "subjectAltName=DNS:mysite.lopux,DNS:www.mysite.lopux"

Tres cosas sobre ese comando:

• las fechas de validez aquí no importan. Las aplicaciones las ignoran a propósito: lo que

decide si tu clave sigue valiendo es el registro publicado, no una fecha dentro del certificado. Así que no hay renovación, nunca. Diez años es simplemente más de lo que te va a importar;

• -nodes significa que la clave no lleva contraseña, que es lo que un servidor web necesita

para arrancar sin nadie delante. Deja el archivo legible solo para el usuario del servidor (chmod 600) y fuera de cualquier imagen que subas a algún sitio;

• no pongas en el certificado nada que no publicarías. Quien complete un saludo TLS con tu servidor lo recibe y lee el nombre en él. Un nombre, sin organización ni correo.

4. Qué funciona junto a tu sitio

Tu sitio habla HTTP normal y nunca ve un certificado. Delante va nginx, que termina el TLS con la clave que publicaste y pasa la petición hacia dentro.

Ese frente existe porque un origen de Lopux-Internet necesita varios ajustes que son lo contrario de lo que da una plantilla de «nginx endurecido» corriente, y cada uno falla de una forma que en el navegador parece correcta:

Aquí está ese nginx, entero. Cambia el nombre, las rutas y la dirección de detrás:

map $http_upgrade $connection_upgrade { default upgrade; '' close; }
server_tokens off;

# lo que no sea tu nombre: puerta cerrada, sin certificado
server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name mysite.lopux;

    ssl_certificate     /etc/ssl/site.crt;   # la clave cuya huella publicas
    ssl_certificate_key /etc/ssl/site.key;
    ssl_protocols       TLSv1.2 TLSv1.3;     # autofirmado: nada que grapar

    client_header_timeout 10s;   # acotan el saludo TLS — ver abajo
    client_body_timeout   10s;
    send_timeout          10s;
    keepalive_timeout     30s;
    reset_timedout_connection on;

    proxy_hide_header Strict-Transport-Security;

    location / {
        proxy_pass http://127.0.0.1:8080;   # tu sitio, HTTP normal, sin publicar
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto https;   # regla 2: sin redirección
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header Upgrade           $http_upgrade;
        proxy_set_header Connection        $connection_upgrade;
        proxy_connect_timeout 5s;
        proxy_read_timeout    60s;
    }
}

Una trampa en esos plazos, con la que nginx directamente no arranca: ssl_handshake_timeout no existe en el módulo http de nginx — pertenece a stream. En http el saludo lo acota client_header_timeout, y por eso es ese valor el que hace el trabajo aquí.

El filtro por SNI merece un párrafo aparte, porque hace algo menos evidente que esconderse de los escáneres. Sin él, tu servidor entrega el mismo certificado — y por tanto el mismo aviso del navegador — a dos visitantes en situaciones opuestas: uno cuya aplicación comparó tu clave con el registro antes de que se moviera un solo byte de la página, y otro que escribió tu dirección IP, donde no se comprobó nada en absoluto. El filtro elimina el segundo caso. No convierte el aviso en una verificación: quien conozca tu nombre puede ponerlo en su propio hosts y llegar sin comprobación igual que antes.

Una regla sobre tus páginas, y se pasa por alto con facilidad: usa enlaces relativos. /about, no https://mysite.lopux/about. Un visitante en modo http:// normal no puede seguir un enlace absoluto https:// a tu propio sitio, y Lopux-Internet deliberadamente no reescribe tus páginas. Los enlaces a otros sitios son cosa tuya y no se ven afectados.

5. Publica la huella de la clave

Abre tu nombre en el portal y baja hasta Certificados. Mientras no haya nada publicado, lo dice sin rodeos: no hay con qué comparar, así que la aplicación se niega a abrir el sitio en lugar de conectarse sin verificar.

Sube site.crt con Elegir archivo de certificado…, o pégalo. Solo el certificado: el archivo que empieza por -----BEGIN PRIVATE KEY----- se queda en tu servidor, y el portal lo rechaza en lugar de guardarlo.

Pulsa Publicar la huella de la clave. El portal lee el certificado, toma el SHA-256 de su clave pública y lo escribe en tu zona.

Compárala con tu propia copia: tienen que coincidir.

openssl x509 -in site.crt -noout -pubkey \
  | openssl pkey -pubin -outform der | openssl dgst -sha256

El apartado es una puerta principal a un registro corriente. El mismo valor está en tu lista de registros como un registro TLSA en _443._tcp, y ahí se ve:

6. Apunta el nombre a tu servidor

En esa misma vista añade un registro A cuyo valor sea la dirección pública de tu servidor. @ significa el nombre en sí.

Ahora la zona lleva los dos registros y, juntos, son todo lo que necesita la aplicación de un visitante: el registro A dice dónde está tu servidor y el TLSA, qué clave debe presentar.

Cuenta con unos diez minutos antes de esperar que un cambio se vea en todas partes. Hay dos cachés por medio, la del resolutor y la de la aplicación, de cinco minutos cada una.

7. Compruébalo

El portal descarga tu sitio como lo haría un visitante y te dice qué impediría que funcionara: una clave que no coincide con la publicada, una huella que falta, una cabecera HSTS, una redirección a https://, enlaces absolutos a ti mismo o un servidor que no respondió.

En esa captura la comprobación se niega a ejecutarse: la dirección del ejemplo es de documentación, y el portal no sondea nada que no sea accesible desde internet — apuntar un nombre a una dirección privada o de bucle local convertiría la comprobación en un sondeo de la red de otra persona. Con un servidor real en una dirección real responde que el sitio está bien, o nombra exactamente qué falla.

Dos comprobaciones que puedes hacer tú, y son las que más importan:

# sin SNI — rechazado
openssl s_client -connect YOUR_ADDRESS:443 </dev/null

# tu certificado
openssl s_client -connect YOUR_ADDRESS:443 -servername mysite.lopux </dev/null

La segunda debería entregarte el certificado cuya huella publicaste. Saca la huella de su clave igual que en §5 y compara: si las dos cadenas difieren, todos los visitantes son rechazados, y para ellos tiene exactamente el aspecto de un intento de suplantación.

8. Qué ve un visitante

Un sitio bien configurado se abre bajo su propio nombre, como cualquier otro:

Ese es lopux.ipvx, el sitio del propio proyecto. Vive en el espacio de nombres igual que vivirá el tuyo y está montado exactamente con esta forma. La clave que sirve coincide con su huella publicada, y por eso una aplicación lo abre sin una sola advertencia.

Lo que obtienen los distintos visitantes:

La última fila es el sentido del espacio de nombres, no una limitación. Pero fíjate en la anterior: tu servidor es una máquina pública corriente y cualquiera puede llegar a él por su dirección. El espacio de nombres no lo esconde, y tu certificado le dice el nombre de tu sitio a cualquiera que complete un saludo TLS: para eso está el filtro por SNI de §4.

9. Cuidar la clave

Nada de esto detecta una clave robada; solo hace que el vínculo entre tu nombre y tu clave sea autoritativo. Quien tenga tu clave se autentica impecablemente hasta que publiques una huella nueva.

• deja site.key legible solo para el usuario del servidor web y fuera del directorio que sirves;
• guarda una copia cifrada: perderla te cuesta un cambio de clave, no tu nombre;
• cambiarla es barato, así que hazlo ante cualquier sospecha. Publica el certificado nuevo antes de cambiar: con dos huellas publicadas se acepta cualquiera de las dos claves, así que

no hay ningún momento en que tu sitio quede inaccesible. Después cambia el servidor, espera diez minutos y quita la vieja;

• quitar una huella es la revocación. No hay a quién pedir permiso ni nada que esperar: dentro

de la ventana de caché al visitante se le rechaza, en vez de mostrarle a quien tenga la clave vieja.

10. Cuando algo va mal

La aplicación nombra el fallo en lugar de mostrar una página en blanco. Qué significa cada uno:

Todas las guías