Conquistando Lugares

1. El problema: Error «Web no segura» (Certificado SSL)

🚨 El susto y la trampa del acceso SSH

Al entrar hoy a mi web (conquistandolugares.es)… ¡PANTALLAZO ROJO AL CANTO! 🛑 El navegador me recibió advirtiendo que la web no era segura.

Esto ocurre porque el certificado SSL de la página había caducado. Cuando el certificado vence, la conexión deja de ser cifrada (https://) y el navegador bloquea el paso automáticamente mostrando esta alerta para evitar que los usuarios naveguen por un sitio no protegido.

La solución rápida era conectar por SSH desde la terminal de mi ordenador para renovar el SSL en 2 minutos, pero el servidor me soltó un portazo en la cara.

💡 Conceptos clave en 1 minuto

Certificado SSL: Cifra la conexión entre el navegador y el servidor (https:// y el icono del candado). Si caduca, salta la pantalla roja de «Sitio no seguro» 🛑.
Conexión SSH: Es el acceso remoto seguro por línea de comandos para controlar tu servidor desde la terminal de tu propio ordenador (PowerShell en Windows o Terminal en Mac) 💻.

🔍 La prueba para saber si tienes exactamente este problema

Abre tu terminal y prueba a conectarte escribiendo:

ssh root@conquistandolugares.es

*(Nota: recuerda cambiar conquistandolugares.es por la IP pública o el dominio de tu propio servidor)*.

Si el sistema te rechaza y te devuelve este mensaje de error, ¡bingo! Tienes el acceso bloqueado y debes seguir leyendo este tutorial:

Connection closed by 212.227.229.115 port 22

💡 Nota rápida: Si a ti sí te funciona la conexión SSH y consigues entrar a la primera, ¡te puedes saltar este capítulo! Ve directo a la sección donde renovamos el certificado SSL.

🤯 La pesadilla de la consola web

Al no tener acceso por SSH, no me quedó otra que recurrir a la consola web KVM del panel de Piensa Solutions.

Aquí te dejo cómo acceder a la consola el servidor desde la web de Piensa Solutions 🎬👇:

Vídeo explicativo: Solucionando el acceso SSH y la consola web en Piensa Solutions.

Y ahí empezó la fiesta:

❌ Sin portapapeles: No permitía copiar ni pegar nada. ¡Había que teclear todo a mano!
👻 Teclado desconfigurado: La consola forzó la distribución en inglés (US), cambiando de sitio comillas ("), barras (/) y puntos y comas (;).

2. ¿Cómo soluciono esto?

🛠️ Paso 1: Recuperar el acceso SSH desde la consola web

Para no seguir sufriendo con la consola web de Piensa Solutions (sin portapapeles y peleando con el teclado desconfigurado), el objetivo es forzar al servidor a aceptar nuestra conexión SSH directa con contraseña desde la terminal de nuestro ordenador.

Para evitar errores de sintaxis con el teclado en inglés, escribimos estas órdenes en la consola web de una en una y sin comillas dobles:

Permitir el acceso al usuario root:

echo PermitRootLogin yes >> /etc/ssh/sshd_config

Habilitar la autenticación por contraseña:

echo PasswordAuthentication yes >> /etc/ssh/sshd_config

Reiniciar el servicio SSH para aplicar los cambios:
```
systemctl restart sshd
```

💻 Paso 2: Probar la conexión SSH en paralelo desde tu terminal

⚠️ Consejo importante: No cierres la consola web de Piensa Solutions todavía. Mantén la ventana abierta a un lado y abre en paralelo la PowerShell de tu ordenador (o la Terminal en Mac).

Prueba a conectarte introduciendo tus datos:

ssh root@conquistandolugares.es

*(Nota: Recuerda cambiar conquistandolugares.es por la IP pública o el dominio de tu servidor).*

Escribe tu contraseña de root. En cuanto el servidor te devuelva el mensaje de bienvenida, sabrás que estás dentro y con capacidad nativa de copiar y pegar con el clic derecho 🥳:

Last login: Thu Aug 13 09:07:56 2026
This server is powered by Plesk.
[root@server-wp-conquistando-lugares ~]#

🔄 Paso 3: La batalla para renovar el SSL (Plesk vs Certbot)

Una vez conectados cómodamente desde nuestra propia terminal, este fue el recorrido real para renovar el certificado:

1. El intento por Plesk CLI (y el fallo de licencia)

Intentamos emitir el certificado usando la extensión propia de Plesk:

plesk bin extension --exec letsencrypt cli.php -d conquistandolugares.es -d www.conquistandolugares.es -m tu-email@gmail.com

❌ El problema: Plesk devolvió un error indicando que la licencia estaba caducada (The license key is invalid). Como no queríamos pagar los 5 €/mes de Plesk, pasamos a instalar Certbot (la herramienta oficial y gratuita).

2. El fallo de repositorios YUM de CentOS 7

Al intentar instalar Certbot con yum install -y certbot python2-certbot-apache, la descarga falló por un repositorio antiguo y desactualizado de TuxCare (centos7-els).

Desactivamos el repositorio rebelde y limpiamos la caché:

yum-config-manager --disable centos7-els

Lanzamos de nuevo la instalación… ¡y completó con éxito! (Complete!) 🎉

3. Emisión del certificado por Webroot

Cuando intentamos generar el certificado automáticamente con el plugin de Apache (certbot --apache), el sistema nos dio este fallo:

Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain.

❓ ¿Por qué ocurrió este fallo de Apache? Plesk gestiona los servidores web de forma personalizada. En lugar de guardar las configuraciones de los dominios en las rutas estándar de Apache, utiliza su propia estructura de archivos y un reverse proxy con Nginx por delante. Como Certbot no encuentra el archivo habitual de la web en la carpeta estándar de Apache, el plugin --apache se desorienta y falla.

💡 La solución: Validación por Webroot Para solucionar esto sin tocar la configuración de Apache, utilizamos la modalidad --webroot. Este método coloca un archivo temporal en la carpeta pública de la web (httpdocs) para que Let’s Encrypt compruebe que el dominio es tuyo.

Ejecutamos el comando especificando la ruta pública real de la web en Plesk:

certbot certonly --webroot -w /var/www/vhosts/conquistandolugares.es/httpdocs -d conquistandolugares.es -d www.conquistandolugares.es --non-interactive --agree-tos -m tu-email@gmail.com

⚠️ Nota muy importante: Recuerda cambiar conquistandolugares.es por tu propio dominio, y sustituir tu-email@gmail.com por tu correo electrónico real (donde te llegarán las notificaciones de renovación de Let’s Encrypt).

¡Certbot validó el dominio al instante y emitió las claves con éxito! 📜🎉

4. Importar y activar el certificado en Plesk

Para que el servidor web reconozca el nuevo certificado generado por Certbot, realizamos dos pasos desde la consola:

Importar las claves a la base de datos de Plesk:

plesk bin certificate -c "Certificado_Certbot" -domain conquistandolugares.es -key-file /etc/letsencrypt/live/conquistandolugares.es/privkey.pem -cert-file /etc/letsencrypt/live/conquistandolugares.es/cert.pem -cacert-file /etc/letsencrypt/live/conquistandolugares.es/chain.pem

Asignar el certificado a la página web:

plesk bin site -u conquistandolugares.es -certificate-name "Certificado_Certbot" -ssl true

El servidor nos devolvió la confirmación definitiva:
SUCCESS: Update of domain 'conquistandolugares.es' completed.

🎉 Paso 4: Comprobación final

Ejecutamos el comando de verificación en el servidor:

sudo certbot certificates

Confirmamos que el certificado está activo y con 89 días de validez restante (VALID: 89 days). Entramos a https://conquistandolugares.es desde el navegador y comprobamos que el candado de conexión segura vuelve a estar activo y la web carga perfectamente sin alertas rojas.

3. Ya está funcionando

🎯 Resultado y comprobaciones finales

¡Misión cumplida! La web conquistandolugares.es vuelve a estar 100% online, segura y accesible para todo el mundo 🔒.

🟢 Candado seguro en el navegador: La alerta roja ha desaparecido por completo y la conexión vuelve a ser cifrada con HTTPS.
📜 Certificado renovado: Con sudo certbot certificates confirmamos que el certificado de Let’s Encrypt está activo y funcionando.
💻 Acceso SSH restaurado: Conexión directa y fluida desde la terminal de nuestro ordenador, sin volver a tocar la consola web del hosting.

💡 Reflexión final y recomendación

gestionar un servidor VPS directamente por consola es totalmente viable apoyándote en una IA como Gemini 🤖.

Recomiendo encarecidamente afrontar estos problemas con el apoyo de una IA: le puedes pegar directamente los mensajes de error reales que te devuelve la terminal y te da de vuelta el código o comando exacto que debes ejecutar. De esta forma, evitas cometer faltas ortográficas o errores de sintaxis en las órdenes.

Seguramente a un administrador de sistemas con experiencia todo este proceso le hubiera tomado apenas 20 minutos. A mí, siendo la primera vez que me tocaba lidiar con este tipo de configuraciones y bloqueos, (sobretodo la parte de la consola web del servidor que no me dejaba copiar y pegar) me ha llevado unos 2 horas, ¡pero el aprendizaje ha merecido totalmente la pena!

💬 ¡Déjame tu comentario!
¿Te ha servido esta guía para solucionar el acceso SSH o renovar tu certificado SSL? Si has intentado seguir los pasos, déjame en los comentarios si te ha funcionado o qué errores te han ido apareciendo para que podamos resolverlos juntos. 👇

📊 Ficha técnica de la guía:
📖 Tiempo de lectura estimado: ~7 minutos.
⏱️ Tiempo de resolución: ~2 horas (o ~20 min para un usuario experto).
🤯 Nivel de dificultad: Bajo (apoyándote en Gemini).

Blog

Error «Web no segura» (Certificado SSL)