Come hai trovato, puoi disabilitare la verifica del certificato a livello di handshake SSL / TLS in Apache Httpd usando SSLVerifyCLient optional_no_ca.
Il secondo problema che dovrai affrontare è quello di indurre il client a inviare il certificato. Poiché il certificato non è destinato a rientrare in una PKI, potrebbe essere autofirmato e avere vari emittenti.
Quando si richiede un certificato client, il server invia un CertificateRequestmessaggio TLS al client durante l'handhsake. Questo messaggio contiene l' certificate_authoritieselenco:
Un elenco dei nomi distinti delle autorità di certificazione accettabili. Questi nomi distinti possono specificare un nome distinto desiderato per una CA principale o per una CA subordinata; quindi, questo messaggio può essere usato per descrivere sia le radici note sia uno spazio di autorizzazione desiderato. Se l'elenco certificate_authorities è vuoto, il client PUO 'inviare qualsiasi certificato del ClientCertificateType appropriato, a meno che non vi siano disposizioni esterne contrarie.
I browser lo usano per scegliere quale certificato client inviare (se presente).
(Notare che la parte relativa all'elenco vuoto è solo nelle specifiche da TLS 1.1 in poi. SSL 3.0 e TLS 1.0 non ci parlano, e in pratica funzionerà anche.)
Hai due opzioni per questo.
Se i certificati client che prevedete saranno autofirmati, avranno tutti emittenti diversi. Poiché non saprai cosa aspettarti, il server dovrà inviare un elenco vuoto. Per fare questo, usa la SSLCADNRequestFiledirettiva e punta a un file che contiene solo una riga vuota (se ricordo bene, non funziona con un file completamente vuoto).
La seconda opzione (meno pulita). È concordare un DN dell'Emittente comune a tutti i certificati client previsti, indipendentemente dal fatto che siano stati effettivamente emessi da quel certificato CA (o se tale CA esiste o meno). In questo modo, romperai il modello PKI in modo considerevole (altro).
Se sei d'accordo su un DN dell'Emittente come CN=Dummy CA(ad esempio). Chiunque può creare un certificato autofirmato utilizzando CN=Dummy CAcome DN oggetto (e DN emittente), possibilmente con chiavi diverse. Sebbene la SSLCADNRequestFiledirettiva preveda di essere configurata con certificati per compilare l'elenco, questi non vengono utilizzati per verificare il certificato client, ma è solo un modo complicato (ma naturale nel contesto delle altre direttive) di configurare l' certificate_authoritieselenco. Se si, come un servizio, mette un CERT auto-firmato con questi nomi in SSLCADNRequestFile, questo renderà l' CertificateRequestutilizzo di messaggi TLS CN=Dummy CAnella certificate_authoritieslista (questi sono solo nomi, non CERT in questa fase). Il cliente sarà quindi in grado di ritirare il proprio certificato con DN dell'EmittenteCN=Dummy CA, indipendentemente dal fatto che la sua firma possa essere verificata o meno da quel certificato (stesse chiavi) o meno, dal momento che in questi passaggi non è coinvolta alcuna verifica della firma.
Detto questo, ricorda che SSLVerifyCLient optional_no_casenza, non viene effettuata alcuna verifica del certificato reale (suppongo che potresti verificare la SSL_CLIENT_VERIFYvariabile se la verifica manuale è solo una soluzione di fallback a un PKI che hai configurato comunque). Tutto quello che saprai in quella fase è che il client ha la chiave privata per il certificato di chiave pubblica che ha presentato (garantito dal CertificateVerifymessaggio TLS ): dovrai eseguire una qualche forma di verifica se vuoi che ci sia l'autenticazione di alcuni ordinare. (Non puoi fidarti di nessuno dei contenuti del certificato, ovvero del legame tra la sua chiave pubblica e i nomi / attributi che contiene.)
Questo non funzionerà bene per i file, ma è possibile farlo per un'applicazione (ad esempio PHP / CGI / ... anche Java se si passa il certificato al server Java proxy). Un modo di base sarebbe quello di avere un elenco noto di chiavi pubbliche, oppure potresti guardare le idee in FOAF + SSL / WebID .