Entweder hast Du meine Frage falsch verstanden oder ich Deine Antwort.
Wie ich eine Webseite mit einem Zertifikat bestücke um https Verbindungen anzubieten weiss ich. Was ich aber möchte ist, dass ich auf meinem Rechner ein Client Zertifikat installiere und wenn ich die Webseite aufrufe dieses überprüft wird. Ob wird dies Two Way SLL-Handshake oder Mutual Authentication genannt.
Die Idee dahinter ist, dass ich beispielsweise Login Pages von Webapplikationen, wie zum Beispiel WP Admin Page, nur für mich aufrufbar mache. Mir ist bewusst, dass ich dies über die .htaccess mittels Benutzer/Passwort machen kann, aber finde dies halt sehr unschön. Ein Client Zertifikat ist wesentlich eleganter und würde mir allenfalls auch die Möglichkeit bitten API zu schützen.
Hab es in der Tat falsch gelesen und bin von einem TLS/SSL CERT für https ausgegangen.
Bei deinem Thema hab ich leider keine Erfahrung, bzw. hab das noch nie ausprobiert.
Hab es in der Tat falsch gelesen und bin von einem TLS/SSL CERT für https ausgegangen.
Bei deinem Thema hab ich leider keine Erfahrung, bzw. hab das noch nie ausprobiert.
Kein Problem. Trotzdem vielen Dank für Deine schnelle Antwort.
kommt drauf an wer alles darauf zugriff haben soll, ich verwende fuer einen sehr kleinen benutzerkreis selbst signierte zertifikate, eigene ca. certs sind 10 jahre gueltig und wildcard unbegrenzt
das ca muss ins linux/windows import werden (einmal)
das client-cert muss je nach browser in browser oder lx/win importiert werden (einmal)
server cert erstellen mit domain als parameter.
grad noch nee readme geschrieben.
https://www.teanet.org/downloads/tn_bash_example-0.2.1.tar.xz
die 2 scripte rufen openssl auf.
apache2 prueft dann obs client cert und server cert von der gleichen ca sind.
wenn du grossen benutzer kreis hast waere ssl dienstleister vlt einfacher
Mag sehr wohl sein, dass dies mit einem Webhosting nicht möglich ist.
Ich wüsste nicht, wie du das CA-Cert deiner eigenen CA in den NC Webserver reinkriegen solltest.
Client Cert Auth mache ich ausschließlich mit eigener CA.
Hi,
ich habe leider keine .htaccess Konfiguration zum Testen, aber die notwendigen Optionen sind laut Apache Dokumentation (https://httpd.apache.org/docs/2.4/mod/mod_ssl.html) auch via .htaccess anwendbar - allerdings weiß ich nicht, ob hier Netcup Restriktionen implementiert, welche die möglichen Optionen einschränken!
Das CA File, welches der Server nutzt, um die Clientzertifikate zu verifizieren (sofern du nicht `SSLVerifyClient optional_no_ca` setzt - was relativ sinnlos wäre, außer, dass es es dem möglichen Angreifer einen Stein in den Weg lelgt), müsste dann in dem Webroot Verzeichnis abgelegt werden, und mit entsprechender Pfadangabe verwiesen werden - bin mir nicht sicher, ob das .htaccess bei Netcup relative Pfadangaben unterstützt - aber das kann man sicherlich testen.
Die nötigen Optionen, mit CA Validation, sollten sein:
SSLVerifyClient require
SSLCACertificateFile <path to file> #alternativ SSLCACertificatePath wenn du kein konkateniertes File hast, wobei ein solches einfach zu erstellen ist
SSLVerifyDepth <integer> #wenn du ein oder mehrere Intermediary Zertifikate zur Ausstellung deiner Clientzertifikate nutztkönnte ich auch nur den CN-Name als Kriterium nehmen.
Eine solche Apache httpd Option ist mir nicht bekannt.
Edit: anscheinend kann man mit Variablen die Daten aus dem präsentierten Clientzertifikat auslesen und via `SSLRequire` erforderlich machen, das scheint mir aber komplex und könnte ebenfalls von Netcup limitiert sein.
könnte ich auch nur den CN-Name als Kriterium nehmen.
Der Server liest das cert aber m.W. nur dann aus, wenn die CA in der Config über sslcacertificatefile validiert wird.
Allerdings ist meine letzte Client Auth Config von 2011 und noch mittes Fake Basic Auth...
Aber wie es der Zufall will, bin ich auch gerade dabei, das ganze mal upzudaten und mich wieder am Umschaun.
[…] die notwendigen Optionen sind laut Apache Dokumentation […] auch via .htaccess anwendbar […]
Das trifft aber leider nicht auf SSLCACertificateFile zu, das ist nur nur in der Server Config oder einem vHost erlaubt. 
Das trifft aber leider nicht auf SSLCACertificateFile zu, das ist nur nur in der Server Config oder einem vHost erlaubt.
Ups! Mein Fehler, da habe ich schlecht geguckt. Dann funktioniert wohl doch nur die `optional_no_ca` Variante - mit der einzigen Möglichkeit es ein wenig durch komplexe if-Klauseln mit zig Variablen in `SSLRequire` einzuschränken (wenn, wie oben geschrieben, die Variablen vom Netcup httpd auch aufgelöst werden).
wenn, wie oben geschrieben, die Variablen vom Netcup httpd auch aufgelöst werden
Ich bin auf deine Berichte gespannt. 
Ich bin auf deine Berichte gespannt.
Ich berichte gar nichts, habe kein Netcup webhosting.
Bislang hatte ich noch keinen Erfolg
Dann löchere doch mal autoyast, wie genau er das mit den
if-Klauseln mit zig Variablen in `SSLRequire`
genau meint.
Wenn das WebHosting keinen Zugriff auf die vHost-Config des Apache zulässt, und man somit weder SSLCACertificatePath noch SSLCACertificateFile konfigurieren kann, dann kann der Server im "client certificate request" des TLS-Handshakes dem Client keine CAs vorschlagen denen er vertrauen würde.
Das führt wiederum dazu, dass die mir bekannten Web-Browser den Benutzer weder dazu auffordern ein Zertifikat zu wählen, noch wählen sie selbst eines (AutoSelection).
Da hier ja gewünscht ist einen Browser als TLS-Client zu verwenden, wird ein Aktivieren von SSLVerifyClient mit "optional_no_ca" also nicht zum Ziel führen - der Client wird kein TLSClientAuth-Zertifikat benutzen.
Möglicherweise bekommt man so ein Szenario hin, indem man OpenSSL s_client als Client benutzt und mit den entsprechenden CmdLine-Argumenten diesen dazu "hinprügelt" dennoch ein Client-Zertifikat zu benutzen. Aber das ist hier ja wohl nicht der gefragte UseCase.
Und TLS-Client-Auth ohne Validierung des Zertifikates ist schlicht nur Security-by-Obscurity, da ist ein HTTP-Basic-Auth mit ausreichend langem Secret (das man im Kennwortspeicher des Webbrowsers oder wo auch immer hinterlegt) sicherlich zu bevorzugen.
