Decodificador de CSR (Solicitud de Firma de Certificado)

Pega una CSR (Solicitud de Firma de Certificado) en formato PEM para revisar antes de enviarla a la CA el CN, el SAN, el nombre de la organización y el algoritmo de clave pública que vas a solicitar. Herramienta gratuita que te ayuda a detectar errores de escritura antes de que sea demasiado tarde.

Qué es el Decodificador de CSR

El Decodificador de CSR es una herramienta gratuita que, al pegar una CSR (Certificate Signing Request, Solicitud de Firma de Certificado) en formato PEM, muestra de un vistazo el Sujeto que vas a solicitar (CN, nombre de la organización, etc.), el SAN (Subject Alternative Name), el algoritmo de clave pública y el algoritmo de firma. Así puedes confirmar en el momento, antes de enviar la solicitud a una CA (autoridad certificadora), que el contenido introducido es exactamente el que querías.

A diferencia de la herramienta hermana "Decodificador de Certificados SSL (X.509)", que analiza certificados ya emitidos, esta herramienta trabaja con la propia CSR, en la etapa previa a la revisión y emisión por parte de la CA. Resulta especialmente útil como comprobación final cuando el certificado todavía no se ha emitido, o justo antes de volver a generar una clave privada, momentos en los que un error pasa fácilmente desapercibido hasta que ya es tarde para corregirlo sin coste.

Cómo usar el Decodificador de CSR

Pega tu CSR en formato PEM Pega directamente en el cuadro de texto el contenido que empieza con "-----BEGIN CERTIFICATE REQUEST-----".
También admite varias CSR a la vez Si pegas varias CSR seguidas, cada bloque se detecta automáticamente por separado.
Haz clic en "Analizar" Comprueba el número de CSR detectadas y luego pulsa el botón para analizarlas en el servidor.
Revisa los resultados Se muestran en pantalla el Sujeto, el SAN, el algoritmo de clave pública y demás campos de cada CSR.

Consejos para aprovecharla mejor

Antes de enviar la CSR, comprueba siempre que tanto el CN (nombre común) como el SAN incluyen absolutamente todos los nombres de host que quieres que cubra el certificado. Olvidar una entrada en el SAN suele obligar a repetir todo el proceso de emisión.
Aprovecha este momento para verificar que el algoritmo de clave pública no sea RSA de menos de 2048 bits ni una curva EC en desuso, ya que eso puede provocar que la CA rechace la solicitud durante su revisión.
Antes de reutilizar la misma CSR en varios servidores, confirma de nuevo que el nombre de la organización y los dominios del Sujeto y del SAN coinciden realmente con lo que vas a solicitar en cada caso.
Ten en cuenta que esta herramienta solo muestra lo que se solicita en la CSR: qué SAN acaba emitiendo realmente la CA puede variar según el resultado de su propia revisión.

Cuándo usar esta herramienta

Comprobación final antes de enviarla a la CA

Antes de comprar un certificado SSL de pago, verifica que el CN y el SAN introducidos al generar la CSR son correctos.

Validar el procedimiento de generación de CSR interno

Permite comprobar visualmente, incluso a quien no está familiarizado con la línea de comandos, si una CSR generada con openssl req u otra herramienta contiene realmente lo esperado.

Revisar el contenido de una CSR emitida hace tiempo

Vuelve a comprobar de forma segura, sin manipular ninguna clave privada, el contenido de una CSR que conservas guardada como archivo.

Detectar omisiones de SAN en certificados multidominio

Antes de solicitar un certificado que cubra varios nombres de host a la vez, identifica si falta alguno en el SAN.

Glosario

CSR (Solicitud de Firma de Certificado): Siglas de Certificate Signing Request. Es el conjunto de datos que se entrega a una CA para solicitar la emisión de un certificado, y que reúne la clave pública junto con la información de la solicitud (Sujeto, SAN, etc.).
CA (autoridad certificadora): Siglas de Certificate Authority. Es la entidad externa que revisa el contenido de la CSR y emite el certificado SSL/TLS real.
CN (nombre común): Uno de los campos del Sujeto que identifica el nombre de host o servicio principal del certificado. Antiguamente los navegadores solo comprobaban el CN, pero hoy en día se da prioridad al SAN.
SAN (Nombre Alternativo del Sujeto): Campo de extensión que enumera nombres de host o direcciones IP adicionales para los que el certificado será válido. En la fase de CSR se registra dentro de las llamadas "Requested Extensions" (extensiones solicitadas).
Requested Extensions (extensiones solicitadas): Atributo mediante el cual quien solicita la CSR pide que se incluyan determinadas extensiones en el momento de la emisión. El SAN se incluye aquí, aunque la CA no siempre lo traslada al certificado tal cual.
Algoritmo de clave pública: Método con el que se generó la clave pública incluida en la CSR. Los más habituales son RSA y EC (criptografía de curva elíptica), y la solidez depende de la longitud de la clave o de la curva elegida.

Preguntas frecuentes

Se envía al servidor una sola vez para poder analizarla, pero no se almacena ni se registra de forma permanente. La CSR no contiene la clave privada, pero aun así evita pegar información de la solicitud que prefieras mantener en privado.

No. Esta herramienta solo admite CSR que empiecen con "-----BEGIN CERTIFICATE REQUEST-----". Nunca pegues una clave privada en ninguna herramienta en línea, sea cual sea.

Las causas más habituales son que falten las líneas BEGIN/END, que el contenido en Base64 esté dañado, o que se haya pegado un certificado o una clave privada en lugar de una CSR real.

El Decodificador de Certificados X.509 analiza certificados ya emitidos por una CA, mientras que esta herramienta analiza la CSR, es decir, el contenido de la solicitud en la etapa previa al envío a la CA. Como la CSR no incluye periodo de validez ni huellas digitales, esos datos no se muestran aquí.

En la mayoría de los casos sí, pero la decisión final depende de la revisión de la CA. Algunas CA pueden ignorar el SAN de la CSR y dar prioridad al que se indique en el formulario web al realizar el pedido.

A propósito — Por qué una CSR incluye su propia "firma"

Si observas con atención el contenido de una CSR, verás que, después del Sujeto y de la información de la clave pública, se guardan también un algoritmo de firma y un valor de firma. A primera vista puede parecer extraño: ¿por qué un documento que le pide a una CA "certifícame, por favor" incluye una firma del propio solicitante? La respuesta está en un concepto llamado "Proof of Possession" (prueba de posesión de la clave privada). Al firmar toda la CSR (el Sujeto, la clave pública, etc.) con la clave privada que forma pareja con la clave pública indicada en la propia solicitud, el solicitante demuestra ante la CA que realmente posee la clave privada correspondiente a esa clave pública. Si alguien intentara crear una CSR incluyendo la clave pública de otra persona sin tener su clave privada, no podría generar una firma válida, de modo que este mecanismo impide las solicitudes fraudulentas por suplantación.

El mecanismo de la CSR se definió en 1986 como PKCS#10, dentro de la familia de estándares de criptografía de clave pública PKCS (Public-Key Cryptography Standards) desarrollada por RSA. Hoy en día la IETF lo ha redefinido como RFC 2986, pero en la práctica el nombre PKCS#10 sigue siendo ampliamente utilizado. Dentro del mundo de los certificados TLS pasa bastante desapercibido, pero es la pieza que da inicio a todo el flujo de emisión de certificados: sin CSR no hay certificado que emitir.

La incorporación del SAN dentro de las Requested Extensions de la CSR no es, en realidad, una práctica tan antigua como cabría pensar. El estándar original de la CSR (PKCS#10) solo contemplaba de forma explícita el Sujeto y el CN, y a medida que se popularizaron los certificados multidominio y los certificados comodín, cada CA fue adoptando por su cuenta distintas formas de aceptar el SAN. Actualmente, herramientas de referencia como openssl admiten de forma estándar un mecanismo llamado Extension Request, definido en la RFC 2985, para incluir el SAN dentro de la CSR, y esta herramienta lee precisamente el SAN desde esa ubicación estándar (el atributo extensionRequest dentro de los Attributes).

Ver todas las curiosidades