Error 0x80092103 when using DA2012 with Win7 clients RRS feed

  • Allgemeine Diskussion

  • I´m just so happy I got DA2012 with Win7 to work that I thought I have to share the solution with you guys out there. There´s no problem with Win8 Clients, all good. With Win7 Clients I always received the error 0x80092103 in the “netsh int httpstunnel show interfaces” dialog saying that the CRL is offline or not reachable or whatever. I got this error *although* we have purchased and configured a public certificate where everything is correct (name, etc). On my way through the Internet I found the following:

    Configuring CRL distribution settings

    Next, disable CRL checking by removing all the CRL distribution settings so that DirectAccess clients skip the checking the CRL of certificates. In an actual deployment scenario the CRL would needs to be published so that client certificates can be revoked when necessary.

    To remove CRL distribution settings

    1. Click Start , point to Administrative Tools , and then click Certification Authority .
    2. In the console tree, right-click corp-DC1-CA , and then click Properties .
    3. Click the Extensions tab. In Specify locations for which users can obtain a certificate revocation list, check all locations of the CRL Distribution Point (CDP) and Authority Information Access (AIA) , and verify that none of them have Publish CRLs to this location , or Publish Delta CRLs to this location selected.
    4. Click OK , click Yes to restart Active Directory Certificate Services, and then close the Certification Authority console.

    Out of: http://technet.microsoft.com/en-us/library/ee861152.aspx

     I marked the important thing in the article. It works perfectly for us. That means that you can easily use your own CA even with Win7 Clients and Win2012 DA without purchasing an expensive public certificate and without start to care about how your internal CRL gets published to the Internet.

    This “workaround” can be, but shouldn´t be the end of the story. I would encourage everybody to configure it that way: using a private AD integrated CA and publish the CRL with TMG. This will be my next step in investigation.

    Freitag, 17. Mai 2013 10:05

Alle Antworten

  • Hi

    I understand you use a private certificate for your IPHTTPS certificate right?

    Technically speaking, it works, but measure how complex is the solution and how much it cost compared to a certificate delivred from a trusted public CA. If you have a problem in your CRL publishing process (ADCS offline, IIS problem, TMG problem), your DirectAccess clients will be unable to check for crl revocation within days. You dont have to manage theses things with a certificate delivered by a public CA.

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Freitag, 17. Mai 2013 12:14
  • Dear BenoitS,

    I´m totally with you regarding complexity using a private certificate for IP-HTTPS. But I repeat myself: We *did* purchase and configure a public certificate for IP-HTTPS but: It doesn´t work!

    So i switched to private once, get rid of the CDP´s in the certificate and here we are!

    Samstag, 18. Mai 2013 08:12
  • Ok, My mistake, i read you posr too fast. That's strange that Windows 8 clients have no problem and Windows 7 has. I suppose your certificate provider is correctly registred in the operating as a trusted provider. If it's not a certificate problem it might be an operating system specific problem (GPO applied only to Windows 7 for example, ...). Did you check CERTUTIL -URL <URL of your certificate provider CDP>, this a good too to check certificate revocation problems? Did you have information in the CAPI2 event log?

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Montag, 20. Mai 2013 13:38
  • Some updates:

    1) If you are using a public certificate from GlobalSign for the IPHTTPS on the DA2012 Server you have to make sure that all Win7 Clients and the DA-Server have an intermediate root certificate with the Name "GlobalSign Domain Validation CA-G2" that must be stored in the "Intermediate Certification Authorities" Folder in the local computer store on each Win7 Client.

    2) Don´t install update from KB931125, Update for Root CA Certificates from December 2012. This will blow up your local certificate store and anything that relies on certificates may not work correctly. If you installed it, read http://support.microsoft.com/kb/2801679/en-us

    Donnerstag, 20. Juni 2013 13:40