Ves el candado junto a la dirección y piensas que la web es segura. En parte es verdad, pero el candado promete bastante menos de lo que mucha gente cree. En esta guía verás qué pasa realmente cuando abres una web con HTTPS: cómo se cifra la conexión, para qué sirve un certificado, quién lo firma y qué significan los errores que a veces te frenan el paso.
En resumen
- HTTPS es HTTP dentro de un túnel TLS: cifra los datos y comprueba que hablas con el servidor correcto.
- El certificado demuestra que el servidor controla ese dominio, firmado por una autoridad en la que confía tu navegador.
- El candado no dice que la web sea honrada: una web de phishing también puede tener HTTPS.
Qué añade HTTPS a HTTP
HTTP es el idioma con el que el navegador pide páginas. Por sí solo viaja en claro: cualquiera en medio (el wifi del bar, un router comprometido) puede leer lo que envías y modificar lo que recibes.
HTTPS mete esa conversación dentro de TLS (Transport Layer Security, sucesor del antiguo SSL; por costumbre se sigue diciendo «certificado SSL»). TLS aporta tres garantías:
| Garantía | Qué significa | Sin ella |
|---|---|---|
| Confidencialidad | Nadie en medio puede leer los datos | Contraseñas y formularios a la vista |
| Integridad | Nadie puede modificarlos sin que se note | Inyección de anuncios o código en la página |
| Autenticación | Hablas con el dueño del dominio | Un impostor podría hacerse pasar por la web |
Cifrado simétrico y asimétrico, explicado simple
TLS combina dos tipos de cifrado porque cada uno es bueno en una cosa.
Simétrico: una misma clave cifra y descifra. Es como una caja fuerte con una única llave que tienen las dos partes. Es muy rápido, ideal para mover megas de datos. Algoritmos típicos: AES y ChaCha20. El problema: ¿cómo os ponéis de acuerdo en la llave sin que nadie la vea por el camino?
Asimétrico: cada parte tiene un par de claves, una pública y una privada. Lo que se firma con la privada se comprueba con la pública, y permite acordar secretos sobre un canal que todos escuchan. Es como un candado abierto que repartes a quien quiera: cualquiera puede cerrarlo, solo tú tienes la llave. Es lento, pero resuelve el problema de la llave.
TLS usa lo asimétrico al principio, para autenticar al servidor y acordar una clave, y luego pasa a lo simétrico para todo lo demás.
El apretón de manos TLS
Antes de enviar un solo byte de la página, navegador y servidor hacen un handshake. Simplificado, en TLS 1.3:
- Hola del cliente: el navegador dice qué versiones y algoritmos admite y envía su parte de un intercambio de claves.
- Hola del servidor: el servidor elige algoritmos y envía su parte del intercambio. Con ambas partes, cada uno calcula la misma clave simétrica sin que haya viajado por la red.
- Certificado: el servidor manda su certificado y una firma hecha con su clave privada que prueba que lo posee.
- Verificación: el navegador comprueba el certificado (dominio, fechas, firma de la autoridad).
- Terminado: ambos confirman que nadie ha manipulado el saludo y empieza el tráfico cifrado.
En TLS 1.3 todo esto cabe en un solo viaje de ida y vuelta, por eso apenas se nota. Además, la clave de cada sesión es efímera: aunque algún día robaran la clave privada del servidor, no serviría para descifrar conversaciones grabadas antes.
Puedes ver un handshake real desde la terminal:
curl -vI https://www.wikipedia.org 2>&1 | grep -E "SSL connection|subject|issuer|expire"
openssl s_client -connect www.wikipedia.org:443 -servername www.wikipedia.org -brief
Certificados y cadena de confianza
Un certificado es un documento digital que dice, básicamente: «la clave pública X pertenece al dominio ejemplo.es, válido hasta tal fecha», firmado por una autoridad de certificación (CA).
¿Y por qué fiarse de la CA? Porque tu sistema operativo y tu navegador traen de serie una lista de certificados raíz de CA auditadas. La confianza funciona en cadena:
Certificado raíz (preinstalado en tu equipo)
└── Certificado intermedio (firmado por la raíz)
└── Certificado del sitio (firmado por el intermedio)
Las raíces se guardan muy protegidas y casi nunca firman directamente; para el día a día usan intermedios. El servidor debe enviar su certificado y el intermedio. Si olvida el intermedio, algunos navegadores lo apañan y otros dan error: es un fallo de configuración muy común.
Hay tipos de validación distintos:
| Tipo | Qué comprueba la CA | Cuándo se usa |
|---|---|---|
| DV (validación de dominio) | Que controlas el dominio | La inmensa mayoría de webs |
| OV (validación de organización) | Dominio y que la empresa existe | Webs corporativas |
| EV (validación extendida) | Comprobación más estricta de la empresa | Antes se marcaba en verde; hoy los navegadores no lo destacan |
Qué garantiza el candado y qué no
El candado (o el icono de ajustes que algunos navegadores muestran ahora en su lugar) significa una cosa concreta: la conexión con este dominio está cifrada y el servidor ha demostrado controlar ese dominio.
No significa:
- Que la empresa detrás sea legítima.
- Que la web no sea un fraude.
- Que el dominio sea el que crees:
banco-seguro-acceso.compuede tener un certificado perfecto.
Conseguir un certificado DV es gratis y automático, así que la mayoría de webs de phishing tienen HTTPS. Lo que hay que mirar es el dominio exacto en la barra de direcciones, no el candado. Lo contrario sí vale como alarma: si una web te pide datos sin HTTPS, no los escribas.
Let’s Encrypt y la caducidad
Let’s Encrypt es una autoridad de certificación sin ánimo de lucro que emite certificados DV gratis y automáticos mediante el protocolo ACME. Fue clave para que HTTPS pasara de minoritario a casi universal.
Sus certificados duran 90 días, a propósito: obliga a automatizar la renovación y limita el daño si una clave se filtra. Además, el sector ha acordado ir reduciendo la duración máxima de todos los certificados públicos en los próximos años, así que renovar a mano tiene los días contados.
Con un servidor propio, el cliente más conocido es Certbot:
sudo certbot --nginx -d ejemplo.es -d www.ejemplo.es
sudo certbot renew --dry-run
El segundo comando simula la renovación. Si pasa, la tarea automática que instala Certbot se encargará de renovar antes de que caduque.
Errores típicos de certificado y qué significan
| Mensaje (Chrome / Firefox) | Qué pasa | Qué hacer |
|---|---|---|
NET::ERR_CERT_DATE_INVALID / SEC_ERROR_EXPIRED_CERTIFICATE | Certificado caducado, o el reloj de tu equipo está mal | Revisa la fecha del equipo; si está bien, avisa a la web |
NET::ERR_CERT_COMMON_NAME_INVALID / SSL_ERROR_BAD_CERT_DOMAIN | El certificado es de otro dominio | No continúes si es una web donde inicias sesión |
NET::ERR_CERT_AUTHORITY_INVALID / SEC_ERROR_UNKNOWN_ISSUER | Firmado por una CA desconocida, autofirmado o falta el intermedio | Normal en un router o NAS doméstico; sospechoso en una web pública |
ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Servidor con TLS antiguo que el navegador ya no acepta | Problema del servidor; necesita actualizar |
| Candado con aviso o «no es seguro» parcial | Contenido mixto: la página es HTTPS pero carga recursos por HTTP | Problema de la web, no de tu equipo |
Si el error aparece en todas las webs a la vez, el culpable está de tu lado: reloj del sistema desajustado, un antivirus que inspecciona HTTPS o un portal cautivo de wifi público que todavía no has aceptado.
Errores habituales
- Confiar en el candado como sello de honradez. Mira el dominio, siempre.
- Pulsar «Continuar de todos modos» por costumbre. En el panel de tu router puede ser aceptable; en tu banco, nunca.
- Pensar que HTTPS oculta qué webs visitas. Cifra el contenido y la ruta, pero tu operador puede saber a qué dominio te conectas, por ejemplo mediante las consultas DNS.
- Olvidar la renovación en un servidor propio. Automatízala y prueba con
--dry-run. - Servir el certificado sin el intermedio. Funciona en tu navegador y falla en el móvil de otro.
