Certificado SSL

Este es un compendio general de cómo obtener un certificado SSL para un subdominio de Helpcom y conectar ese certificado en un servidor. Está basado en las herramientas certbot y acme.sh y sus documentaciones oficiales:

• https://github.com/acmesh-official/acme.sh#2-just-issue-a-cert
• https://certbot.eff.org/instructions?ws=apache&os=pip
• https://www.linuxparty.es/57-seguridad/9978-generar-un-certificado-ssl-tls-gratis-y-autofirmado-con-certbot

Requisitos Generales:

• Acceso a la configuración de Zone Editor del dominio de helpcom.cl (a fecha de 2025, Benzahosting).
• Servidor Linux Debian o compatible que cumpla con linux-servidor.
• Servicio de servidor web Apache (apache2) o Nginx (nginx) desde la paquetería.
• El servidor debe estar sirviendo contenido alcanzable desde internet con un subdominio.
• Certbot ó acme.ssh (uno de los dos basta) instalados con sus instrucciones oficiales.

Para instalar Certbot en Debian 11 en adelante se puede hacer sin problemas desde el gestor de paquetes:

apt install certbot

Para instalar acme.sh se puede clonar el repositorio oficial.

git clone https://github.com/acmesh-official/acme.sh.git

Para configurar el servidor web correspondiente (Apache o Nginx) se recomienda seguir las recomendaciones oficiales. En particular, para Certbot se recomienda crear un depósito de certificados bajo el árbol de directorios del servicio web (ej.: /etc/apache2/certbot) y para configurar acme.sh se recomienda habilitar el modo Stateless para simplificar la fase de challenge al pedir un certificado singular de subdominio y crear también su ruta de certificados correspondiente (ej.: /etc/apache2/certacme).

Tomar nota que los repositorios de devops-stag y devops-erebor vienen con ejemplos de archivos de configuración para ayudar a configurar acme-challenge y este tutorial asume que esos archivos han sido instalados.

En este caso tenemos un proyecto web en HTTP que es alcanzable bajo miproyecto.helpcom.cl y que corre en uno de los recursos de IPs públicas a las que tiene acceso Helpcom (ej.: Erebor).

Requisitos:

• el zone editor de Helpcom debe tener un registro A con un nombre que apunte al servidor. En este caso, por ejemplo, servidor2.helpcom.cl.
• Los puertos 80 y 443 del servidor servidor2 deben estar abiertos y conectados al servidor Apache/Nginx.

El servicio web debe tener habilitado un archivo de configuración de acme-challenge, basado en el correspondiente en devops-stag o similar. Este archivo suele ser:

• Apache: /etc/apache2/conf-enabled/acme-challenge.conf
• Nginx: /etc/nginx/conf.d/acme-challenge.conf

Se asume que el VirtualHost tiene una estructura similar a la siguiente en un archivo de virtualhost:

Apache - sites-available/miproyecto.helpcom.cl.conf (el cual debe estar activado con a2ensite):

<VirtualHost *:80>
	ServerName miproyecto.helpcom.cl
	UseCanonicalName Off

	ErrorLog ${APACHE_LOG_DIR}/miproyecto.log
	# debería estar cubierto por acme-challenge.conf
	# Alias /.well-known/acme-challenge  /var/www/.acme

	# alojamiento directo...
	# DocumentRoot /var/www/miproyecto.helpcom.cl/public
	# ...o proxeado 
	ProxyPreserveHost On
	# etc...
</VirtualHost>

Nginx - sites-available/miproyecto.helpcom.cl.conf - pendiente

Con Certbot, asumiendo que la configuración esté correcta, basta con invocar Certbot y el programa mismo ofrecerá la opción de modificar el archivo de VirtualHost correspondiente en vivo:

# Apache
certbot certonly --apache -d miproyecto.helpcom.cl
# Nginx
certbot certonly --nginx -d miproyecto.helpcom.cl

Si todo sale correctamente, Certbot generará una familia de certificados en /etc/letsencrypt/live.d para el dominio deseado, y generará un nuevo archivo de configuración para el servidor web con la configuración HTTPS, por ejemplo en este caso /etc/apache2/sites-available/miproyecto.helpcom.cl-le.conf. Antes de reiniciar el servicio web para que tome la configuración, es necesario activar este nuevo sitio con a2ensite.

Con acme.sh, asumiendo que la configuración está correcta, basta con invocar acme.sh pasándole específicamnte la ruta de certificados del servicio que queremos (si no se ha configurado el programa para eso) y habilitando el modo Stateless.

acme.sh --issue -d miproyecto.helpcom.cl --stateless

Notar que la opción --stateless va al final.

Si todo sale correctamente, el sistema anunciará que se ha generado los archivos de certificado en el directorio deseado. Si no se configuró acme.sh para exportar los certificados al servicio web, se puede hacer directamente con la opción installcert:

# configurar como corresponda:
export CERTP=/etc/apache2/certacme
export CERTD=miproyecto.helpcom.cl
acme.sh --install-cert -d "CERTD" \
    --cert-file "${CERTP}/${CERTD}/cert.pem" \
    --key-file "${CERTP}/${CERTD/key.pem" \
    --fullchain-file "${CERTP}/${CERTD/fullchain.pem"

Una vez que los certificados estén copiados deben coincidir con las rutas en el archivo generado. Si no se configuró acme.sh para generar el archivo, o la configuración no corresponde, se puede crear manualmente con el ejemplo en VirtualHost-443.

Una vez que esté todo verificado, recargamos la configuración del servidor web:

# Apache
service apache2 reload
# Nginx
service nginx reload

Si se desea, una vez que el certificado está probado, forzar el sitio a usar HTTPS, se debe modificar la configuración del sitio de ese VirtualHost del puerto 80 para redirigir al puerto 443.

Para esto modificamos el fragmento del VirtualHost en el archivo de sitio HTTP (no HTTPS) por ejemplo sites-available/miproyecto.helpcom.cl.conf, como sigue:

Apache:

<VirtualHost *:80>
	ServerName miproyecto.helpcom.cl
	UseCanonicalName Off
	Redirect / https://miproyecto.helpcom.cl/
 
	# quitar DocumentRoot y directivas ProxyPass,
	# pero NO quitar otras directivas de configuración
...
 
</VirtualHost>

Nginx:

TBA

En este caso tenemos un proyecto que corre en HTTP que es alcanzable bajo uno de los subdominios wildcard de helpcom.cl que es proxeado por el servidor de Servicios: por ejemplo miproyecto.desarrollo.helpcom.cl (que es proxeado desde Servicios por la ruta ofis.helpcom.cl → *.desarrollo.helpcom.cl → miproyecto.desarrollo.helpcom.cl → servidor 235).

Requisitos:

• el zone editor de Helpcom debe tener el registro CNAME wildcard validado que apunta al multiplexor de Servicios; en este caso, *.desarrollo.helpcom.cl.
• El servidor de Servicios debe estar encendido y habilitado para que haga las funciones de multiplexor.
• Los puertos 80 y 443 del servidor de destino (en este caso, Desarrollo) deben estar abiertos y conectados al servidor Apache/Nginx.
• El multiplexor Apache/Nginx en el servidor de destino (ej.: Desarrollo) debe estar configurado para responder a desarrollo.helpcom.cl, al wildcard *.desarrollo.helpcom.cl, o ambos.

(TBA)

Acá se presenta un ejemplo de archivo de VirtualHost resultante, el cual puede ser usado como plantilla para configurar el acceso a los certificados manualmente si por alguna razón Certbot o acme.sh no pueden generar el archivo correctamente:

Ejemplo 1: Apache + Certbot

<VirtualHost *:443>
	ServerName miproyecto.helpcom.cl
	...
	Include /etc/letsencrypt/options-ssl-apache.conf
	SSLCertificateFile     /etc/letsencrypt/live/miproyecto.helpcom.cl/fullchain.pem
	SSLCertificateKeyFile  /etc/letsencrypt/live/miproyecto.helpcom.cl/privkey.pem
 
...
 
</VirtualHost>

Ejemplo 2: Nginx + acme.sh

server {
	listen 80;
	listen [::]:80;
	listen 443 ssl;
	listen [::]:443 ssl;
	server_name miproyecto.helpcom.cl;
 
	include include.d/acme.conf;
 
	ssl_certificate         /etc/nginx/certacme/miproyecto.helpcom.cl/fullchain.pem;
	ssl_certificate_key     /etc/nginx/certacme/miproyecto.helpcom.cl/key.pem;
	ssl_trusted_certificate /etc/nginx/certacme/miproyecto.helpcom.cl/fullchain.pem;
 
	ssl_stapling on
 
...
}