Desde el 15 de enero de 2026, Let’s Encrypt emite certificados TLS públicos directamente para direcciones IP. Ya no se requiere un nombre de dominio, por lo que una dirección del tipo https://IP_pública puede abrirse sin advertencia de certificado no confiable. Se admiten tanto IPv4 como IPv6.
La IP se registra en la extensión Subject Alternative Name del certificado como iPAddress. Ese formato está previsto por los requisitos del CA/Browser Forum. El navegador compara la dirección a la que se conectó el usuario con la IP en SAN. No es necesario registrar la IP como un nombre de dominio habitual en dNSName.
Los certificados de Let’s Encrypt para IP tienen una diferencia importante respecto a los certificados para dominios. Para ellos se requiere el perfil shortlived y la validez es de 160 horas, es decir, 6 días y 16 horas. Por eso no es viable instalar ese certificado manualmente y recordarse renovarlo cada pocos meses. Hay que configurar la renovación automática de inmediato.
Un certificado de Let’s Encrypt solo se puede obtener para una IP pública. Las direcciones10.0.0.0/8,172.16.0.0/12,192.168.0.0/16y otros rangos reservados no son aptos para un certificado públicamente confiable. Las normas del CA/Browser Forum prohíben expresamente a las autoridades de certificación emitir tales certificados. Para una red interna se necesita una autoridad de certificación propia o un certificado autofirmado.
Cómo obtener un certificado de Let’s Encrypt para IPv4 o IPv6 con Certbot
Para certificados IP hace falta un Certbot moderno. La opción --ip-address apareció en Certbot 5.3, y el soporte de IP en el modo webroot llegó en la versión 5.4. Por eso para la instrucción siguiente use Certbot 5.4 o posterior. La documentación actual permite indicar varias veces --ip-address para incluir varias IPv4 o IPv6 en un mismo certificado.
Primero, compruebe la versión:
certbot --version
Para la verificación por HTTP-01 el servidor debe ser accesible desde Internet por la misma IP que irá al certificado, y el puerto TCP 80 debe aceptar conexiones entrantes. Let’s Encrypt accede a http://IP/.well-known/acme-challenge/... y comprueba un archivo temporal. DNS para esa verificación no es necesario. HTTP-01 funciona también con direcciones IP, mientras que DNS-01 no se aplica para verificar IP. Como alternativa existe TLS-ALPN-01 en el puerto 443, pero el soporte de este método depende del cliente ACME.
Si Nginx, Apache u otro servidor web ya están funcionando, es más cómodo usar webroot. La secuencia es: IP pública asignada al servidor → puerto 80 abierto → el directorio del sitio accesible por HTTP → Certbot crea el archivo de verificación → Let’s Encrypt verifica la IP → Certbot guarda el certificado.
Primero ejecute la solicitud en el entorno de pruebas de Let’s Encrypt, sustituyendo la IP real y el directorio del sitio:
sudo certbot certonly --staging --preferred-profile shortlived --webroot --webroot-path /var/www/html --ip-address <PUBLIC_IPV4> --cert-name ip-cert
El certificado de prueba no es de confianza pública. Si la verificación fue correcta, repita el comando sin --staging:
sudo certbot certonly --preferred-profile shortlived --webroot --webroot-path /var/www/html --ip-address <PUBLIC_IPV4> --cert-name ip-cert
Para IPv6 el comando es el mismo. En --ip-address se pasa la dirección sin corchetes:
sudo certbot certonly --preferred-profile shortlived --webroot --webroot-path /var/www/html --ip-address <PUBLIC_IPV6> --cert-name ip-certSi el servidor es accesible simultáneamente por IPv4 e IPv6, ambas direcciones se pueden incluir en un único certificado:
sudo certbot certonly --preferred-profile shortlived --webroot --webroot-path /var/www/html --ip-address <PUBLIC_IPV4> --ip-address <PUBLIC_IPV6> --cert-name ip-certLet’s Encrypt debe verificar con éxito cada dirección indicada. Si IPv4 funciona pero IPv6 apunta a otro servidor o está bloqueada por un cortafuegos, la emisión del certificado con ambas direcciones fallará.
Cuando el servidor web aún no está en ejecución, se puede usar --standalone. Certbot levantará temporalmente un servidor HTTP para la verificación. En ese caso el puerto 80 debe estar libre y accesible desde Internet:
sudo certbot certonly --preferred-profile shortlived --standalone --ip-address <PUBLIC_IP> --cert-name ip-certCómo instalar el certificado IP en Nginx o Apache y configurar la renovación
Obtener el certificado y configurarlo automáticamente en el servidor web no es lo mismo. Certbot ya sabe obtener certificados IP, pero aún no puede instalarlos en Nginx o Apache. Los complementos nginx y apache no admiten direcciones IP. Por eso se obtiene el certificado mediante webroot, standalone o manual, y las rutas a los archivos se añaden en la configuración del servidor web manualmente.
Con --cert-name ip-cert Certbot guarda los archivos actuales en rutas estables /etc/letsencrypt/live/ip-cert/fullchain.pem y /etc/letsencrypt/live/ip-cert/privkey.pem. Para Nginx basta indicarlos en el bloque del servidor correspondiente:
server { listen 443 ssl; listen [::]:443 ssl; ssl_certificate /etc/letsencrypt/live/ip-cert/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/ip-cert/privkey.pem; location / { root /var/www/html; } }Tras editar, compruebe la configuración y recargue:
sudo nginx -t sudo systemctl reload nginxPara Apache se usan los mismos archivos:
<VirtualHost *:443> SSLEngine on SSLCertificateFile /etc/letsencrypt/live/ip-cert/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/ip-cert/privkey.pem </VirtualHost>
Tras la renovación el servidor web debe volver a leer el nuevo certificado. Dado que los complementos de servidor web de Certbot todavía no soportan certificados IP, hay que configurar --deploy-hook. El hook se ejecuta después de una renovación exitosa y notifica a Nginx o Apache que carguen los archivos actualizados desde el disco. Por ejemplo, para Nginx:
sudo certbot reconfigure --cert-name ip-cert --deploy-hook "systemctl reload nginx"
Para Apache, en lugar de la orden de recarga de Nginx indique systemctl reload apache2 o la orden equivalente de su distribución. Let’s Encrypt recomienda usar --deploy-hook precisamente porque los instaladores automáticos de servidores web aún no funcionan con certificados IP.
Compruebe si está instalado el temporizador del sistema para Certbot:
systemctl list-timers | grep certbotA continuación pruebe la renovación:
sudo certbot renew --dry-run
Debido al plazo de 160 horas, la tarea certbot renew debe ejecutarse con regularidad, no una vez por semana. Las instalaciones estándar de Certbot suelen crear automáticamente un temporizador del sistema o una tarea cron. Tras una renovación exitosa, --deploy-hook obligará al servidor a volver a cargar el certificado; de lo contrario aparecerán archivos nuevos en disco y Nginx o Apache seguirán sirviendo la copia antigua.
Cuándo no funcionará el certificado en una IP
Una dirección privada según RFC 1918 no puede obtener un certificado público. El problema también afecta al rango 100.64.0.0/10, que está reservado para CGNAT. Con CGNAT el IPv4 externo pertenece a la infraestructura del proveedor y normalmente no es posible dirigir conexiones entrantes hacia su servidor. Por eso Let’s Encrypt no podrá verificar el control de la dirección mediante HTTP-01.
Una IP pública dinámica técnicamente se puede certificar, pero en la práctica suele tener poco sentido. El certificado está ligado a la dirección exacta. Tras un cambio de IPv4, el certificado anterior no valida la nueva dirección, y el nuevo titular de la IP anterior podría recibir otra punta de red. Para servicios con direcciones cambiantes un nombre de dominio suele ser más conveniente.
Con IPv6 rige el mismo principio. El certificado se expide para una IPv6 concreta, no para todo el prefijo /64 asignado por el proveedor. No elija una IPv6 temporal que el sistema operativo cambie periódicamente por privacidad; el servidor necesita una dirección estable. El límite de Let’s Encrypt para certificados nuevos se cuenta no por cada IPv6 individual, sino por todo el /64.
Según los límites actuales, Let’s Encrypt permite hasta 50 certificados nuevos en siete días para una misma IPv4 o una misma red IPv6 /64. Las renovaciones habituales se reconocen por separado, y las renovaciones mediante ACME Renewal Information están exentas de límites. Por eso la corta validez del certificado IP por sí sola no significa que la renovación automática agote rápidamente la cuota.
Para una red doméstica, la interfaz del router, un laboratorio o un servidor con dirección 192.168.x.x es mejor elegir una autoridad de certificación propia o un certificado autofirmado y añadir el certificado raíz confiable en los dispositivos necesarios. Para un VPS público, API o equipo sin un nombre de dominio conveniente, un certificado de Let’s Encrypt para IP ya puede ser una solución completa. Para un panel de administración con IP fija hay que tener en cuenta el riesgo adicional.
Let’s Encrypt envía todos los certificados emitidos a los registros públicos Certificate Transparency. La IP del SAN de ese certificado queda disponible para búsquedas y recolección automática, por lo que no puede considerarse oculta una interfaz administrativa solo porque no tenga dominio. Es mejor combinar HTTPS para la interfaz con VPN, cortafuegos, restricción de acceso por IP u otra protección.
El dominio sigue siendo más conveniente cuando el servidor puede cambiar de dirección, funciona tras un balanceador, tiene varias instancias o una red de entrega de contenido. El dominio mantiene un nombre constante del servicio independientemente de la IP que tenga detrás.
Preguntas y respuestas
¿Se puede obtener un certificado SSL para una IP sin dominio?
Sí. Desde el 15 de enero de 2026 Let’s Encrypt emite públicamente certificados TLS para IPv4 e IPv6 públicas. No se requiere un dominio para ese tipo de certificado.
¿Se puede obtener un certificado Let’s Encrypt para 192.168.1.1?
No. 192.168.1.1 pertenece al rango privado. Las autoridades de certificación públicas no pueden emitir certificados TLS confiables para IP reservadas. Para una red local hace falta una autoridad de certificación propia o un certificado autofirmado.
¿Funciona Let’s Encrypt con IPv6?
Sí. Se puede incluir una IPv6 pública en el certificado mediante la opción Certbot --ip-address. Let’s Encrypt debe poder conectarse exactamente a la dirección indicada para verificar el control.
¿Se pueden incluir IPv4 e IPv6 en un mismo certificado?
Sí. Certbot permite repetir --ip-address varias veces. Todas las direcciones aparecerán en el SAN de un mismo certificado, si la verificación de cada una concluye con éxito.
¿Es necesario el puerto 80 abierto?
Para HTTP-01 se necesita acceso al puerto 80 desde Internet. El protocolo ACME también permite verificar la IP mediante TLS-ALPN-01 en el puerto 443, si el cliente elegido soporta ese método.
¿Por qué el certificado IP de Let’s Encrypt dura solo unos días?
Para los certificados IP Let’s Encrypt exige un perfil de corta vida. El certificado tiene una validez de 160 horas. El periodo corto reduce las consecuencias de la fuga de la clave privada, pero exige una renovación totalmente automatizada.
¿Funcionará el certificado en una IP con CGNAT?
Por lo general no. Con CGNAT el dispositivo no controla directamente la IP pública externa y las conexiones entrantes al puerto necesario no llegan al servidor. Para la verificación Let’s Encrypt necesita una dirección públicamente enrutable cuyo control pueda confirmar el servidor.
¿Qué es mejor: certificado en IP o en dominio?
Para una IP pública fija ambos enfoques proporcionan HTTPS confiable. El dominio es más conveniente ante cambios de dirección, balanceo o migración del servicio. El certificado por IP es útil cuando el servicio debe abrirse directamente por una dirección pública estable.
Configure certificados y servicios de red solo en servidores e IP que esté autorizado a gestionar. Al publicar servicios en Internet cumpla la legislación de la Federación de Rusia y no exponga interfaces administrativas sin protección adicional.
