Una Certificate Signing Request (CSR) es el paso previo obligatorio para obtener un certificado TLS de cualquier autoridad certificadora, ya sea Let's Encrypt, DigiCert o una CA interna corporativa. Este generador de CSR construye la solicitud junto con su clave privada directamente en el navegador usando Web Crypto API, sin que la clave privada salga nunca de tu equipo, y explica cada campo del Distinguished Name para que la CA no rechace la solicitud por datos incoherentes.
Qué contiene una CSR y por qué la clave privada no debe compartirse
Una CSR incluye la clave pública, el Distinguished Name (organización, país, dominio) y una firma generada con la clave privada correspondiente, todo codificado en PKCS#10 y presentado en formato PEM (bloques Base64 delimitados por -----BEGIN CERTIFICATE REQUEST-----). La clave privada nunca forma parte de la CSR ni debe enviarse a la CA: solo se usa localmente para firmar la solicitud, demostrando posesión de esa clave sin revelarla.
Los campos del Distinguished Name explicados
El Common Name (CN) debe ser exactamente el dominio que protegerá el certificado, como www.ejemplo.com; para SAN múltiples (varios dominios en un mismo certificado) se añaden como Subject Alternative Names. Organization (O) es la razón social legal, Organizational Unit (OU) el departamento (cada vez menos usado y descontinuado en certificados EV), Country (C) el código ISO de dos letras, y Locality (L) y State (ST) la ciudad y provincia. Un CN que no coincida exactamente con el dominio real hace que el navegador muestre advertencias de certificado no válido.
RSA vs ECDSA: qué algoritmo elegir para la clave
RSA de 2048 bits sigue siendo el estándar más compatible y aceptado universalmente, pero ECDSA con curva P-256 ofrece seguridad equivalente con claves y firmas mucho más pequeñas, lo que reduce la latencia del handshake TLS. Para servicios públicos de alto tráfico, ECDSA P-256 es la opción recomendada por el CA/Browser Forum en 2024; para compatibilidad con sistemas legacy o dispositivos embebidos antiguos, RSA 2048 sigue siendo más seguro apostar.
SAN (Subject Alternative Name): certificados multi-dominio
Desde que los navegadores dejaron de confiar en el CN por sí solo (RFC 6125 y el abandono posterior por parte de Chrome/Firefox), el campo SAN es obligatorio para que un certificado sea válido, incluso si protege un único dominio. Un certificado wildcard usa *.ejemplo.com como SAN para cubrir todos los subdominios de primer nivel, pero no cubre el dominio raíz ni subdominios de segundo nivel como api.staging.ejemplo.com, que necesitan su propia entrada SAN o un wildcard adicional.
Del CSR al certificado: qué hace la autoridad certificadora
La CA recibe la CSR, verifica la firma con la clave pública incluida (confirmando que quien la generó posee la clave privada), valida el control sobre el dominio (por DNS TXT, archivo HTTP o email, según el método de validación DV/OV/EV) y emite el certificado firmado con su propia clave. Para autoridades ACME como Let's Encrypt, este proceso está automatizado con certbot u otros clientes ACME, pero el CSR manual sigue siendo necesario para CAs comerciales tradicionales o certificados internos con OpenSSL.
Errores frecuentes que provocan el rechazo de una CSR
Los motivos más comunes de rechazo son: CN con protocolo incluido (https://ejemplo.com en lugar de ejemplo.com), país con más de dos letras, organización que no coincide con el registro mercantil en certificados OV/EV, y clave RSA por debajo de 2048 bits, ya no aceptada por ninguna CA pública desde 2014. Verifica siempre el contenido de la CSR con openssl req -text -noout -in mi.csr antes de enviarla, para detectar errores antes de que la CA tarde días en rechazarla.
Casos de uso comunes
- Generar la CSR y clave privada para solicitar un certificado a Let's Encrypt o una CA comercial.
- Renovar un certificado TLS de un servidor interno sin exponer la clave privada a terceros.
- Crear un certificado wildcard para cubrir todos los subdominios de una aplicación SaaS.
- Preparar CSR para múltiples dominios de una misma organización con SAN.
- Verificar el Distinguished Name antes de enviarlo a un departamento de compras de certificados EV.
Buenas prácticas
- Guarda la clave privada de forma cifrada y nunca la envíes por email ni la subas a un repositorio.
- Usa ECDSA P-256 para servicios públicos modernos; RSA 2048 solo si necesitas compatibilidad legacy.
- Incluye todos los SAN necesarios desde el principio: añadir dominios después requiere una nueva CSR.
- Verifica el CSR con openssl req -text -noout antes de enviarlo a la autoridad certificadora.
- No reutilices la misma clave privada entre distintos certificados o entornos.