Tema

Herramientas populares

Decodificador de CSR

Pegue una solicitud de firma de certificado y lea cada campo que contiene: el sujeto, la clave, cada nombre alternativo y cada extensión. La página también comprueba la solicitud contra las reglas que aplica una CA pública, y le dice si su clave privada coincide con ella. Aquí también se decodifica un certificado SSL.

Decodificado en su navegador con Web Crypto · no se sube nada, no se guarda nada · Baseline Requirements del CA/Browser Forum v2.3.1

Se decodifica en su navegador. No se sube nada, no se guarda nada.
Suelte el archivo en cualquier parte de esta página PEM, DER, .csr, .cer, .crt, .pem, .req, .txt

Pruebe uno

Todo en esta página ocurre en su navegador. Abra el panel de red y observe: ninguna solicitud lleva sus datos.

¿Qué es un CSR?

Una solicitud de firma de certificado (CSR) es un pequeño archivo firmado que le pide un certificado a una autoridad de certificación. Lleva su clave pública, los nombres que quiere en el certificado y una firma hecha con su clave privada.

El formato es PKCS#10, definido en el RFC 2986. La parte que se firma contiene solo cuatro cosas: un número de versión, un nombre de sujeto, un SubjectPublicKeyInfo que lleva su clave pública y un conjunto de atributos. Todo eso lo firma después la clave privada que corresponde a la clave pública que lleva dentro, así que un CSR está autofirmado. Esa firma es la prueba de posesión: cualquiera puede leer su clave pública, pero solo quien tiene la clave privada puede firmar una solicitud que se verifique contra ella.

Su clave privada no está en el archivo, y nunca debería estarlo. Un CSR se puede enviar por correo, pegar en el formulario web de una CA y decodificar aquí sin ningún riesgo, que es justamente por lo que esta página puede hacer todo su trabajo en su navegador sin enviar nada a ningún lado.

Una solicitud, byte a byteRFC 2986 · PKCS#10

Todo el archivo

  • Envoltorio4 bytes
  • La parte que se firma469 bytes
  • Qué algoritmo de firma15 bytes
  • La firma en sí261 bytes

Dentro de la parte que se firma

  1. Versión3 bytesSiempre cero: la única versión que define el formato
  2. Nombre del sujeto108 bytesEl nombre distintivo que escribió en el formulario
  3. Su clave pública294 bytesAlgoritmo, tamaño y la clave: el único campo que una autoridad de certificación usa con certeza
  4. Atributos60 bytesPor donde viajan los nombres alternativos que pidió

Su clave privadafirma la parte de arribaPrueba de que usted tiene la clave privada correspondiente · La firma cubre solo esa parte, no el archivo completo

La solicitud de ejemplo que ofrece esta página, de 749 bytes. Cuatro cosas entran en la parte que se firma; la clave privada que corresponde a la clave pública de adentro firma exactamente esa parte, y lo que sale es el último 261 bytes.
Resultado del decodificador de CSR: sujeto, clave, nombres alternativos y hallazgos de reglas de la CAResultado del decodificador de CSR: sujeto, clave, nombres alternativos y hallazgos de reglas de la CAPegar o soltarUn CSR, un certificado o una clave pública: PEM, base64, un volcado hexadecimal o un archivo. Varios a la vez no hay problema.El veredictoQué hace una CA pública con esta solicitud: emitirla, cambiarla o rechazarla, con el motivo de cada caso.Los nombresCada nombre que cubriría el certificado, con el nombre común comprobado contra ellos.La clave y la firmaAlgoritmo, tamaño, curva y exponente, y si se sostiene la firma de la propia solicitud.Coincidencia de claveAgregue la clave privada o el certificado emitido para ver si pertenece a esta solicitud. Ninguno de los dos sale de su navegador.
Una solicitud de firma de certificado desarmada: el veredicto, los nombres que pide, la clave detrás de ella y un lugar para comparar su propia clave. Seleccione un número para ver qué muestra cada parte.

Cómo comprobar un CSR antes de enviarlo

Vale la pena comprobar tres cosas: que los nombres sean los que quiso poner, que la firma se verifique y que nada incumpla una regla que aplique su CA.

Pegue la solicitud arriba. La página lee el sujeto atributo por atributo, enumera cada nombre alternativo del sujeto, muestra el algoritmo y el tamaño de la clave, y luego comprueba la firma de la propia solicitud. Una solicitud cuya firma no se verifica se editó, se truncó o se dañó después de generarse: vuelva a generarla en lugar de enviarla.

Después vienen las reglas. Una autoridad de certificación aplica los Baseline Requirements del CA/Browser Forum, y una solicitud que incumple alguna de ellas se rechaza o se modifica sin aviso. Los hallazgos de esta página se marcan como Causa de rechazo cuando la CA no puede emitir lo que pidió, Corrección automática cuando lo emitirá pero eliminará o modificará un campo, y Nota cuando no hay nada mal pero algo merece una mirada.

Tres comprobaciones, en el orden en que se ejecutanCA/Browser Forum TLS BR 2.3.1
  1. Los nombresCada nombre que cubriría el certificado, y si el nombre común está entre ellos
  2. La firmaVerificada con la propia criptografía de su navegador
  3. Las reglas de la autoridad de certificaciónAplicadas una por una, cada una con el documento del que viene
  • EnvíeloNada en la solicitud incumple una regla
  • Se rechazaráEl archivo está bien formado; lo que pide no está permitido
  • Genérelo de nuevoUna firma que no se verifica significa que el archivo se editó, se truncó o se copió mal después de generarse
Las dos primeras comprobaciones son sobre el propio archivo, y la tercera es sobre lo que permite una autoridad de certificación. Una solicitud puede superar las dos primeras y aun así ser rechazada.

Qué hay en un CSR, y qué usa realmente su CA

De todo lo que hay en un CSR, una CA pública usa con certeza un solo campo: la clave pública. La mayor parte del resto lo valida por su cuenta, lo sobrescribe, o tiene prohibido copiarlo.

DigiCert lo dice sin rodeos en su propia documentación: «DigiCert usa la clave pública incluida en el CSR para crear su certificado de cliente. Todos los demás campos del CSR se ignoran». En un certificado OV o EV, la CA debe validar por sí misma la organización, la localidad y el país antes de incluirlos; lo que usted escribió no se da por bueno. Las fechas de vigencia nunca se toman de una solicitud: siguen el calendario de los Baseline Requirements.

Dos campos del sujeto no solo se ignoran, sino que están prohibidos. organizationalUnitName (OU) no debe aparecer en un certificado TLS público —según la votación SC047 del CA/Browser Forum, ningún certificado emitido desde el 1 de septiembre de 2022 puede incluirlo— y emailAddress no está permitido en absoluto en un certificado validado por dominio. El nombre común está permitido, pero se desaconseja, y si está presente debe repetir exactamente uno de los nombres alternativos del sujeto. Esa última regla es la razón por la que esta página marca un nombre común que falta en la lista SAN.

Qué hace una autoridad de certificación con cada campoCA/Browser Forum TLS BR 2.3.1
En su solicitudQué pasa con élPor qué
Clave públicaSubjectPublicKeyInfoSe usa tal como lo envióLo único que una autoridad de certificación toma de usted con certeza
Nombres alternativossubjectAltName2.5.29.17Se usa tal como lo envióLa CA confirma que usted controla cada nombre antes de anotar cualquiera de ellos
Nombre comúnCN2.5.4.3Validado, y luego lo escribe la CASe desaconseja; si está presente, debe repetir exactamente uno de los nombres alternativos
Organización, localidad, estadoO, L, ST2.5.4.10Validado, y luego lo escribe la CAEn un certificado validado por organización, estos vienen de los propios registros validados de la CA, no de lo que usted escribió
PaísC2.5.4.6Validado, y luego lo escribe la CAPuede aparecer, sea cual sea el nivel de validación
Unidad organizativaOU2.5.4.11No está permitido en absolutoProhibido en un certificado público desde el 1 de septiembre de 2022
Dirección de correoemailAddress1.2.840.113549.1.9.1No está permitido en absolutoNo está permitido en un certificado validado por dominio
Válido desde, válido hastanotBefore, notAfterNunca viene de la solicitudLo define el calendario que sigue la autoridad de certificación, nunca su solicitud

«DigiCert usa la clave pública incluida en el CSR para crear su certificado de cliente. Todos los demás campos del CSR se ignoran».

DigiCert, su propia documentación
Los campos por los que la gente se angustia, y lo que realmente vale cada uno. Su clave y sus nombres sobreviven; la unidad organizativa no puede aparecer en absoluto, ni una dirección de correo en un certificado validado por dominio, escriba lo que escriba; y las fechas nunca fueron suyas para definir.

Por qué una CA rechaza un CSR

Casi todo rechazo se reduce a un nombre que una CA no puede certificar, un comodín demasiado amplio, una dirección IP reservada, una clave demasiado pequeña, un hash de firma demasiado antiguo, o una solicitud cuya firma no se verifica.

Una autoridad de certificación no puede emitir para un nombre interno: uno que «no termina con un dominio de nivel superior registrado en la base de datos de la zona raíz de IANA». Eso atrapa a server.local, intranet, un nombre de una sola etiqueta sin ningún punto, y cualquier sufijo inventado. Las etiquetas deben ser letras, dígitos y guiones, así que se rechaza un guion bajo en un nombre de host, y un nombre no debe escribirse con un punto final. Un comodín solo puede reemplazar toda la etiqueta más a la izquierda, y nunca un sufijo público: *.example.com está bien, *.co.uk no. Puede aparecer una dirección IP, pero no una reservada: nada de 10.0.0.0/8, 192.168.0.0/16, 127.0.0.1 ni fc00::/7.

En cuanto a las claves, los Baseline Requirements son exactos: un módulo RSA de al menos 2048 bits, divisible exactamente entre 8, o un punto en P-256, P-384 o P-521, y «no se permiten otros algoritmos ni otros tamaños de clave». Una CA también debe rechazar una clave que se pueda factorizar, incluida una «que se pueda factorizar en 100 rondas con el método de factorización de Fermat»: esta página hace esa prueba sobre la clave de su solicitud. Y aunque el hash de la firma de un CSR no es el del certificado, Let's Encrypt dejó de aceptar autofirmas SHA-1 en 2022, así que una herramienta antigua que todavía firme con SHA-1 verá rechazada su solicitud.

Nombres que una autoridad de certificación no certificaráCA/Browser Forum TLS BR 2.3.1
  • server.local
    Un nombre internoNo termina en un dominio de nivel superior que exista en la zona raíz pública, así que nadie puede demostrar que es suyo
    Rechazado
  • intranet
    Una sola etiquetaUn nombre sin ningún punto cae bajo la misma definición
    Rechazado
  • my_host.example.com
    Un guion bajoUna etiqueta solo puede llevar letras, dígitos y guiones, y nada más
    Rechazado
  • *.co.uk
    Un comodín sobre todo un registroUn comodín puede ocupar el lugar de la etiqueta más a la izquierda, nunca el de un sufijo público
    Rechazado
  • 192.168.1.10
    Una dirección reservadaUna dirección pública se puede certificar; una de un rango privado o de propósito especial, nunca
    Rechazado
  • example.com.
    Un punto finalLa etiqueta raíz vacía no debe escribirse
    Rechazado
Seis nombres, cada uno incumple una regla distinta, y todos son un rechazo que podría haber previsto antes de enviar la solicitud.

¿Cómo sé si mi clave privada coincide con mi CSR?

Un archivo de clave privada ya lleva su propia clave pública, así que la comparación es entre dos claves públicas: no hace falta ningún secreto y no hay que enviar nada a ningún lado.

Abra Comparar una clave o un certificado arriba y agregue la clave junto a la solicitud. La página solo lee la mitad pública del archivo —entiende claves PKCS#8, PKCS#1 y SEC1—, la compara con la clave de la solicitud, y responde. No se sube nada, no se guarda nada, y la clave se borra al salir del campo. La misma comprobación funciona entre una solicitud y el certificado que devolvió la CA, con lo que se detecta «el certificado y la clave privada no coinciden» antes de que un servidor se niegue a arrancar.

Si prefiere no pegar una clave en ninguna página web, la misma respuesta son dos comandos en su propia máquina. openssl req -in request.csr -pubkey -noout imprime la clave pública de la solicitud, y openssl pkey -in private.key -pubout la imprime a partir de la clave: una salida idéntica significa que coinciden. La forma antigua -modulus solo funciona con claves RSA; -pubkey funciona con cualquier tipo de clave.

Dos archivos, una comparaciónRFC 2986 · OpenSSL manual
Su navegador
  • El archivo de clave privadaEl archivo que nunca debe enviar a ningún ladoSe lee su mitad pública
  • La solicitudEl archivo que envía a la autoridad de certificaciónYa lleva la clave pública

¿Son la misma clave?

  • CoincidenEl certificado que se devuelva se instalará con esta clave
  • No coincidenEste es el desajuste que informa un servidor web cuando se niega a arrancar

Nada cruza esta línea · La comparación funciona con la red desconectadaEn cualquier otro lugar

O hágalo en su propia máquinaopenssl req -in request.csr -pubkey -nooutopenssl pkey -in private.key -puboutUna salida idéntica significa que coinciden
Un archivo de clave privada ya lleva su propia clave pública, así que la pregunta se resuelve comparando dos claves públicas. Para eso no hace falta mover ningún secreto, y ninguno se mueve.

CSR, certificado, clave privada: ¿cuál es la diferencia?

La clave privada es el secreto. El CSR es una solicitud que demuestra que usted la tiene. El certificado es la respuesta firmada de la CA, y es el único de los tres que es público por diseño.

Los tres archivos suelen estar en la misma carpeta con nombres confusamente parecidos. Una clave privada empieza con -----BEGIN PRIVATE KEY----- o -----BEGIN RSA PRIVATE KEY----- y nunca debe enviarse a nadie, ni siquiera a una autoridad de certificación. Una solicitud de firma de certificado empieza con -----BEGIN CERTIFICATE REQUEST-----, la firma esa clave, y es segura de enviar. Un certificado empieza con -----BEGIN CERTIFICATE-----, lo firma la CA, y de todas formas se envía a cada visitante de su sitio.

Una vez emitido el certificado, la solicitud ya no sirve para nada más: no hace falta para instalar, renovar ni revocar nada. La clave es lo que debe conservar, y conservar a salvo. Pegue cualquiera de los tres arriba y esta página le dirá cuál es.

Tres archivos, una carpeta, nombres confusamente parecidosRFC 7468

  • La clave privadaSecreto

    Su primera línea-----BEGIN PRIVATE KEY-----También muy usadas-----BEGIN RSA PRIVATE KEY-----

    Firmado por
    Nada: es la que firma
    Quién puede verlo
    Usted, y nadie más
    Para qué sirve
    Demuestra que este servidor es al que se le emitió el certificado

  • La solicitud de firma de certificadoPúblico

    Su primera línea-----BEGIN CERTIFICATE REQUEST-----También muy usadas-----BEGIN NEW CERTIFICATE REQUEST-----

    Firmado por
    A sí misma, con la clave privada
    Quién puede verlo
    Usted y la autoridad de certificación
    Para qué sirve
    Pide un certificado, y demuestra que usted tiene la clave correspondiente

  • El certificadoPúblico

    Su primera línea-----BEGIN CERTIFICATE-----

    Firmado por
    La autoridad de certificación
    Quién puede verlo
    Cada visitante de su sitio
    Para qué sirve
    Le dice a un navegador que esta clave pertenece a estos nombres

.csr.pem.req.txtNingún estándar le asigna una extensión de archivo a una solicitud; todas estas están en uso, y esta página lee el contenido en lugar del nombre

Solo el primero de los tres es un secreto. El último se entrega de todas formas a cada visitante, y el del medio deja de servir en cuanto llega el certificado.

¿Es seguro decodificar un CSR en línea?

Un CSR no lleva ningún secreto, así que decodificar uno en cualquier sitio es inofensivo. Una clave privada es un asunto distinto, y es el archivo con el que la gente la confunde.

Todo en esta página se ejecuta en su navegador. El código que analiza la solicitud se descargó junto con la página, la firma se comprueba con la Web Crypto de su propio navegador, y no se hace ninguna solicitud a ningún servidor con sus datos dentro: puede observar el panel de red mientras la usa. Eso es una propiedad de cómo está construida la página, no una promesa que le pedimos que crea sin más.

La razón por la que esto importa es el archivo que suele ir junto al CSR. La propia definición del CA/Browser Forum es implacable: «Se dice que una clave privada está comprometida si su valor se ha revelado a una persona no autorizada, o si una persona no autorizada ha tenido acceso a ella». No hace falta ningún uso indebido: basta con que llegue al servidor de otra persona. En 2020, DigiCert encontró 337 claves privadas que sus clientes habían pegado junto a sus CSR, y revocó todos los certificados involucrados, escribiendo que «al enviar la clave privada a DigiCert junto con el CSR, el cliente comprometió la clave privada». Si esta página alguna vez lee una clave privada que usted pegó, se lo dice, se niega a decodificarla y no conserva nada de ella.

Adónde va realmente el archivoCA/Browser Forum TLS BR 2.3.1

Esta página

Su navegador
  1. Se lee el archivo
  2. Lo analiza el código que llegó con la página
  3. La firma la comprueba el propio navegador
  4. Se dibuja el resultado

Ninguna solicitud sale con sus datos dentroAbra el panel de red y observe mientras la usa

Una página que lo sube

Su navegador

Se sube el archivo…junto con lo que se haya pegado al lado

El servidor de otra persona

Una clave privada que llega ahí queda comprometida solo por eso

«Se dice que una clave privada está comprometida si su valor se ha revelado a una persona no autorizada, o si una persona no autorizada ha tenido acceso a ella».

la definición que las autoridades de certificación escribieron para sí mismas

Ya ha pasadoEn 2020, una autoridad de certificación encontró 337 claves privadas pegadas junto a una solicitudSe revocó cada certificado involucrado

Nada en una solicitud es secreto, así que decodificar una en cualquier sitio es inofensivo. El archivo con el que la gente la confunde es un asunto distinto, y el daño no necesita ningún uso indebido: basta con que se vea.

RSA o ECDSA: ¿qué clave debería pedir un CSR?

Una clave ECDSA P-256 es tan fuerte como una clave RSA de 3072 bits, y mucho más pequeña, así que es la mejor opción predeterminada. RSA 2048 sigue siendo aceptada en todas partes.

El NIST ubica a P-256 y a RSA-3072 en la misma fortaleza de seguridad de 128 bits, y su tabla ni siquiera tiene una fila para RSA-4096: la siguiente fila es RSA-7680, con 192 bits, el nivel que alcanza P-384. Así que una clave RSA de 4096 bits le cuesta a cada visitante trabajo extra de negociación sin ninguna ganancia documentada sobre 3072. Los Baseline Requirements también permiten P-521, pero Let's Encrypt la rechaza, así que una solicitud con P-521 puede ser perfectamente legal y aun así fallar en la CA que pensaba usar.

Ed25519 no es una opción para un certificado TLS público hoy, por bueno que sea el algoritmo: los Baseline Requirements enumeran RSA y las tres curvas del NIST, y agregan que «no se permiten otros algoritmos ni otros tamaños de clave». Tampoco lo es una clave poscuántica: la votación que habría permitido ML-DSA en TLS público se cerró sin aprobarse en octubre de 2026. Ed25519 y ML-DSA siguen siendo útiles para SSH, para firmar y para una CA privada, y esta página lee solicitudes que las usan.

La misma fortaleza, en dos tamaños muy distintosNIST SP 800-57 Part 1 Rev 5, Table 2
FortalezaClave RSACurva
112 bits de seguridad2048 bitsCualquier CA públicaNinguna curva que permita una autoridad de certificación pública está en esta fortaleza
128 bits de seguridad3072 bitsCualquier CA públicaP-256Cualquier CA pública
4096 bitsCualquier CA pública4096 bits ni siquiera está en la tabla
192 bits de seguridad7680 bitsCualquier CA públicaP-384Cualquier CA pública
256 bits de seguridad15.360 bitsCualquier CA públicaP-521Cualquier CA pública
  • Clave RSA
  • Curva
  • Los escalones van directo de un tamaño al siguiente y se saltan el popular de en medio, así que el trabajo extra de negociación que le cuesta a cada visitante no compra nada que nadie haya documentado
  • Aceptada porLet's Encrypt

Una curva lleva la misma fortaleza en una fracción de los bytes

La comparación publicada, con las dos cosas que deciden si realmente puede usar una clave: lo que permiten las reglas, y lo que permite la autoridad de certificación que pensaba usar.

Cómo generar un CSR en cualquier plataforma

Un solo comando de OpenSSL cubre Linux, macOS y Windows con OpenSSL instalado. IIS tiene certreq, macOS tiene Acceso a Llaveros, y este sitio tiene un generador que nunca envía su clave a ningún lado.

Con OpenSSL, openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" genera la clave y la solicitud en un solo paso. (-nodes deja la clave sin cifrar. OpenSSL 3 también lo escribe -noenc, pero el LibreSSL integrado en macOS solo conoce -nodes.) Después, openssl req -in example.com.csr -text -verify -noout la muestra y la verifica. En Windows, certreq -new request.inf request.req lee un archivo .inf cuyos nombres alternativos van bajo el OID 2.5.29.17 con líneas _continue_: no existe una clave SAN=. La propia página de referencia de Microsoft advierte que su ejemplo usa SHA-1, que una CA rechazará ahora, así que configure el hash usted mismo.

En una Mac, Acceso a Llaveros > Asistente de certificados > Solicitar un certificado a una autoridad de certificación genera uno, con el tamaño de clave detrás de la casilla «Dejarme especificar información del par de claves». O use nuestro generador de CSR, que crea la clave con la Web Crypto de su navegador y le entrega ambos archivos sin que toquen ningún servidor. Ningún estándar le asigna una extensión de archivo a un CSR: .csr, .pem, .req y .txt están todos en uso, y esta página lee el contenido en lugar de confiar en el nombre.

Cuatro maneras de generar unoOpenSSL · Microsoft Learn · Apple Support

  1. OpenSSLLinux, macOS, Windows

    Genera la clave y la solicitud en un solo comandoopenssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com"Luego léala de vuelta y verifique su propia firmaopenssl req -in example.com.csr -text -verify -noout

  2. certreqWindows Server e IIS

    Lee un archivo de texto plano; los nombres alternativos van en una sección de extensiones, uno por líneacertreq -new request.inf request.req[Extensions] 2.5.29.17 = "{text}" _continue_ = "DNS=example.com&" _continue_ = "DNS=www.example.com"La propia página de ejemplo de Microsoft todavía está escrita en torno a un hash que una autoridad de certificación ahora rechaza, así que configure el hash usted mismo

  3. Keychain AccessmacOS

    Keychain Access › Certificate Assistant › Request a Certificate From a Certificate AuthoritySu Mac nombra estos menús en su propio idiomaEl tipo y el tamaño de clave se esconden detrás de la casilla que le permite especificar el par de clavesClaves RSA de 2048 a 4096 bits; las más pequeñas ya no se ofrecen

  4. DNS RobotCualquier navegador

    Genera la clave con la propia criptografía de su navegador y le entrega ambos archivos sin que ninguno toque un servidorAbrir el generador
Un solo comando de OpenSSL funciona igual en Linux, macOS y Windows. Las otras tres vías son para las máquinas donde no lo tiene a mano.

¿Cuánto durará el certificado?

Un certificado TLS público emitido hoy no puede superar los 200 días. Eso baja a 100 días en marzo de 2027 y a 47 días en marzo de 2029.

El calendario viene de la votación SC-081v3 del CA/Browser Forum, adoptada en abril de 2025, y no es algo que un CSR pueda influir: la vigencia nunca viene de la solicitud. Cada escalón tiene dos números, un SHOULD NOT un día por debajo del MUST NOT: 199 y 200 hoy, 99 y 100 desde el 15 de marzo de 2027, 46 y 47 desde el 15 de marzo de 2029. Para efectos del conteo, «un día se mide como 86.400 segundos», y cualquier parte de un día adicional cuenta como un día completo.

La consecuencia práctica es que la renovación tiene que ser automática. Si todavía genera un CSR a mano cada año, este es el momento de pasarse a ACME, donde el cliente genera la solicitud por usted —y donde, de paso, sí se exige PKCS#10, aunque los propios Baseline Requirements solo piden «una solicitud de certificado en la forma que prescriba la CA»—.

Cuánto puede durar un certificadoCA/Browser Forum TLS BR 2.3.1 §6.3.2
  1. antes del 15 de marzo de 2026Dónde está hoy397 días398 días
  2. desde el 15 de marzo de 2026199 días200 días
  3. desde el 15 de marzo de 202799 días100 días
  4. desde el 15 de marzo de 202946 días47 días
  • Todo el calendario viene de una sola votación, SC-081v3, adoptada el 11 de abril de 2025
  • Un día se cuenta como exactamente 86.400 segundos y cualquier parte de un día adicional cuenta como un día completo
  • Nada en una solicitud cambia nada de esto
Cuatro escalones, cada uno con dos números: el que desaconsejan las reglas y el que prohíben. Las fechas ya están fijadas, que es lo que hace de la renovación automática la única respuesta viable.

Qué le muestra el ASN.1 sin procesar

Debajo del base64, un CSR es un árbol codificado en DER. El decodificador lo dibuja con desplazamientos de bytes y nombra cada identificador de objeto que reconoce, que es justo lo que imprime openssl asn1parse.

Es la manera honesta de mostrar un campo para el que nadie tiene un nombre amigable. Abra Estructura sin procesar en cualquier elemento decodificado y puede ver el CertificationRequestInfo, los nombres distintivos relativos del sujeto uno por uno, el SubjectPublicKeyInfo, el conjunto attributes [0] y, dentro de él, el atributo extensionRequest —identificador de objeto 1.2.840.113549.1.9.14, definido no en el RFC 2986 sino en el RFC 2985 §5.4.2—, que lleva las mismísimas extensiones X.509 del RFC 5280.

El otro atributo que puede encontrar ahí es challengePassword (1.2.840.113549.1.9.7). Se pensó como un secreto compartido para revocar un certificado más adelante, todavía lo usa la inscripción SCEP, y no cumple ningún papel en un pedido normal de certificado web. Esta página lo muestra cuando está presente, porque un campo que no se ve es un campo que no se puede comprobar.

La misma solicitud, en bytesRFC 2986 · RFC 2985 · RFC 5280
En el byteEstructuraTamaño
0SEQUENCE749 bytes
4SEQUENCE469 bytes
8INTEGER03 bytes
11SEQUENCE108 bytes
13SET13 bytes
15SEQUENCE11 bytes
17OBJECT IDENTIFIERC2.5.4.65 bytes
22PrintableStringUS4 bytes
26SET21 bytes
28SEQUENCE19 bytes
30OBJECT IDENTIFIERST2.5.4.85 bytes
35UTF8StringCalifornia12 bytes
47SET24 bytes
49SEQUENCE22 bytes
51OBJECT IDENTIFIERL2.5.4.75 bytes
56UTF8StringSan Francisco15 bytes
71SET22 bytes
73SEQUENCE20 bytes
75OBJECT IDENTIFIERO2.5.4.105 bytes
80UTF8StringExample Inc13 bytes
93SET26 bytes
95SEQUENCE24 bytes
97OBJECT IDENTIFIERCN2.5.4.35 bytes
102UTF8Stringwww.example.com17 bytes
119SEQUENCE294 bytes
123SEQUENCE15 bytes
125OBJECT IDENTIFIERrsaEncryption1.2.840.113549.1.1.111 bytes
136NULL2 bytes
138BIT STRING2160 bits30 82 01 0a 02 82 01 01 00 c5 47 47 1d 26 1c bf275 bytes
413[0]60 bytes
415SEQUENCE58 bytes
417OBJECT IDENTIFIERextensionRequest1.2.840.113549.1.9.1411 bytes
428SET45 bytes
430SEQUENCE43 bytes
432SEQUENCE41 bytes
434OBJECT IDENTIFIERSubject Alternative Name2.5.29.175 bytes
439OCTET STRING32 bytes30 1e 82 0f 77 77 77 2e 65 78 61 6d 70 6c 65 2e34 bytes
473SEQUENCE15 bytes
475OBJECT IDENTIFIERsha256WithRSAEncryption1.2.840.113549.1.1.1111 bytes
486NULL2 bytes
488BIT STRING2048 bits00 57 41 c5 09 98 14 78 8c ee c3 61 d4 c0 e0 2d261 bytes
  • Contiene otras cosas
  • Contiene un valor
  • Se nombra por su posición

  • El atributo que lleva las extensiones

    1.2.840.113549.1.9.14Se define en un documento distinto del que define la propia solicitud, que es por lo que los nombres alternativos viajan dentro de un atributo en lugar de ir junto al sujeto

  • El otro atributo que puede encontrarNo está en esta solicitud

    1.2.840.113549.1.9.7Un secreto compartido, pensado para pedir más adelante que se revoque el certificado, y que todavía se usa cuando un dispositivo se inscribe en una red
Cada byte de la solicitud de ejemplo, con cada identificador de objeto nombrado. Esto es lo que imprime un decodificador de línea de comandos, dibujado en lugar de impreso, para que vea dónde termina un campo y dónde empieza el siguiente.

Decodificador de CSR: preguntas y respuestas

¿Cómo decodifico un CSR?

Pegue toda la solicitud en el cuadro de arriba, incluidas las líneas -----BEGIN CERTIFICATE REQUEST----- y -----END CERTIFICATE REQUEST-----, o suelte el archivo en la página. Se decodifica mientras pega: el sujeto, la clave pública, cada nombre alternativo del sujeto, cada extensión solicitada y las huellas. También puede pegar solo el cuerpo en base64, un volcado hexadecimal, o subir un archivo DER binario.

¿Es seguro usar este decodificador de CSR?

Sí, por dos razones. Una solicitud de firma de certificado no lleva ningún secreto —está pensada para enviarse a una autoridad de certificación—, así que decodificar una en cualquier sitio es inofensivo. Y esta página hace el trabajo en su navegador: el código que analiza la solicitud se descargó junto con la página, y no se envía nada a ningún servidor. Si pega una clave privada por error, la página se lo advierte, se niega a decodificarla y no conserva nada de ella.

¿Cómo compruebo si mi CSR es válido?

Decodifíquelo aquí y lea el veredicto. La página comprueba la firma de la propia solicitud, que demuestra que quien la envía tiene la clave privada correspondiente, y luego aplica las reglas que usa una autoridad de certificación pública: nombres que no puede certificar, comodines demasiado amplios, direcciones IP reservadas, claves demasiado pequeñas o factorizables, campos del sujeto obsoletos y hashes de firma anticuados. Cada hallazgo indica si es una causa de rechazo, una corrección automática o solo una nota.

¿Por qué mi autoridad de certificación rechaza mi CSR?

Las causas más comunes son un nombre interno como server.local o un nombre de host de una sola etiqueta, un guion bajo en un nombre de host, un comodín sobre un sufijo público como *.co.uk, una dirección IP privada entre los nombres alternativos, una clave RSA de menos de 2048 bits, o una solicitud todavía firmada con SHA-1. Decodifique la solicitud arriba y cada una de esas causas se nombra explícitamente, con la regla que incumple.

¿Cómo sé si mi clave privada coincide con mi CSR?

Use Comparar una clave o un certificado arriba: agregue la clave junto a la solicitud y la página compara, en su navegador, la clave pública del archivo de clave con la de la solicitud. O hágalo usted mismo: openssl req -in request.csr -pubkey -noout y openssl pkey -in private.key -pubout imprimen la misma clave pública cuando coinciden. La misma comparación funciona entre una clave y un certificado ya emitido.

¿Esto también decodifica un certificado SSL?

Sí. Pegue un certificado y se decodifica como tal: emisor y sujeto, número de serie, fechas de vigencia, cada nombre alternativo, uso de la clave y uso extendido de la clave, los identificadores de clave de la autoridad y del sujeto, las URL de OCSP y de emisores de la CA, las políticas del certificado y cualquier marca de tiempo de certificate transparency incluida. Pegue juntos un certificado y su solicitud, y la página también le dice si comparten clave.

¿Qué campos usa realmente una autoridad de certificación de mi CSR?

Con certeza, uno: la clave pública. La propia documentación de DigiCert dice que el resto se ignora. En un certificado OV o EV, la CA debe validar por sí misma la organización y el país antes de incluirlos; las fechas de vigencia siempre vienen del calendario de los Baseline Requirements, nunca de la solicitud. Dos campos no solo se ignoran, sino que están prohibidos en un certificado TLS público: OU y, en los certificados validados por dominio, emailAddress.

¿El nombre común todavía importa?

Solo como una copia de otra cosa. Los navegadores ignoran el nombre común para hacer coincidir el host desde 2017, y usan solo los nombres alternativos del sujeto. Los Baseline Requirements marcan el nombre común como NOT RECOMMENDED, y exigen que, si está presente, «DEBE contener exactamente una entrada que sea uno de los valores incluidos en la extensión subjectAltName del certificado». Un nombre común que no está entre sus nombres alternativos es una causa de rechazo, y esta página lo marca.

¿Puedo decodificar varios archivos a la vez?

Sí. Pegue juntos una solicitud, su certificado y los intermedios, y cada bloque se decodifica en su propia tarjeta, en el orden en que los pegó. Un bloque dañado no detiene a los demás. Si hay una clave privada en algún lugar de lo que pegó, se la identifica y se la omite, nunca se la decodifica. Se decodifican hasta cuarenta bloques, y todo lo que supere eso se cuenta y se informa en lugar de descartarse en silencio.

¿Qué es un challenge password en un CSR?

Un atributo opcional del RFC 2985, pensado originalmente como un secreto compartido que se indicaría al pedir que se revocara el certificado. Todavía cumple un papel en la inscripción SCEP, donde un dispositivo demuestra que tiene permiso para pedirla. No cumple ningún papel en un pedido ordinario de certificado web, y como es un campo que pocas herramientas muestran, esta página lo despliega cada vez que una solicitud lo lleva.

¿Puedo usar una clave Ed25519 para un certificado público?

Todavía no. Los Baseline Requirements permiten RSA y las curvas P-256, P-384 y P-521, y luego establecen que «no se permiten otros algoritmos ni otros tamaños de clave», así que ninguna autoridad de certificación pública emitirá contra una solicitud con Ed25519. Es una buena clave para SSH, para firmar y para una CA privada, y este decodificador lee sin problema solicitudes con Ed25519 y Ed448, y claves poscuánticas ML-DSA.

¿Cuánto dura ahora un certificado?

Un certificado TLS público emitido hoy no puede superar los 200 días, por debajo de los 398 que regían antes del 15 de marzo de 2026. Baja a 100 días el 15 de marzo de 2027 y a 47 días el 15 de marzo de 2029, según la votación SC-081v3 del CA/Browser Forum. Nada en un CSR influye en esto; la vigencia la define la CA. Con estos plazos, la renovación tiene que ser automática, lo que en la práctica significa ACME.

¿Le falta algo?Sugiera una función o una herramienta nueva

Herramientas relacionadas