Como ha encontrado, puede deshabilitar la verificación del certificado en el nivel de protocolo de enlace SSL / TLS dentro de Apache Httpd mediante SSLVerifyCLient optional_no_ca.
El segundo problema que enfrentará con lo que intenta hacer es hacer que el cliente envíe el certificado. Dado que su certificado no está destinado a estar dentro de una PKI, podrían estar autofirmados y tener varios emisores.
Al solicitar un certificado de cliente, el servidor envía un CertificateRequestmensaje TLS al cliente durante el reconocimiento. Este mensaje contiene la certificate_authoritieslista:
Una lista de los nombres distinguidos de las autoridades de certificación aceptables. Estos nombres distinguidos pueden especificar un nombre distinguido deseado para una CA raíz o para una CA subordinada; por lo tanto, este mensaje se puede usar para describir tanto las raíces conocidas como el espacio de autorización deseado. Si la lista de certificados_autoridades está vacía, el cliente PUEDE enviar cualquier certificado del ClientCertificateType apropiado, a menos que exista algún acuerdo externo en contrario.
Los navegadores usan esto para elegir qué certificado de cliente enviar (si lo hay).
(Tenga en cuenta que la parte sobre la lista vacía está solo en la especificación de TLS 1.1 en adelante. SSL 3.0 y TLS 1.0 no dicen nada al respecto, y en la práctica, también funcionará).
Tienes dos opciones para esto.
Si los certificados de cliente que espera serán autofirmados, todos tendrán diferentes emisores. Como no sabrá qué esperar, el servidor deberá enviar una lista vacía. Para hacer esto, use la SSLCADNRequestFiledirectiva y apúntela a un archivo que contenga solo una línea vacía (si no recuerdo mal, no funciona con un archivo completamente vacío).
La segunda opción (menos limpia). Es acordar un DN del Emisor común a todos los certificados de cliente que espera, independientemente de que hayan sido emitidos o no por ese certificado de CA (o de si esa CA existe o no). Al hacerlo, estaría rompiendo el modelo PKI considerablemente (más).
Si está de acuerdo con un DN del emisor como CN=Dummy CA(por ejemplo). Cualquiera puede crear un certificado autofirmado utilizando el CN=Dummy CADN del sujeto (y el DN del emisor), posiblemente con diferentes claves. Aunque la SSLCADNRequestFiledirectiva espera configurarse con certificados para construir la lista, estos no se utilizan para verificar el certificado del cliente, es una forma complicada (pero natural en el contexto de las otras directivas) de configurar la certificate_authoritieslista. Si, como servicio, coloca un certificado autofirmado con estos nombres SSLCADNRequestFile, esto hará que el CertificateRequestmensaje TLS se use CN=Dummy CAen la certificate_authoritieslista (estos son solo nombres, no certificados en esta etapa). El cliente podrá recoger su propio certificado con el DN del emisorCN=Dummy CA, si su certificado podría verificarse o no mediante ese certificado (las mismas claves) o no, ya que de todos modos no hay verificación de firma en estos pasos.
Dicho esto, recuerde que con SSLVerifyCLient optional_no_ca, no se realiza una verificación real del certificado (supongo que podría verificar la SSL_CLIENT_VERIFYvariable si su verificación manual es solo una solución alternativa a una PKI que haya configurado de todos modos). Todo lo que sabrá en esa etapa es que el cliente tiene la clave privada para el certificado de clave pública que ha presentado (garantizado por el CertificateVerifymensaje TLS ): deberá realizar algún tipo de verificación si desea que haya autenticación de algunos ordenar. (No puede confiar en el contenido del certificado, es decir, en cualquiera de los enlaces entre su clave pública y los nombres / atributos que contiene).
Esto no funcionará bien para los archivos, pero puede hacerlo para una aplicación (por ejemplo, PHP / CGI / ... incluso Java si pasa el certificado al servidor Java proxy). Una forma básica sería tener una lista conocida de claves públicas, o podría mirar las ideas en FOAF + SSL / WebID .