Datos personalizados en el certificado SSL

Question

Datos personalizados en el certificado SSL

#1 de CristianTM (6 votos)
#2 de Mike Ounsworth (2 votos)

7

Estoy buscando una forma de agregar datos personalizados adicionales en un certificado de servidor SSL emitido por una CA estándar. ¿Es esto posible?

Quiero obtener un certificado de servidor SSL emitido por una CA estándar, para que sea aceptado por los navegadores estándar. Sin embargo, tengo una pequeña cantidad de datos adicionales que serán utilizados por mi aplicación privada que también me gustaría incluir en el certificado. Estoy buscando una manera de incluirlo en el certificado, de una manera que los navegadores estándar ignorarán y (críticamente) que la CA no eliminará.

¿Hay un campo o lugar donde pueda almacenar datos arbitrarios, sin que sean eliminados por las CA públicas?

Tal vez la parte otherName parte de subjectAltName : ¿lo conservará cualquier CA estándar? ¿Debo mirar una extensión x509 personalizada?

El requisito crítico es que la CA no lo elimine ni lo modifique. Necesito que exista al menos una CA en la que confíen los principales navegadores, y no eliminaré estos datos personalizados. Sé que algunos campos de la solicitud de firma de certificado (CSR) están filtrados o eliminados por las CA, pero no he podido encontrar la documentación sobre cuáles (si los hay) permiten datos arbitrarios y se conservarán del CSR en el certificado final.

Esta pregunta está relacionada, pero no es la misma: no tiene el requisito de que el certificado sea firmado por una CA en la que confían los navegadores modernos. Además, he encontrado mucha información sobre cómo agregar extensiones personalizadas a un CSR x509, pero eso no es lo que estoy buscando; eso no me dice en qué extensión se guardan los datos (qué extensión no será eliminada por las principales CA). Sé cómo crear un CSR que contenga datos personalizados , pero no sé qué campos del CSR se copiarán sin modificar en el certificado final del servidor. Tampoco estoy buscando una solución que implique la ejecución de mi propia CA: quiero que el certificado de servidor sea aceptado por los navegadores estándar. Esta pregunta también tiene un aspecto similar, pero no lo creo. No veo una respuesta clara allí.

public-key-infrastructure tls certificates x.509

pregunta D.W. 19.06.2015 - 04:21

fuente

2 respuestas

Lea otras preguntas en las etiquetas public-key-infrastructure tls certificates x.509

Intercambio de DEK y KEK (claves de cifrado) entre el servidor de aplicaciones y el servidor de claves ¿Es un paquete detectar un riesgo en el VPS? Si es así, ¿qué precauciones debo preguntar a mi anfitrión si toman?

score 6 · Answer 1

Bueno, me pondría en contacto con CA para preguntar si lo harían. Podrían hacerlo, y tal vez estén dispuestos a hacerlo si pagas lo suficiente. Cualquier campo no crítico que los broswers no entiendan será ignorado y podría ser agregado por la CA. La pregunta es si lo harían y eso solo puede ser respondido por ellos.

Algunos CPS incluso mencionan la posibilidad de agregar extensiones no críticas (y estas pueden ser privadas) y NO agregar, por supuesto, extensiones privadas críticas ( enlace - 7.1.2). Es solo una cuestión de querer hacerlo.

Las CA de emisor utilizarán extensiones de certificado de acuerdo con Estándares aplicables de la industria, incluyendo RFC 3280/5280. CA emisores no emitirá certificados con una extensión privada crítica.

Pero probablemente la forma correcta de hacer lo que quiere es usar certificados de atributo. Podría tener un Emisor de certificado de atributo que controle y emita AC a su certificado SSL, dándole los atributos adicionales que necesita y que solo usted entiende. TLS tiene soporte para proporcionar esas CA a su cliente o puede enviarlas al utilizar el túnel SSL ya creado, y éstas pueden ser interpretadas por el cliente según sea necesario.

score 2 · Answer 2

Has preguntado:

Tal vez la otra parte de nombre de subjectAltName?

No, no allí. Los navegadores leen el campo Asunto Alt Name (SAN) y pueden usarse para realizar ataques Man in the Middle (MITM), por lo que las CA no deben permitir datos personalizados (y no verificables públicamente) en los campos SAN.

Le dirijo a RFC 5280 que define el estándar de certificado X.509, específicamente Sección 4.2 Extensiones de certificado . No veo ninguna extensión estándar que permita texto general, pero el siguiente experto es interesante (énfasis mío):

El formato de certificado X.509 v3 También permite a las comunidades definir extensiones privadas para llevar información exclusiva de esas comunidades. Cada extensión en una El certificado se designa como crítico o no crítico. UNA El sistema que utiliza el certificado DEBE rechazar el certificado si encuentra una extensión crítica que no reconoce o una extensión crítica que contiene información que no puede procesar. Un no critico la extensión PUEDE ser ignorada si no se reconoce, pero DEBE ser Procesado si se reconoce. Las siguientes secciones presentan Extensiones recomendadas utilizadas dentro de los certificados y estándares de Internet. Ubicaciones para información. Las comunidades pueden elegir usar más extensiones

Has dicho:

Sé cómo crear una CSR que contiene datos personalizados, pero no sé qué campos de la CSR se copiarán sin modificar en el certificado final del servidor.

Nadie en este sitio puede responder eso por ti. De acuerdo con RFC 4210 , una CA puede modificar extensiones no críticas a voluntad (y devolver el certificado con el grantedWithMods PKIStatus). Entonces, como se mencionó en los comentarios, esto es algo que tendrá que negociar con una CA específica.