DESCRIPCIÓN BREVE

Configuración Https en servidores

Apache2

ACTIVIDAD: Autor: Santiago Galván Sánchez

Esta obra está bajo una Licencia Creative
Commons Atribución-NoComercial-

SEGURIDAD EN
CompartirIgual 4.0 Internacional. Para ver
una copia de esta licencia, visite
[Link]
sa/4.0

SERVIDORES WEB
LAMP
Servicios en red – 2º CFGM SMR
ACTIVIDAD 3: SEGURIDAD EN SERVIDORES WEB (HTTPS Y CERTIFICADOS
SSL)
• Módulo: Servicios en Red
• Grado: Sistemas Microinformáticos y Redes (SMR)
• Entorno: Ubuntu Server 24.04 LTS (Continuación de la actividad de VirtualHosts)

1.1 Objetivos de la Actividad

En esta tercera fase, elevaremos el nivel de seguridad de nuestro servidor. Ya sabemos servir
múltiples webs, pero ahora aprenderemos a proteger los datos que viajan entre el servidor y el
cliente.
• Comprender la diferencia entre HTTP y HTTPS.
• Entender el concepto de Certificado SSL/TLS y la encriptación asimétrica.
• Generar certificados autofirmados (Self-Signed) para entornos de pruebas.
• Configurar Apache para servir tráfico seguro por el puerto 443.
• Implementar redirecciones forzadas de HTTP a HTTPS.

1.2 Fundamentos: ¿Por qué el candadito es importante?

Hasta ahora, nuestras webs ([Link], etc.) funcionan sobre HTTP (puerto
80). Esto significa que la información viaja en “texto plano”.

1.2.1 La Analogía de la Postal vs. El Sobre Blindado

Imagina que los datos que envías al servidor son una carta:
• HTTP (La Postal): Envías una postal abierta. Cualquiera que esté en el camino (el cartero,
el vecino, un hacker en la cafetería) puede leer lo que has escrito. Si envías una contraseña,
la ven.
• HTTPS (El Sobre Blindado): Metes la carta en una caja fuerte indestructible antes de
enviarla. Solo el destinatario (el servidor) tiene la llave para abrirla. Cualquiera que
intercepte el paquete en el camino solo verá una caja cerrada, pero no podrá leer el
contenido.
Para lograr esto, necesitamos dos cosas: 1. Módulo SSL/TLS: El mecanismo de cifrado. 2.
Certificado Digital: El documento que garantiza que “soy quien digo ser” (como un DNI digital).

Contexto del Escenario: “Crisis de Privacidad”

• Tu Rol: Sigues siendo el SysAdmin Junior estrella en “EduServer Solutions S.L.”.
• El Cliente: Instituto Tecnológico Central.

Servicios en red – 2º CFGM SMR – IES Ana Luisa Benítez - P á g i n a 1 | 10

 • La Situación: Tras el éxito de los VirtualHosts, hubo un incidente. Un alumno “avispado” de
segundo curso utilizó un sniffer (Wireshark) en la red de la biblioteca e interceptó el usuario
y contraseña del Director cuando este accedía al panel de administración, ya que la web
viajaba en texto plano.
• La Consecuencia: El Director está muy preocupado. Ha exigido que todas las
comunicaciones con los servidores del instituto se cifren inmediatamente.

☑ La Misión (El Correo de Encargo)

Recibes el siguiente correo urgente marcado con prioridad ALTA:
De: Laura M. (Directora de Infraestructura)
Para: SysAdmin Junior
Asunto: URGENTE: Implementación de SSL/TLS y mitigación de riesgos
Hola,
Tenemos un problema de seguridad. El cliente ha reportado una brecha de datos debido a
la falta de cifrado en las webs que desplegaste ayer.
No te culpo, no estaba en los requisitos iniciales, pero ahora es imperativo solucionarlo.
Necesito que actives el protocolo HTTPS en el servidor Ubuntu 24.04.
Dado que estamos en un entorno de desarrollo local y no tenemos dominios públicos
reales, no podemos comprar certificados oficiales. Utilizaremos Certificados
Autofirmados (Self-Signed).
Tus tareas para hoy:
1. Generar claves criptográficas: Crea certificados SSL para el servidor.
2. Habilitar HTTPS: Configura Apache para escuchar en el puerto 443.
[Link] los VirtualHosts: Tanto la web del instituto como la de la biblioteca deben
funcionar con el “candado” (aunque el navegador nos avise de que no es una entidad
certificadora conocida, eso es normal en pruebas).
Confío en que lo tengas listo antes del almuerzo.
Saludos, Laura M.

Servicios en red – 2º CFGM SMR – IES Ana Luisa Benítez - P á g i n a 2 | 10

1.3 RETO 1: Habilitando SSL y Certificados Autofirmados
Vamos a configurar el servidor para que soporte conexiones seguras. Como no somos una entidad
certificadora (como VeriSign o Let’s Encrypt), crearemos nuestro propio certificado.

1.3.1 Pasos a seguir:

1. Conexión y preparación: Conéctate por SSH a tu servidor (igual que en actividades anteriores).
2. Habilitar el módulo SSL en Apache: Apache trae la capacidad de encriptar, pero viene apagada
por defecto.
sudo a2enmod ssl
sudo systemctl restart apache2

3. Crear el certificado SSL: Usaremos la herramienta openssl para crear un certificado válido por
365 días. Guardaremos las claves en una carpeta organizada.
sudo mkdir -p /etc/apache2/certs
sudo openssl req -x509
-nodes -days 365 -newkey rsa:2048
-keyout /etc/apache2/certs/[Link]
-out /etc/apache2/certs/[Link]
IMPORTANTE: Durante este proceso, te pedirá datos (Country, State, etc.). Puedes rellenarlos o
dejarlos en blanco, pero en "Common Name (CN)" pon: *.[Link]
4. Configurar el Puerto 443 en el Firewall y VirtualBox: Igual que hicimos con el puerto 8081,
necesitamos habilitar el puerto 443 que usa https.
• En Ubuntu (UFW):
sudo ufw allow 443/tcp
• En VirtualBox (Máquina apagada o en caliente): Ve a Configuración -> Red -> Reenvío de
puertos. Añade una nueva regla:
o Nombre: https
o Protocolo: TCP
o IP Anfitrión: [Link]
o Puerto Anfitrión: 8443 (Usaremos este porque el 443 de tu Windows suele estar
ocupado o restringido).
o IP Invitado: (Dejar en blanco)
Servicios en red – 2º CFGM SMR – IES Ana Luisa Benítez - P á g i n a 3 | 10
 o Puerto Invitado: 443

5. Configurar el VirtualHost por defecto para SSL: Apache trae un archivo de configuración de
ejemplo para SSL. Vamos a activarlo.
sudo a2ensite [Link]
sudo systemctl reload apache2
Sin embargo, debemos decirle a ese archivo dónde están nuestros nuevos certificados.
sudo nano /etc/apache2/sites-available/[Link]
Busca las líneas SSLCertificateFile y SSLCertificateKeyFile y cámbialas por las rutas de los archivos
que creaste en el paso 3:
SSLCertificateFile /etc/apache2/certs/[Link]
SSLCertificateKeyFile /etc/apache2/certs/[Link]
Guarda y recarga Apache (sudo systemctl reload apache2).
Comprobación: Abre en tu navegador de Windows: [Link] ¡ALERTA! Verás una
pantalla roja o un aviso de "La conexión no es privada".

Servicios en red – 2º CFGM SMR – IES Ana Luisa Benítez - P á g i n a 4 | 10

 • ¿Por qué? Porque el navegador no conoce a "EduServer Solutions" como una autoridad
mundial.
• Solución: Pulsa en "Configuración avanzada" -> "Acceder a localhost (sitio no seguro)".
• Deberías ver la página por defecto de Apache, pero ahora con https en la barra.

1.4 RETO 2: VirtualHosts Seguros (SNI)

Laura M. te escribe de nuevo: "He visto que el localhost funciona, pero [Link] sigue
yendo por HTTP inseguro. Migra los portales del reto anterior a HTTPS."
Para alojar varios dominios HTTPS en una misma IP, Apache usa SNI (Server Name Indication).
1.4.1 Pasos a seguir:
1. Duplicar la configuración: Vamos a modificar los archivos del "Instituto" y la "Biblioteca" que
creamos en la actividad anterior para añadir la versión SSL.
2. Editar [Link] para soportar SSL: Vamos a editar el archivo de configuración. Nota: Lo
ideal es crear un archivo nuevo [Link], pero por simplicidad editaremos el existente
añadiendo un segundo bloque.
sudo nano /etc/apache2/sites-available/[Link]
Añade al final del archivo (sin borrar lo que ya hay del puerto 80) el siguiente bloque:
<VirtualHost *:443>
ServerName [Link]
DocumentRoot /var/www/instituto

SSLEngine on
SSLCertificateFile /etc/apache2/certs/[Link]
SSLCertificateKeyFile /etc/apache2/certs/[Link]
</VirtualHost>
3. Repetir para [Link]: Haz lo mismo en el archivo de la biblioteca, cambiando el
ServerName y el DocumentRoot correspondientes.
<VirtualHost *:443>
ServerName [Link]

Servicios en red – 2º CFGM SMR – IES Ana Luisa Benítez - P á g i n a 5 | 10

 DocumentRoot /var/www/biblioteca
SSLEngine on
SSLCertificateFile /etc/apache2/certs/[Link]
SSLCertificateKeyFile /etc/apache2/certs/[Link]
</VirtualHost>
4. Recargar:
sudo systemctl reload apache2
Comprobación: Accede a [Link] (Recuerda poner el puerto 8443
al final y aceptar el riesgo de seguridad). Deberías ver la web del instituto bajo HTTPS.

1.5 RETO 3: "Nadie escribe HTTPS manualmente"

Contexto: Son las 13:50 PM. Estás a punto de irte a comer. Recibes un Whatsapp de Laura:
"El Director del instituto dice que él escribe [Link] y le sigue saliendo la web
insegura. No se acuerda nunca de escribir https:// al principio. Configura una Redirección
Forzada. Quiero que si alguien entra por el puerto 80 (HTTP), el servidor lo lance automáticamente
al puerto 443 (HTTPS). Hazlo para la web del instituto. ¡Gracias!"
Configuración:
Debes modificar la configuración del puerto 80 en el archivo [Link] para que no muestre la
web, sino que redirija al puerto 443, https. En nuestro laboratorio, para que nos funcione desde el
navegador en Windows, lo redirigimos al puerto 8443 que es el puerto que tenemos redireccionado
en virtualbox, al puerto 443 de la máquina virtual.
Habilita el módulo “rewrite” de Apache
sudo a2enmod rewrite
sudo systemctl restart apache2
Edita el archivo [Link] en /etc/apache2/sites-available

Servicios en red – 2º CFGM SMR – IES Ana Luisa Benítez - P á g i n a 6 | 10

Recarga la configuración: sudo systemctl reload apache2
Prueba en el navegador a acceder de nuevo a [Link] y verifica que
automáticamente se redirige a https, puerto 8443

Explicación de la regla indica:

• %{SERVER_NAME}: Apache coge automáticamente el nombre definido arriba

(instituto.127...). Así, si copias y pegas este bloque en otro archivo (ej. biblioteca),
funcionará sin cambiar nada.
• :8443: ¡OJO AQUÍ! Esto sí te recomiendo dejarlo fijo.
o ¿Por qué? Porque tu usuario entra desde Windows usando el puerto 8080. Si usas la
variable automática del puerto del cliente, Apache intentará redirigir a
[Link] (que es incorrecto para SSL) o al puerto por defecto 443 (que en tu
Windows puede no estar redirigido a la VM).
o Al poner :8443 te aseguras de que el navegador de Windows vaya al puerto correcto
donde escucha el SSL.
• $1: Es la parte de la URL que va después del dominio (ej: /fotos/[Link]). Esto asegura
que si alguien entra a una subcarpeta, no lo mandes a la página de inicio, sino a la misma
subcarpeta pero segura.

1. RewriteRule ... [R=301,L] -> "¡ALTO! El usuario está en el sitio inseguro. Mándalo al sitio
seguro (HTTPS) para siempre (301) y deja de leer instrucciones (L)." Si no pusieras la L, el
servidor seguiría leyendo las líneas de abajo, y podría intentar buscar el archivo o aplicar
otras reglas antes de expulsar al usuario hacia el HTTPS, lo que podría causar errores o
comportamientos extraños.

¡ENHORABUENA!
Has securizado la infraestructura. Ahora el tráfico viaja cifrado y los datos de los usuarios están a
salvo de miradas indiscretas.

Servicios en red – 2º CFGM SMR – IES Ana Luisa Benítez - P á g i n a 7 | 10

ANEXO: FUNDAMENTOS TEÓRICOS
¿Cómo funciona realmente HTTPS?
Para entender lo que acabamos de configurar, debemos mirar "bajo el capó". HTTPS no es magia; es
una combinación de Matemáticas (Cifrado) y Confianza (Certificados).
1. Los tres pilares de HTTPS
Cuando ves el candado en el navegador, están sucediendo tres cosas vitales para la seguridad:
1. Cifrado: Nadie puede leer los datos en tránsito (ni el ISP, ni un hacker en la red Wi-Fi).
2. Integridad: Nadie ha modificado los datos por el camino (no han inyectado virus ni
cambiado el contenido).
3. Autenticación: Estás hablando con quien crees que estás hablando (el servidor es realmente
quien dice ser y no un impostor).
2. Las Llaves: Cifrado Asimétrico vs. Simétrico
HTTPS utiliza dos tipos de cifrado en diferentes momentos de la conexión para ser seguro y rápido
a la vez.
A. Cifrado Asimétrico (El par de claves)

Shutterstock
Imagina un sistema de buzón de correos:
• Clave Pública (El Buzón): Cualquiera puede meter una carta en el buzón (cifrar). Es pública
y el servidor se la entrega a cualquier visitante.
• Clave Privada (La Llave del Buzón): Solo el dueño del buzón (el servidor) tiene la llave
para abrirlo y sacar la carta (descifrar). Esta nunca se comparte.

Servicios en red – 2º CFGM SMR – IES Ana Luisa Benítez - P á g i n a 8 | 10

En HTTPS: El servidor guarda celosamente la clave privada. El navegador usa la clave pública del
servidor para enviarle el primer mensaje secreto.
B. Cifrado Simétrico (La llave maestra temporal)
Es como tener una llave idéntica para ambas personas. Es mucho más rápido computacionalmente
que el asimétrico, pero tiene un problema logístico: ¿Cómo nos pasamos la llave sin que nadie la vea
por el camino?
La Solución Híbrida: HTTPS usa el cifrado asimétrico (lento y seguro) solo al principio para
intercambiar la clave simétrica. Una vez que ambos tienen la clave simétrica, la usan para toda la
navegación (rápido).
3. El Certificado Digital y la Autoridad de Certificación (CA)
Tener claves de cifrado no es suficiente. ¿Cómo sé que la Clave Pública que recibí es realmente de
[Link] y no de un atacante que se hace pasar por él?
Aquí entra el Certificado Digital. Piensa en él como el DNI o Pasaporte de una página web.
Contiene:
• El nombre del dominio (ej. [Link]).
• La Clave Pública del sitio.
• La fecha de caducidad.
• La firma de una Autoridad de Certificación (CA).
¿Qué es la CA (Certificate Authority)?
Es una entidad en la que todos confiamos (similar a la Policía o la Fábrica Nacional de Moneda y
Timbre para los DNIs físicos).
• Tu navegador (Chrome, Firefox, Edge) viene con una lista preinstalada de CAs confiables.
• Si el certificado del servidor está firmado por una de estas CAs, el navegador muestra el
candado cerrado.
• Si el certificado es "Autofirmado" (como el que hemos creado en esta actividad), el
navegador te avisa de peligro porque nadie avala esa identidad. Es como si te fabricas tu
propio DNI con cartulina: puede que los datos sean reales, pero nadie garantiza que seas tú.
4. El proceso paso a paso: "The SSL Handshake"
Todo esto ocurre en milisegundos cada vez que entras a una web segura. Se llama "Apretón de
Manos" (Handshake):
1. Client Hello: El navegador saluda al servidor y le dice qué versiones de cifrado soporta.
2. Server Hello + Certificado: El servidor responde y envía su Certificado Digital (que incluye
su Clave Pública).

Servicios en red – 2º CFGM SMR – IES Ana Luisa Benítez - P á g i n a 9 | 10

 3. Verificación: El navegador revisa el certificado: "¿Ha caducado? ¿Está firmado por una CA
fiable?". Si todo está bien, continúa. Si no, muestra la alerta roja.
4. Intercambio de Claves (Key Exchange):
o El navegador genera una clave temporal aleatoria (Clave de Sesión).
o El navegador cifra esa clave usando la Clave Pública del servidor (que venía en el
certificado).
o Envía el paquete cifrado al servidor.
5. Descifrado: El servidor recibe el paquete y usa su Clave Privada para descifrarlo y obtener
la Clave de Sesión.
6. Túnel Seguro: ¡Ahora ambos tienen la misma Clave de Sesión! A partir de aquí, abandonan
las claves asimétricas y usan esta clave rápida para cifrar todo el contenido de la web (HTML,
imágenes, contraseñas).

Resumen Rápido (Cheat Sheet)

Concepto Función Ubicación

Clave Privada Descifrar mensajes entrantes. Servidor (Nunca sale de ahí).

Clave Pública Cifrar mensajes para el servidor. Pública (Viaja en el certificado).

Certificado Garantiza la identidad (DNI). Servidor -> Navegador.

HTTPS Protocolo seguro. Puerto 443.

Servicios en red – 2º CFGM SMR – IES Ana Luisa Benítez - P á g i n a 10 | 10