Verificación del dominio de un certificado en OpenSSL

Question

Necesito verificar el dominio de un certificado X509 usando C-land OpenSSL.

Mi entendimiento es que la biblioteca no hacer esto por mí, y que tengo que aplicar más o menos el siguiente algoritmo:

1. Si el campo dNSName de la extensión subjectAlternativeName está presente, establece que a name valor.
2. De lo contrario, configure name en el campo CN del asunto.
3. Compare name con el nombre de host solicitado, permitiendo que cada asterisco coincida con [A-Za-z0-9 _] +, pero no con 'punto' (.).

Me parece que debería haber un montón de código dando vueltas para hacer esto, pero no he encontrado ninguno.

¿Alguien puede encontrar un ejemplo de esto? ¿O, como alternativa, comprobar la cordura de mi algoritmo?

EDITAR: Esto es lo que se me ocurrió: https://gist.github.com/2821083. Parece realmente extraño que OpenSSL deje esto al código de llamada.

Answer 1

Usted es bastante acertado, aunque tenga cuidado con el tema Nombres alternativos y direcciones IP sin procesar y FQDN. Es posible que desee para robar

BOOL SSL_X509_getIDs(apr_pool_t *p, X509 *x509, apr_array_header_t **ids) 

y amigos relacionados de http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c y el destinatario de la llamada en ssl_engine_init.c (que es por cierto el lado del servidor) para todas las opciones.

Como está actuando en la devolución de llamada openssl - también tenga en cuenta la fecha & hora y la cadena si no ha proporcionado eso ya en el CTX.

Dw.

Answer 2

Parece realmente extraño que OpenSSL deje esto al código de llamada.

Sí, es una omisión muy problemática en la práctica porque muchas aplicaciones no se dan cuenta de que deben realizar el cheque manualmente.

OpenSSL 1.1.0 incluirá la verificación de nombre de host (en HEAD ahora (a partir de SEPT 2013)). De acuerdo con los registros de cambios, hay una opción -verify_name y apps.c responde al interruptor -verify_hostname. Pero s_client no responde a ninguno de los conmutadores, por lo que no está claro cómo se implementará o invocará la verificación del nombre de host para un cliente.

---

Si el campo de la extensión subjectAlternativeNamednsName está presente, establecer el nombre a ese valor.

Puede haber varios nombres alternativos del sujeto (SAN), así que prepárese para más de uno.

De lo contrario, establezca el nombre en el campo CN del asunto.

Creo que también necesita comprobarlo para encontrar una coincidencia.

Compare nombre contra el nombre de host solicitado, permitiendo que cada asterisco para que coincida con [A-Za-z0-9 _] +, pero no 'punto' (.).

Es mucho más doloroso. También debe asegurarse de no coincidir con un gTLD o ccTLD. Por ejemplo, no desea hacer coincidir un certificado emitido con el gTLD *.com. Ese certificado probablemente fue emitido por un tipo malo;)

ccTLDs son como * .eu, * .us o இலங்கை (nic.lk). Hay aproximadamente 5000 de ellos y Mozilla ofrece una lista al http://publicsuffix.org/. La lista sin formato está en https://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1.

---

Me parece que debe haber un montón de código dando vueltas a hacer esto, pero no he encontrado ninguna.

Además de la sugerencia de van Gulik, también puedes probar Curl. Estoy bastante seguro de que Curl contiene código de coincidencia de nombre de host.

---

Incluso puede verificar que los certificados estén bien formados. El grupo responsable en el contexto de la Web son los foros CA/Browser. Tienen requisitos básicos y ampliados para la creación de certificados:

• Requisitos de certificados de línea de base, https://www.cabforum.org/Baseline_Requirements_V1_1_6.pdf
• Extended Requisitos de certificados de validación, https://www.cabforum.org/Guidelines_v1_4_3.pdf

En los documentos de referencia, se encuentra, por ejemplo, un IP listado como el Nombre común (CN) también se debe enumerar en los Nombres alternativos del sujeto (SAN).

En los documentos extendidos, encontrará que las direcciones IP reservadas (RFC 1918) no pueden estar presentes en un certificado de validación extendida (EV); y los certificados EV no pueden contener comodines.