Comme vous l'avez constaté, vous pouvez désactiver la vérification de certificat au niveau de la négociation SSL / TLS dans Apache Httpd à l'aide de SSLVerifyCLient optional_no_ca.
Le deuxième problème auquel vous allez être confronté avec ce que vous essayez de faire est d'amener le client à envoyer le certificat. Étant donné que vos certificats ne sont pas destinés à faire partie d'une infrastructure à clé publique, ils peuvent être auto-signés et avoir différents émetteurs.
Lors de la demande d'un certificat client, le serveur envoie un CertificateRequestmessage TLS au client pendant le handhsake. Ce message contient la certificate_authoritiesliste:
Une liste des noms distinctifs des autorités de certification acceptables. Ces noms distinctifs peuvent spécifier un nom distinctif souhaité pour une autorité de certification racine ou pour une autorité de certification subordonnée; ainsi, ce message peut être utilisé pour décrire à la fois des racines connues et un espace d'autorisation souhaité. Si la liste certificate_authorities est vide, le client PEUT envoyer tout certificat du ClientCertificateType approprié, sauf s'il existe un arrangement externe contraire.
Les navigateurs l'utilisent pour choisir le certificat client à envoyer (le cas échéant).
(Notez que la partie sur la liste vide est uniquement dans la spécification à partir de TLS 1.1. SSL 3.0 et TLS 1.0 sont silencieux à ce sujet, et en pratique, cela fonctionnera également.)
Vous avez deux options pour cela.
Si les certificats clients que vous attendez vont être auto-signés, ils auront tous des émetteurs différents. Parce que vous ne savez pas à quoi vous attendre, le serveur devra envoyer une liste vide. Pour ce faire, utilisez la SSLCADNRequestFiledirective et pointez-la vers un fichier qui ne contient qu'une ligne vide (si je me souviens bien, cela ne fonctionne pas avec un fichier complètement vide).
La deuxième option (moins propre). Est de convenir d'un DN émetteur commun à tous les certificats clients que vous attendez, qu'ils aient effectivement été émis ou non par ce certificat CA (ou que cette CA existe ou non). Ce faisant, vous briseriez considérablement le modèle PKI (plus).
Si vous êtes d'accord sur un DN émetteur comme CN=Dummy CA(par exemple). Tout le monde peut créer un certificat auto-signé en utilisant CN=Dummy CAcomme DN d'objet (et DN d'émetteur), éventuellement avec des clés différentes. Bien que la SSLCADNRequestFiledirective s'attende à être configurée avec des certificats pour construire la liste, ceux-ci ne sont pas du tout utilisés pour vérifier le certificat client, c'est juste une manière compliquée (mais naturelle dans le contexte des autres directives) de configurer la certificate_authoritiesliste. Si vous, en tant que service, placez un certificat auto-signé avec ces noms SSLCADNRequestFile, cela fera que le CertificateRequestmessage TLS sera utilisé CN=Dummy CAdans la certificate_authoritiesliste (ce ne sont que des noms, pas des certificats à ce stade). Le client pourra alors récupérer son propre certificat auprès de l'émetteur DNCN=Dummy CA, que sa signature puisse ou non être vérifiée par ce certificat (mêmes clés), car aucune vérification de signature n'est de toute façon impliquée dans ces étapes.
Cela étant dit, n'oubliez pas qu'avec SSLVerifyCLient optional_no_ca, aucune vérification de certificat réelle n'est effectuée (je suppose que vous pouvez vérifier la SSL_CLIENT_VERIFYvariable si votre vérification manuelle n'est qu'une solution de secours à une PKI que vous avez configurée de toute façon). Tout ce que vous saurez à ce stade, c'est que le client possède la clé privée du certificat de clé publique qu'il a présenté (garanti par le CertificateVerifymessage TLS ): vous devrez effectuer une certaine forme de vérification si vous voulez qu'il y ait authentification de certains Trier. (Vous ne pouvez pas faire confiance au contenu du certificat, c'est-à-dire à la liaison entre sa clé publique et les noms / attributs qu'il contient.)
Cela ne fonctionnera pas bien pour les fichiers, mais vous pouvez le faire pour une application (par exemple PHP / CGI / ... même Java si vous passez le certificat au serveur Java mandaté). Une façon de base serait d'avoir une liste pré-connue de clés publiques, ou vous pouvez regarder les idées dans FOAF + SSL / WebID .