locked
TMG und Client Auth via Client Zertifikat geht auf einmal nicht mehr RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    eine TMG (aktuell gepatched) auf der ein Weblistener läuft, der Excahnge (OWA) publiziert und bei dem man sich mit einem Client Zertifikat und Benutzername/Kennwort authentifizieren muss.

    Das benutzte Zertifikat des Listeners wurde mit einem Stammzertifikat erstellt, das zwar noch gültig, nicht aber mehr das aktuelle ist (hat noch 1024) bit Schlüssellänge. Es gibt also ein neues Stammzertifikat mit einer Schlüssellänge von 4096 Bit. Die Benutzer haben inzwischen zumeist auch Clientzertifikate mit dem neuen Stammzertifikat.

    Bisher war es kein Problem, wenn Benutzer irgendein gültiges Stammzertifikat hinterlegt hatten (oder besser gesagt jenes, das zum Zeitpunkt der Ausstellung gültig war).

    Seit gestern ist das nicht mehr so. Wenn der Client nicht genau das Stammzertifikat in der Liste der gültigen Stammzertifikate gespeichert hat, mit dem das Zertifikat des Listeners ausgestattet ist, funktioniert die Anmeldung nicht mehr. Wieso auf einmal? Was kann das sein?

    Danke für Input.

    Greetings/Grüße Gernot

    • Typ geändert Alex Pitulice Freitag, 27. Dezember 2013 10:51 Warten auf Feedback
    Samstag, 21. Dezember 2013 10:16

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden

    Noch eine Ergänzung: Ich habe übrigens einen 2. Standort mit dem derselben Konstellation. Da geht das auch weiterhin noch problemlos!

    Greetings/Grüße Gernot

    Samstag, 21. Dezember 2013 10:31
  • Discussion
    Anmelden
    0
    Anmelden

    Hi,

    das alte RootCA Zertifikat wurde revoked? Die Clients hatten noch einen alten CRL Cache? Der ist jetzt abgelaufen und deswegen geht die Auth. nicht mehr?
    Was sagt denn das CAPI Logging am Client?

    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.galileocomputing.de/3276?GPP=MarcGrote

    Samstag, 21. Dezember 2013 11:26
  • Discussion
    Anmelden
    0
    Anmelden

    Hi,

    nee. Hatte ich geschrieben. Zertifikat wurde NICHT revoked. Sonst würde der 2. Standort nicht mehr laufen. Es gibt halt ein neues Stammzertifikat, damit man Zertifikate mit einer Schlüssellänge mehr als 1024 erzeugen kann.

    CAPI logging werde ich am Montag mal machen.

    Greetings/Grüße Gernot


    Sonntag, 22. Dezember 2013 14:12
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Gernot,

    hast Du Neuigkeiten?

    Gruss,

    Alex

    Alex Pitulice, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Montag, 23. Dezember 2013 13:28
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Alex,

    CAPI Logging läßt auf eine CRL tippen. Aber der Client kommt an die CRL ran! Wenn ich vom PC aus die URL der CRL aufrufe, dann kann man diese herunter laden.

    Aber das widersprich auch irgendwie der Tatsache, dass eine TMG an einem anderen Standort (mit derselber PKI) einwandfrei funktioniert...

    Greetings/Grüße Gernot

    Freitag, 27. Dezember 2013 16:22
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Gernot,

    hast du mal die Zertifikate auf den Clients verglichen?

    Von einem bei dem der connect noch erfolgreich durchgeführt werden kann zu einem der keine Verbindung herstellen kann.

    Sind hier unterschiede in der CRL URL. Oder wurden die Zertifikate vll. mit unterschliedlichen Root CA Zertifikaten ausgestellt (alt und neu, z.b. durch autoenroll (renew)).

    Würde die CRL URL geändert oder angepasst vor dem erneuern des CA Zertifikats ?

    Grüße

    Olli


    • Bearbeitet O.Schwarz Freitag, 27. Dezember 2013 23:05 add. text
    Freitag, 27. Dezember 2013 22:22
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Olli,

    ich hatte ja schon geschrieben: Es gibt alte und es gibt neue Benutzer-Zertifikate. Mache wurden mit der alten und manche mit der neuen rootCA ausgestellt. Das ist ja eigentlich immer so! Irgendwann muss man auch mal das RootZert verlängern dürfen.

    Komisch ist, dass es an einem Standort klappt!

    Es KANN also nichts mit der Revocation list zu tun haben. auch deswegen nicht, weil das neue RootZert schon 3 Monate alt ist.

    Greetings/Grüße Gernot

    Donnerstag, 2. Januar 2014 14:12
  • Discussion
    Anmelden
    0
    Anmelden

    Habe jetzt noch einmal genauer ins CAPI2 Log geschaut:

    der PC meckert tatsächlich, wenn das Clientzertifikat angewendet werden soll: Error 41 Sperrung überprüfen.

    Dort wird die URL aufgelistet und es kommt die Meldung: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

    Wenn ich diese URL im Browser aufrufe, wird die CRL brav aufgemacht. Wieso kann der Browser das nicht?

    Im 2. Schritt soll dann das Zertifikat des aufgerufenen Servers überprüft werden. Das geht auch nicht und das ist wohl das Problem:

    In diesem Zertifikat sind 2 URLs für den Zugriff auf die CRL hinterlegt. Als erstes die interne URL und als 2. die externe URL (falls man das Zertifikat extern verwendet). Lt. CAPI Log versucht der Client nur die erste URL, um die CRL zu finden! Ich dachte immer, es werden alle möglichen Verteilpunkte durchprobiert.

    Greetings/Grüße Gernot

    Donnerstag, 2. Januar 2014 15:40
  • Discussion
    Anmelden
    0
    Anmelden

    Hi,

    die Reihenfolge der CRL Pruefung wuerde ich bestaetigen. Je nach Client OS erst OCSP, dann alle CRL CDP der Reihe nach bis es zu einem Timeout kommt.

    Ob es wirklich an der CLR liegt kannst Du ja mal pruefen, indem Du den CRL Check auf einem Client deaktivierst.

    Kannst Du mit CERTUTIL auf einem Client mal checken ob die CRL erreichbar ist.

    Dann noch mal checken wie die Proxy Settings fuer WinHTTP sind. die CRL API nutzt WinHTTP um eine CRL zu pruefen, sprich, wenn es im Browser geht die CRL herunterzuladen, muss es noch nicht ueber die CRL API funktionieren

    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.galileocomputing.de/3276?GPP=MarcGrote

    Donnerstag, 2. Januar 2014 18:36
  • Discussion
    Anmelden
    0
    Anmelden


    Proxy Settings für WinHTTP sind "ohne Proxy".

    Der letzte Eintrag im CAPI2 log ist Error 81: Vertrauenswürdigkeit prüfen. Und das Ergebnis ist "Die Signatur des Zertifikats konnte nicht bestätigt werden": 80096004.

    Aber jetzt zu certutil: Wenn ich das Rootzert des Problemzertifikats ansehe und die URL der CRL mit certutil untersuche, ist alles OK.

    Aber: Wenn ich mit Certutil das Stammzertifikat lade und abrufen wähle, kommt immer:

    Status gescheitert. Falscher Aussteller der Basissperrliste. Die aufgeführt URL ist dann aber korrekt.

    Greetings/Grüße Gernot

    Donnerstag, 9. Januar 2014 15:15