Qué es un certificado SSL y para qué sirve

Cuando abres un sitio con https://, el navegador y el servidor acuerdan una clave secreta antes de intercambiar cualquier página, contraseña o token. Sin eso, todo viaja en texto plano: el Wi-Fi de la cafetería, tu proveedor de internet y cualquier equipo en el camino pueden leer y alterar el contenido. El protocolo que hace ese acuerdo es TLS.

"SSL" sigue siendo el nombre que todos buscan y el que usan los paneles de hosting, pero el protocolo SSL como tal quedó obsoleto: hoy lo que se usa es TLS. Entender cómo funciona te ayuda a poner HTTPS en tu sitio, en el panel de tu bot o en tu API, y a diagnosticar cuando el certificado da error.

¿Qué es SSL/TLS?#

TLS (Transport Layer Security) es un protocolo que se sitúa entre TCP y la aplicación (HTTP, SMTP, bases de datos y otros). Ofrece tres garantías:

• Confidencialidad: los datos se cifran, así que quien intercepta el tráfico solo ve bytes sin sentido.
• Integridad: cualquier alteración en el camino se detecta.
• Autenticación: el cliente confirma, mediante un certificado, que habla con el servidor del dominio que escribió.

SSL (Secure Sockets Layer) fue creado por Netscape en los años 90. SSL 3.0 fue prohibido por la RFC 7568 por fallos de seguridad, y TLS 1.0 y 1.1 fueron declarados obsoletos por la RFC 8996. Las versiones en uso hoy son TLS 1.2 y TLS 1.3 (RFC 8446). Cuando alguien dice "certificado SSL", casi siempre se refiere al certificado que usa TLS.

¿Cómo funciona el handshake TLS?#

El handshake es la negociación que ocurre tras la conexión TCP y antes de los datos de la aplicación. De forma simplificada, en TLS 1.3:

1. ClientHello. El navegador envía las versiones y conjuntos de cifrado que acepta, el nombre del dominio (extensión SNI) y su parte del intercambio de claves.
2. ServerHello y certificado. El servidor elige los parámetros, devuelve su parte del intercambio de claves y envía el certificado, junto con una prueba de que posee la clave privada correspondiente.
3. Verificación. El navegador comprueba que el certificado es válido para el dominio, que no ha caducado y que lo firmó una autoridad en la que confía.
4. Clave de sesión. Ambos lados calculan la misma clave simétrica sin enviarla nunca por la red. A partir de ahí, todo se cifra con ella.

TLS 1.3 resuelve todo esto en un solo viaje de ida y vuelta, uno menos que TLS 1.2, lo que reduce la latencia de cada conexión nueva. El cifrado de clave pública solo se usa para establecer la clave; los datos usan cifrado simétrico, mucho más rápido.

¿Qué es un certificado y quién lo firma?#

El certificado es un archivo que vincula una clave pública con un nombre de dominio. Contiene el dominio (o dominios), la clave pública, las fechas de validez y la firma de quien lo emitió.

Esa firma proviene de una autoridad certificadora (CA). El sistema operativo y el navegador ya incluyen una lista de CA raíz de confianza. En la práctica, el servidor envía una cadena: el certificado del sitio, firmado por una CA intermedia, que a su vez está firmada por la raíz. Si la cadena termina en una raíz conocida, el navegador confía en el certificado.

La mayoría de los certificados de sitios son de tipo DV (Domain Validation): la CA solo confirma que quien lo pidió controla el dominio. Los tipos OV y EV comprueban además la organización. Para la mayoría de los proyectos, DV es suficiente, y Let's Encrypt emite este tipo de certificado sin costo. Para comparar las opciones, mira certificado SSL de pago o gratuito.

Los certificados tienen una validez limitada y cada vez más corta: Let's Encrypt, por ejemplo, publicó un calendario que reduce por etapas los 90 días que fueron durante años su valor por defecto. Por eso la renovación debe ser automática.

¿Cómo comprobar el certificado de un dominio?#

Desde la terminal, con OpenSSL:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

La salida muestra para quién se emitió (subject), quién lo emitió (issuer) y el periodo de validez (notBefore y notAfter). La opción -servername envía el SNI, necesario cuando varios dominios comparten la misma IP.

Con curl puedes ver la versión de TLS negociada:

curl -vI https://example.com 2>&1 | grep -E "SSL connection|TLSv|expire date|issuer"

Si algo falla, el mensaje de error suele indicar el camino. Para los casos más comunes, mira errores de certificado SSL.

¿Dónde termina TLS en tu arquitectura?#

No siempre es tu app la que se encarga del TLS. Es habitual que un proxy inverso, un balanceador de carga o una CDN reciba la conexión HTTPS, descifre el tráfico ahí (la llamada terminación TLS) y reenvíe la petición a tu app. Así los certificados y las claves quedan fuera de tu código.

En la práctica, tu app puede recibir HTTP plano detrás del proxy. Para saber si el acceso original fue HTTPS, lee la cabecera X-Forwarded-Proto (con la configuración de proxy de confianza de tu framework) en lugar de deducirlo por el esquema de la conexión local.

¿Cuándo no basta con TLS?#

TLS protege los datos en tránsito y nada más. No evita la inyección SQL, no valida lo que envía el usuario, no protege contraseñas almacenadas ni garantiza que el dueño del sitio sea honesto. Tampoco lo oculta todo: la IP del servidor y, en la mayoría de los casos, el nombre del dominio al que accedes siguen siendo visibles para quien observa la red.

Cómo hacerlo en Square Cloud#

En Square Cloud, el TLS queda delante de tu aplicación, como en la arquitectura de la sección anterior: la app escucha en HTTP, en 0.0.0.0 y en el puerto de la variable PORT, y la plataforma publica el tráfico por HTTPS. El certificado y la clave privada nunca entran en tu código.

Toda aplicación web recibe un subdominio *.squareweb.app con HTTPS, en todos los planes. El certificado DV se emite y se renueva solo, así que los plazos de validez cada vez más cortos no se vuelven tarea tuya. Las peticiones HTTP se redirigen a HTTPS, y las cabeceras que envía tu aplicación, como HSTS, pasan intactas.

Para usar tu propio dominio, disponible desde el plan Standard (desde R$44,99 al mes), creas en tu registrador los registros DNS que muestra el panel y sigues la validación en tiempo real. El certificado se emite automáticamente cuando el dominio resuelve. La red incluye además HTTP/3, WAF y mitigación de DDoS. Consulta los pasos en dominios personalizados y los detalles de la red en red y CDN.