Sign in
 
HomeProductsLibraryLearnDownloadsSupportForums
Microsoft Forefront TechCenter >
> 
> 
SSTP CRL Revocation Check Failing

Вопрос SSTP CRL Revocation Check Failing

  • Thursday, August 30, 2012 6:01 AM
     
     
    Sign In to Vote
    0

    SSTP will not initiate a connection between the remote client and the server because the CRL information is said to be unavailable. However, I have setup a CRL that is stored at http://company.com/CRL/ that is visible to both the intranet and the Internet at the same address, I have re-issued certificates to the client that contain this address, and yet I am still getting a revocation error for the connection. I am using RADIUS to perform the authentication of users with TMG as the perimeter gateway, and I was wondering if this sounds like it is an issue with the CRL just not being updated, I need to reissue the certificate on the RADIUS server, if I need to have something else enabled besides just configure TMG to accept SSTP and have the CRL configured, or if something else anything would be helpful at this point, I am banging my head against a wall a bit on this.

     

All Replies

  • Thursday, August 30, 2012 7:55 AM
     
     
    Sign In to Vote
    1

    Hi,

    please check if the client has access to the latest CRL published and if the client has access to the CRL.
    to check CRL access open the URL for the CRL CDP in your webbrowser or:
    certutil -URL http://crl.domain.de/crld/ca.crl
    Please also try to delete the CRL cache:
    certutil -URLCache CRL –delete

    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

     
  • Thursday, August 30, 2012 8:12 AM
     
     
    Sign In to Vote
    0

    Ok, so I got the Company-ROOT-CA.crl but Company-ROOT-CA+.crl will not download. I am going to work on getting that to download, but is that necessary to have as well as the normal CRL? I only ask because if it isn't I am still having the same issue. Also, of course, when it tries to download the LDAP version that is not able to happen, but for completeness I thought that I would mention that.

     
  • Thursday, August 30, 2012 8:50 AM
     
     
    Sign In to Vote
    0

    Hi,

    Company-ROOT-CA+.crl is the Delta CRL. The Client must have access to the Base CRL, access to the Delta CRL ist not mandatory required but highly recommended
    The CRL can only be downloaded via LDAP if you publish the LDAP path of the CA but this is also not required. LDAP CDP will only be used internal

    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

     
  • Thursday, August 30, 2012 9:34 AM
     
     
    Sign In to Vote
    0

    Ok, so if it is not required do you have any thoughts as to why I am still getting a revocation cannot be accessed error?

     
  • Friday, August 31, 2012 5:12 AM
    Moderator
     
     
    Sign In to Vote
    0

    Hi,

    Thank you for the post.

    If you disable the CRL check on the client, does it work? What is the detailed error message you have got? Here is troubleshooting guide for your reference: http://support.microsoft.com/kb/947031.

    Regards,

    Nick Gu - MSFT

     
  • Friday, August 31, 2012 8:02 AM
     
     
    Sign In to Vote
    0
    0x80092013 is the exact error code that I received when trying to connect my Windows 8 Pro computer. When I browse to the address entered for the CRL in the certificates, http://company.com/crl/, I am able to see that the CRL is there (I have directory browsing enabled on the web server hosting the CRL) and am able to download it from there. The same address is used internally, and again I am able to see that the CRL is there and download it internally as well. However, I am still failing the CRL check with the error code 0x80092013. Any thoughts?
     
  • Friday, August 31, 2012 9:29 AM
     
     
    Sign In to Vote
    0
    ok, so maybe I am missing this, but in the link that you provided, I was not able to find a way to disable the CRL check. However, it did point me to the fact that the certificate that I was using on the external side of TMG was not issued with the correct CRL distribution point, so I issued a new certificate for that which does have the correct distribution point. The link seemed like it was working, and then I ran into the same check issue again. However, I did check to see, and the primary CRL is available, however neither of the delta CRLs are being able to download and the IIS server is throwing back a file not found (by both I mean I have on server that hosts the CRL internally and one server that hosts it externally, but neither server's delta works all the same). So, is it possible that the issue is coming from the delta CRL not being able to be checked because of this 404 error by IIS?
     
  • Thursday, November 29, 2012 9:04 AM
     
     
    Sign In to Vote
    0

    Hi,

    I think you're experiencing the problem I had when I first set up my external CRL access.
    IIS has problems with the + sign in the filename of the DeltaCRL.

    Adding this to the web.config of the IIS should remedy that behavior.

    <configuration>
            <system.webServer>
            <security>
                <requestFiltering allowDoubleEscaping="True"/>
            </security>
        </system.webServer>
    </configuration>

    Got that from here:
    http://styletronix.wordpress.com/2011/02/12/sperrlistenverteilung-ber-iis-konfigurieren/