Apache "SSLSessionCacheTimeout" mit Client-Certs

• Die SSL-Sitzung Neuverhandlung sollten keine Auswirkungen des application-level-Sitzung. Könnten Sie etwas konkreter über das, was du meinst, wenn du "Benutzer müssen zur Authentifizierung mit einem X. 509-Zertifikat" und "eine neue Sitzung versucht werden, gemacht werden, aber nicht. Es scheitert an der Tatsache, dass die re-Authentifizierung wird nicht ausgeführt." ?
• Benutzer das erste mal anmeldet web-app | wählt Zertifikat von einer smart card | kundenspezifische Spring Security code extrahiert die notwendigen LDAP credential | erhält schließlich Zugriff auf die web-app. Allerdings, wenn die Sitzung des Benutzers abläuft, wird eine neue Sitzung erstellt werden kann (vermutlich seit dem re-Authentifizierung nicht auftreten) und der web-app stürzt ab. Ich war neugierig, ob durch die Festlegung, dass der Apache-Feld auf einen höheren Wert, wenn eine neue Sitzung konnte authentifiziert werden, wie durch den höheren Wert, da es würde, vermutlich, verwenden Sie das client-cert.
• Die Sache ist, der browser wird automatisch erneut das X. 509-Zertifikat im Falle der server (nicht der Suche nach einem match für die sessionID, die vom client gesendet) eine neue Sitzung beantragen. So, abgesehen von dem, was passiert auf application-Ebene, eine neue TLS-Sitzung-Erstellung Auftritt nach der SSLSessionCacheTimeout sollte nicht unterscheiden sich von der ersten TLS-Sitzung Schöpfung. Beachten Sie, dass dies gilt nicht, wenn der client und der server verwenden rfc5077 "Session-Wiederaufnahme ohne Server-Side-State".
• also die SSL session variiert von der HTTP session? Benutzer Authentifizierung über eine smart card durch die Wahl der richtigen cert. Nachdem die HTTP-Sitzung abläuft, wird eine neue HTTP-Sitzung wird versucht, die hergestellt werden, aber nicht. Ich denke, dass es fehlschlägt, weil es nicht erneut authentifizieren. Ich war neugierig, ob die Inkrementierung SSLSessionCacheTimeout helfen würde da, bei einer neuen session, die SSL-cert wäre immer noch herum. Mein Gedanke war, dass das SSL-Zertifikat abgelaufen war, wie pro die SSLSessionCacheTimeout, aber, wenn ich eine Erweiterung, die neue session ist erfolgreich erstellt.
• Die SSL-Sitzung wird nicht co-umfangreich mit der HTTP-Sitzung. Beide können unabhängig voneinander ablaufen. Zertifikate nicht ablaufen, wie pro die SSLSessionCacheTimeout', Sie haben den Ablauf mal in Jahren gemessen. 8 Stunden ist viel zu lang für eine SSL-Sitzung: Sie sind in der Regel in Minuten gemessen. Es ist ziemlich lang, selbst für eine HTTP-Sitzung. Es gibt viel zu viel Spekulation hier. Sie müssen aufhören, Vermutungen und Annahmen zu machen, und herauszufinden, was eigentlich passiert ist. Einige HTTP-Spuren zum Beispiel. Bearbeitet in der post.
• könnten Sie bitte lassen Sie mich wissen, was ich suchen soll mit der HTTP traces? Ich gebe zu, es ist Spekulation, aber es ist aus meiner Unsicherheit.
• interessanter wäre zu wissen, was Sie tun, in Ihre HTTP-Sitzung, wenn die SSL-cert-Sitzung ist nicht mehr gültig sein, vielleicht stürzt die app. denken, Sie sind ein finance-bank und wollen, um Ihre web-Sitzung-service sicher, was passieren sollte, um die Sitzung ab, wenn das Zertifikat nicht mehr gültig ist, was sollte der Nutzer tun ein, was niemals funktionieren in jedem Fall, wenn das Zertifikat nicht mehr gültig ist.
• Die HTTP-Sitzung nicht weiß, Wann die SSL-Sitzung verfällt. Es gibt keine solche Sache wie die "SSL-cert-Sitzung". Wir diskutieren über SSL-Sitzungen Ablauf, nicht Zertifikat Ablauf. Die HTTP-Sitzung gar nicht kennt, Zertifikat Ablauf entweder.
• Angenommen, Sie sagen uns, welches problem Sie eigentlich hat, und welche Beweise haben Sie für Sie?
• Blick auf die apache-error logs sehe ich: Re-negotiation handshake failed: Not accepted by client!?. Suchen Sie in Ihrer Antwort auf eine ServerFault post (serverfault.com/questions/410925/...), ich kann mit OpenSSL 0.9.8, die nach einem commentered auf Ihre Antwort sagt hat ein Problem mit der Neuverhandlung.

Zeige alle Kommentare