none
The Certificate Status could not be determined because the revocation check failed

    Question

  • In a Coexistence I reissued both Exchange 2007 Certs and a New Exchange 2010 via Entrust (using UCC's) the Exchange 2007 seems to be functioning with the new "Legacy" name but for exchange 2010 I get "The Certificate Status could not be determined because the revocation check failed" I've Tried both the PowerShell Method and the Wizard method, Added to the Domain CA, I saw 1 sad post on Exchange Experts about godaddy certs but that doesn't really apply
    Monday, October 19, 2009 9:04 PM

Answers

  • Everyone,

    Ben and I worked on the issue in his environment and have it working.  Here is what we found.

    Exchange uses WinHTTP to determine the validity of a certificate.  WinHTTP seems to use Web Proxy Auto-Discover Protocol (WPAD), so if you have a Proxy Access Control (PAC) file being specified through DHCP or DNS, it's going to pick that up and use it, regardless of what you have set up in IE for your proxy.

    If you are not using a PAC file, it's possible that WinHTTP is not configured at all with proxy settings.
    To determine which settings are currently in use by your Exchange server, log into it, start up an admin console and run the following command:

    netsh winhttp show proxy

    This should give us the current proxy info being used by Exchange.  If it's not showing the right server, you may want to try changing it using the next command:

    netsh winhttp set proxy-server="http=myproxy:88;https=sproxy:88" bypass-list= "*.foo.com"

    Ozone92 reported that the above command in Server 2008 R2 is:

    netsh winhttp set proxy proxy-server="http=myproxy:88;https=sproxy:88" bypass-list= "*.foo.com"

    Replace myproxy and sproxy with the name or IP of your own proxy server, and be sure to specify ports.  The bypass section is optional.

    I found these commands here:
    http://www.dbits.be/index.php/pc-problems/65-vistaproxycfg

    NOTE: If you can't seem to get the command to run, and keep getting a message that says "command was not found: netsh winhttp set proxy-server", you may want to copy the command above directly into the command prompt and edit it from there.  I have tried this on 3 computers, and somehow can't get it to work if I type it in, but it works fine if I paste it in, then edit it.


    Close, then re-open the Exchange Management Console and check the status of the certificate.
    If the proxy settings are correct, and it still doesn't work, try the following commands to clear the OCSP/CRL cache:

    certutil -urlcache ocsp delete
    certutil -urlcache crl delete

    Next, reboot your server, and open the Exchange Management Console back up to check the status of the certificate again.

    Let me know if I need to clarify anything, or if you're still having problems.

    -Todd
    DigiCert Support
    Wednesday, November 18, 2009 7:25 PM

All replies

  • Hi Geoff,

    Got the same issue - you didn't sort it out by any chance ?

    Thursday, October 22, 2009 4:45 PM
  • I have not, is Entrust your SSL Provider?
    Friday, October 23, 2009 3:19 AM
  • Here's a little Test it seems that both windows 7 and windows server 2008 R2 Block server revocations list try going to

    crl.entrust.net/server1.crl  in your browser and download the crl (Cretificate Revocation List this is the backend check or the otherside of thirdparty SSL's)

    hmm download works in XP (tested)
    hmm download works in Vista (tested)
    hmm download works in Server 2003/2008 (tested)
    hmm download works in Mac SnowLepord (tested)

    download blocked in Server 2008 R2 (tested on more then 1 R2 Server)
    download blocked in Windows 7 (tested on more then 1 WIN7 Workstation)

    looks to me like we've been blocked from checking our CRL's



    "It works, Trust me" lol not!
    Friday, October 23, 2009 7:22 PM
  • Hey guys, I work for DigiCert, and have seen this happen a few times now with customers of ours.  When researching the error I found this post, and thought I'd just add a possible solution. 

    In our initial testing we could see that whenever we opened up the Exchange Management Console that outbound OCSP traffic was getting generated, but that a reply wasn't making it back.  Checking the ISA server that was in front of this box showed that no traffic was actually making it out over port 80 (port used by both OCSP and the direct CRL download). 

    Using wireshark on the Exchange Server showed that the OCSP requests weren't actually going through his ISA server, but trying to use a totally different proxy.

    Our customer modified the Proxy.pac file to ensure it pointed to the right ISA server and we then removed and re-importedthe certificate (he had previously exported to .pfx), closed the Exchange Management Console, then opened it back up and everything was finally working.

    I can't guarantee that this it's the same problem you're experiencing, but I just wanted to throw that out there in case it's helpful.  In every case we've had with this it's been network related somehow.

    ***One additional troubleshooting step we tried (but wasn't directly related to our solution) is clearing the cache for CRL download and OCSP communication.
    Run from a command prompt: 
    certutil -urlcache ocsp delete
    certutil -urlcache crl delete
    (http://technet.microsoft.com/en-us/library/ee619754(WS.10).aspx talks about this)
    In theory, if it's just a caching issue, this would resolve the problem.



    -Todd
    Digicert, Inc.

    Friday, November 13, 2009 8:17 PM
  • You may also want to try adding the cert vendor's domain to the Trusted Site list in IE on that server.
    Brian Day, Overall Exchange & AD Geek
    MCSA 2000/2003, CCNA
    MCTS: Microsoft Exchange Server 2010 Configuration
    LMNOP
    Friday, November 13, 2009 8:36 PM
  • I did that Brian, now working with MS ( [REG:109110974257014] pro/Windows Svr 2008 Std AL/Windows Server and Windows 7 both rejected their trusted certificate provider revocation list) Support, the extension is blocked from download by R2 and WIN 7 clients all other clients (WIN2k3, XP WIN2K8(R1) and Vista) can download. this affects our CA as well not just our exchange server as our DC's are R2. I remember way back when we transitioned to Windows 2000 from NT an extension being block and a big hababaloo over it, the workaround then was to add the extension to the then IE6 allowed (via a REG edit) List but for the life of me I can't remember 25+ years in this industry and I tend to forget a few things...

    Saturday, November 14, 2009 12:46 AM
  • GeoffM,

    I ran a test on some of our machines at work to try to reproduce your findings but was able to download crl.entrust.net/server1.crl from Windows Server 2008 and Windows 7.  I just tried it on two Windows 7 machines here at my home and was also able to get to it.  Were all of the machines you tested on inside the same network?  I could have misunderstood something about the test you ran though, so let me know if I need to tweak my approach to be 1:1 with yours. 

    It looks like Entrust also uses OCSP as an alternative to the older CRL technology.  So your computers should be first trying to communicate to ocsp.entrust.net (or whatever is listed in the Authority Information Access Extension) over port 80 to directly query about whether or not this cert is valid.   If that fails, then I believe it falls back to directly downloading the CRL to see if it's revoked.

    You mentioned that that it's blocking extensions, does that mean that if you go to the details tab of the certificate that the extensions are not even showing up?

    Does this problem affect you browsing the internet on the affected computers?  Does it give a warning when browsing to a site protected by Entrust?  Or does it only seem to have the issue when Exchange tries to do a revocation test on the cert?

    -Todd
    DigiCert, Inc.
    Saturday, November 14, 2009 5:54 PM
  • Todd, thanks for testing your WIN2k8 was that R2? because my non R2 servers download the crl's fine all the machines are in our domain I did look thru  GP especailly after I upgraded the DC's to R2 another intresting fact is the WIN 7 clients I tested on where RC we started ungrading those this last week to Release and on those (Or Mine) I tried again and was not block from downloading the crl..

    on extensions my test was simple I put the address in IE and it would normally download the crl, on R2 the error comes up that IE can not download "Unable to download server1.crl from crl.entrust.net. Unable toopen this Intrenet site. The requested site is either unavailble or cannot be found. Please try again later."  going to ocsp.entrust.net returms  

    Welcome to the Tumbleweed Validation Authority Version 4.10

    the Problems is only Reported by the CA and Exchange it still validates our Webmail and SharePoint, we also have certs for OCS and our Public and Internal Domamins It may be rising some issuse on our 802.1x internal wireless (some users reporting not able to validte) but that may be just policy and not related.
    Saturday, November 14, 2009 7:23 PM
  • I'll have to double check our 2k8 server, I don't know for sure if it was R2 or not.  

    It's interesting that after going to the release version of Windows 7, this problem went away.  I'm not sure what to attribute that to, but the fact that it only happens when Exchange is trying to check whether the cert has been revoked or not, and not when just browsing the web implies that there is something special, or different about the way that Exchange is querying using OCSP or downloading the CRL.  It is somehow doing it differently than the browser does.
    As a side note though, the Windows 7 devices I tried it on were all release versions.

    If you have a proxy or firewall device that you can monitor traffic on, you may want to filter so you are only watching outbound traffic over port 80 from the Exchange server, then open up the Exchange Managment Console.  If things were working normally you should see traffic going out to entrust.net addresses, and replies coming back.  If you don't see traffic getting out to the internet on port 80, there has to be something wrong on the server or network that's keeping that from happening.

    With the customer I was talking about earlier, this was the case.  Because of wireshark, we knew that the server itself was sending requests on 80, but when we looked at the ISA server we could see no traffic going out.  We then looked even closer at wireshark and saw that the server was not trying to send these requests through the proxy server, but some other server.  He could browse the web and certs worked perfectly fine from within the browser too, just like you're experiencing.  The problem only occurred when he was trying to assign the cert to services in the Exchange Management Console. 
    The odds of this being the exact same problem may be slim, but from past experience, my bet is on it being a network/config issue somewhere.

    -Todd
    DigiCert, Inc.
    Sunday, November 15, 2009 3:28 AM
  • GeoffM,

    I just confirmed that our 2008 server is not actually R2.

    We've confirmed here that you can easily get a working exchange server to break and get this error by simply modifying the hosts file to redirect traffic for the URL it needs to download the CRL from to something else.

    The results do seem a little obvious, but it does tell me two things.
    1) That an interruption of the connection in any way will likely cause this
    and
    2) Exchange may only be using the CRL download method to check revocation status.
    OR
    That it will fail this test if even one of the two methods of testing revocation status fails (There are two methods commonly in use, the CRL download and compare method, and the newer OCSP method). 

    I might be able to do further testing later to see which of number 2 is right.
    • Proposed as answer by Developer_75 Friday, March 08, 2013 4:59 AM
    Monday, November 16, 2009 6:19 PM
  • Todd, you mentioned a proxy.pac file that fixed this for one person. I can't find a file by that name. Where is it located?

    I'm useing Exchange 2010 on Windows 2008 with a Digicert certificate. It is in a lab behind an ISA. As described in this thread, browsing to the sites and downloading the CRL is not a problem, but Exchange still shows this error in the EMC.
    Tuesday, November 17, 2009 6:11 PM
  • I don't know if this is relevant. I'm looking for the Proxycfg.exe program it mentions, but it is not in the system32 directory as the article indicates.

    http://technet.microsoft.com/en-us/library/bb430772%28EXCHG.140%29.aspx
    Tuesday, November 17, 2009 9:03 PM
  • Ben,

    The location of the proxy.pac file would probably be specified inside the proxy settings of IE.  If you didn't explicitly set it up to use a proxy.pac file then there probably won't be one involved at all. 
    There's got to be something else going on here with the network setup, but I'm sure we can sort it all out together.

    I think I just tracked you down in our order system and left you a voice message.  Give me a call at the number I left and we'll make sure everything sorted out.  

    -Todd
    DigiCert, Inc.

    Tuesday, November 17, 2009 10:02 PM
  • Everyone,

    Ben and I worked on the issue in his environment and have it working.  Here is what we found.

    Exchange uses WinHTTP to determine the validity of a certificate.  WinHTTP seems to use Web Proxy Auto-Discover Protocol (WPAD), so if you have a Proxy Access Control (PAC) file being specified through DHCP or DNS, it's going to pick that up and use it, regardless of what you have set up in IE for your proxy.

    If you are not using a PAC file, it's possible that WinHTTP is not configured at all with proxy settings.
    To determine which settings are currently in use by your Exchange server, log into it, start up an admin console and run the following command:

    netsh winhttp show proxy

    This should give us the current proxy info being used by Exchange.  If it's not showing the right server, you may want to try changing it using the next command:

    netsh winhttp set proxy-server="http=myproxy:88;https=sproxy:88" bypass-list= "*.foo.com"

    Ozone92 reported that the above command in Server 2008 R2 is:

    netsh winhttp set proxy proxy-server="http=myproxy:88;https=sproxy:88" bypass-list= "*.foo.com"

    Replace myproxy and sproxy with the name or IP of your own proxy server, and be sure to specify ports.  The bypass section is optional.

    I found these commands here:
    http://www.dbits.be/index.php/pc-problems/65-vistaproxycfg

    NOTE: If you can't seem to get the command to run, and keep getting a message that says "command was not found: netsh winhttp set proxy-server", you may want to copy the command above directly into the command prompt and edit it from there.  I have tried this on 3 computers, and somehow can't get it to work if I type it in, but it works fine if I paste it in, then edit it.


    Close, then re-open the Exchange Management Console and check the status of the certificate.
    If the proxy settings are correct, and it still doesn't work, try the following commands to clear the OCSP/CRL cache:

    certutil -urlcache ocsp delete
    certutil -urlcache crl delete

    Next, reboot your server, and open the Exchange Management Console back up to check the status of the certificate again.

    Let me know if I need to clarify anything, or if you're still having problems.

    -Todd
    DigiCert Support
    Wednesday, November 18, 2009 7:25 PM
  • I just wanted to say thank to Todd from DigiCert. It is very impressive for a company to seek out a customer (especially on a forum they do not own) with a problem and fix it.

    I performed the steps we worked out on my other CAS server in my lab and they worked there too. All I needed was the Netsh command and restarting the EMC. After that the cert showed as OK and I could assign it.

    It is very odd that the netsh command line does not work when typed. I keep thinking we typoed something, but I cannot see it. Anyway, copying and pasting works.
    Wednesday, November 18, 2009 7:49 PM
  • From the CA -

    C:\Windows\system32>netsh winhttp show proxy

    Current WinHTTP proxy settings:

        Direct access (no proxy server).

    From the MAIL Server

    C:\Windows\system32>netsh winhttp show proxy

    Current WinHTTP proxy settings:

        Direct access (no proxy server).

    I'm happy that I can host  a discussion on Cert issues  an love helping get frikken certs  trouble free (honestly I almost have to budget another FTE to manage the domains certs) but I'm really beggining to think this is oddly unique to infrastructure

    here's what the Support person wants me to use

    Certutil -verify -urlfetch certfilename.cer

    however this only gets what we already know we somehow have missed the issue (not you Todd)

    1) that crl.entrust.net/server1.crl is blocked only from downloading on WIN2K8 R2 Servers (I have 13 of them 8 dataCenters in 2 Hyper-V Clusters, 2 DC's, 3 Mail)
    2) that the above crl^ downloads just fine on WIN2K8 and every other WIN-OS

    I no longer believe it's a GP issue unless one ot the new GP's needs a specific value other then a default one
    our PIX/ACL's haven't changed nor has our ISA rules since the upgrade to R2 (again I must say this only affects our R2 Servers)


    Thursday, November 19, 2009 12:16 AM
  • Geoff,

    Just to make sure I understand the scenario,

    1)   Your servers are behind an ISA server, and in order to hit the internet they absolutely require Proxy settings.
    2)   When you go to a command prompt on these servers and type in "netsh winhttp show proxy", it returns results that say "Direct access (no proxy server)"?

    If these two conditions are true, then the steps I posted above should help.  The problem is that WinHTTP (the service used when Exchange needs to check CRLs) does not use standard IE settings, it uses its own proxy settings that are comletely independant.  Running that command shows what WinHTTP is set up to use, and if it shows direct access, that means there are currently no proxy settings, meaning it will not be able to hit the internet at all (again, only true if they NEED proxy settings to hit the internet).

    So if this really is the case, you will just need to run the following command to set up the proxy manually:

    netsh winhttp set proxy-server="http=myproxy:88;https=sproxy:88" bypass-list= "*.foo.com"

    Ozone92 reported that the above command in Server 2008 R2 is:

    netsh winhttp set proxy proxy-server="http=myproxy:88;https=sproxy:88" bypass-list= "*.foo.com"

    Just change the http and https proxy and port to match the correct information.  The bypass setting is only optional.  I noted above, but for some reason I could never get the command to work unless I copied straight from a web browser, pasted it into the command prompt, then edited it from there.

    When Ben and I worked on his issue earlier today, all he had to do was enter that command, then close and open the Exchange Management Shell again and it worked.

    I really hope this is the same problem you're having, and this is helpful.

    -Todd
    DigiCert Support

    -edited to include additional information supplied by Ozone92
    Thursday, November 19, 2009 1:52 AM
  • We use a ISA server inside for reverse proxy for workstaion computers and another ISA in our DMZ for publishing, and a PIX Firewall for the Entire LAN/VLAN certain servers/services bypass ISA and are secured through the ACL on the PIX

    In working with Support today we have come to a test partial solution - I'm going to clear out the current certs on the CA and Exchange (only the UCC Certs) revoke them at entrust and reissue ...
    Friday, November 20, 2009 2:54 AM
  • Thanks for the help Todd, this solved my issue with one change to your netsh command.  Using server 2008 R2 the command is:

    netsh winhttp set proxy proxy-server
    Monday, December 21, 2009 11:05 PM
  • Thanks for the follow up Ozone, I modified my two earlier posts to include your findings.
    -Todd DigiCert Support
    Tuesday, December 22, 2009 2:17 PM
  • Ozone92 reported that the above command in Server 2008 R2 is:

    netsh winhttp set proxy proxy-server="http=myproxy:88;https=sproxy:88" bypass-list= "*.foo.com"

    -----------------

    I'm also having the same problem, my Server is 2008 R2.

    The above command works for me -- it solve the "Revocation failed" issue for my certificate.

    I found out that you need to include your AD domain name in the bypass-list, else your EMC won't be able to connect to the Exchange Server.

    This is the command I used:

    netsh winhttp set proxy proxy-server="http=myproxy.mydomain.com:8000;https=myproxy.mydomain.com:8000" bypass-list= "*.myADdomain.internal"

    I guess you may not need the bypass list if your proxy.pac already include a bypass for your internal
    AD domain, which is not in the proxy.pac in our case. I don't have access to my proxy server so I can't verify this. can someone verify this?

    Anyways, Thanks to Todd and the rest for the help.


    Tuesday, January 12, 2010 10:00 AM
  • - Another update -

    I just worked with another customer of ours that had this same problem. 

    The server was originally behind a proxy, but no matter what we did, we could not get it to verify the certificate.  We then removed all winhttp proxy settings (the netsh winhttp show proxy command reported that no proxy was configured) and moved the server from behind the proxy so it had unrestricted access, but it still wouldn't work.

    Through packet traces, our customer found that it was still trying to go through a proxy, even though the show proxy command reported that it had direct access to the internet.

    In the end, our customer put the server back behind the proxy and set the bypass list to include any and all domains used for OCSP or CRL checks (this could be *.digicert.com, *.entrust.net, *.verisign.com, etc).

    Doing this got things working for him.

    Good luck to anyone still working through one of these issues,

    -Todd
    DigiCert, Inc.
    -Todd DigiCert Support
    • Proposed as answer by MrEZEKIEL Monday, March 19, 2012 3:52 AM
    Thursday, March 11, 2010 6:25 PM
  • Hi @all!

    We had the same problem with a GoDaddy-cert today. Our solution had something to do with the proxy as well. There was a Astaro FW/Proxy in front of the Exchange server - in combination with Exchange 2007 this was no problem at all - just with Exchange 2010 there was a problem.

    The solution was to uncheck the "search automatically for proxy servers"-checkbox in the IE configuration. With this flag set, there was a login-box showing up, when not logged in as the administrator. Without this flag, everybody (including the Exchange service account) could access the Internet.

    Cheers,

    Andre

    Monday, March 29, 2010 7:44 AM
  • Had this problem on Exchange 2010 on Server 2008 R2, but it was because I had failed to install the Intermediate Cert.  Our cert is from certificatesforexchange (which is godaddy using starfield).  I went to IE > Internet Options > Content tab > Certificates > Intermediate Certification Authorities tab > Import... and imported the PKCS #7 intermediate certificate.

    Posting this in case somebody else, like me, is not being thorough.

     

    Tuesday, March 30, 2010 6:37 PM
  • I have the same problem.

    My design:

    2 x Cas/Hub servers running windows 2008 R2 ent with MS NLB

    2 x Mailbox servers running windows 2007 r2 stand

    I currently have a MS support call open as well a a support call with Digicert.

    I have tried everything outlined above.

    From what we can see we are NOT seeing any traffic on port 80 exiting the interface when completeing a certifcate request. We have used wire shark and MS Network monitor to insect packets. OCSP uses port 80. it should NOT be on any other port.

    I have also setup an internal CA and experinced the same error result.

    I have also tried diabling MS NLB and all other NIC except for one to determine if traffic is exiting the wrong interface. Result - No diffrence, still the same error and no syn for port 80

    " The Certificate status could not be determined because revocation check failed"

    As far as i am concerned this is a bug with Exchange 2010!

    What i am trying to determine - is this is a bug with Windows 2008 Ent R2 only or do we experince the same problem in Windows 2008 ent.

    I am now building another box running 2008 ent only. I will try the same cert request process. Will let you know how i went.

    Any thoughts is welcomed on this.

    MS support call #: 110032425585613

    PS: if this is a bug in exchange 2010 can i get a refund on my support call??

     

     

    Thursday, April 08, 2010 3:35 AM
  • ***UPDATE***

    This has to be a Microsoft bug! More specifically related when combining the HUB Transport and CAS roles on teh same server!

    I have built a 3rd CAS/HUB server running 2008 Enterprise.

    I have performed a certicate request, processed it through digicert, then completed the pending request. I still recive the same error:

    "The certificate status could not be determined becuase the revocation check failed"

    After seeing the above error (AGAIN) i then performed the following command:


    certutil -verify -urlfetch c:\digicert.cer >cert1.txt

    The above command will perform a manual revocation check on your cert. In my case, the cert in the command is my exported cert from my server. The Cert from my server is the "completed cert request"  that was sent from digicert.

    In short i am testing the imported cert from digicert that i have exported to the filename 'digicert.cer'

    Once you have run the command, open the cert1.txt file and verify the crl have been verified or failed.

    In my case, all the crls and OCSP are verified and ok. The only one that gave me an error was an ldap one, but i have been told by MS to ignore it.

    This proves the revocation is OK and that Exchange is lying to me! Exchange uses winhttp to verify cert revocation. For some reason it isnt working.

    We have tried setting a proxy and it still fails. winhttp is set to direct internet access.

    I am clutching at nothing now, and to be honest i am quite over it!

    I have an esculated support ticket from Microsoft. I have not herd from any of their esculated support staff in China for over 5 days now.

    Microsoft, you need to pull your finger out here!

    Again, here is my support call. Please feel free to add to it you you are experincing the same problem:

    11003242558561

    PS: this is a bug in exchange 2010 i would like a refund on my support call!!

     

    • Edited by Chucky_au Wednesday, April 14, 2010 5:15 AM edit
    Wednesday, April 14, 2010 5:13 AM
  • Hi Chucky_au,

     

    Was having the same issues as you, did a manual revocation and returned no errors, but exchange management console didn't think it was valid. 

    Turns out, even though it thought it was valid going through the proxy when you do the manual revocation, it wasn't. I allowed http for the cas server straight out to the internet and it performed the revocation fine... 

     

    hope this helps.

     

    Ewan

    Monday, April 19, 2010 1:42 AM
  • Hi Chucky_au,

     

    Was having the same issues as you, did a manual revocation and returned no errors, but exchange management console didn't think it was valid. 

    Turns out, even though it thought it was valid going through the proxy when you do the manual revocation, it wasn't. I allowed http for the cas server straight out to the internet and it performed the revocation fine... 

     

    hope this helps.

     

    Ewan

    Monday, April 19, 2010 1:42 AM
  • Hi Ewan,

     

    Cheers for the reply.

     

    Interesting to hear about the http thing. Can you tell me when you say allowed http are you reffering to the winhttp proxy setting its self. For example, winhttp by default is configured for dirrect internet access.

    My call has been esculated again to Microsoft. To be honest i think it has been thrown to another call centre in another country as i am having to go through all the basic configuration trouble shooting again.  This is a very very slow troubleshooting process.

     

    Monday, April 19, 2010 2:01 AM
  • Thanks for this, setting proxy for winhttp resolved for me.

     

    Here is the KB article: http://support.microsoft.com/kb/979694

    Thursday, May 13, 2010 11:15 AM
  • Hi guys,

    I have the same issue.

    Exchange 2010 on Windows Server 2008 R2 with a DigiCert (SAN)

    This is what I have tried:

    - Customer use IE proxy, have tried to remove that and use it together with the underneath settings.
    - netsh winhttp set proxy proxy-server="http=<proxyip>:8080;https=<proxyip>:8080" bypass-list="*.corp.company.com;*.company.com;*.digicert.com" (corp.company.com is the AD domain)
    - certutil -urlcache ocsp delete & certutil -urlcache crl delete and restarted the server
    - netsh winhttp reset proxy so its back to auto
    - requested a new cert and imported it...

    How do i do a manual revocation check?

    I have struggled with this issue for 3 days now...

    Please help me out!

     

    Edit:

    If I use the certutil URL Retrieval Tool i get this:

    Certs (from AIA) - http://www.digicert.com/CACerts/DigiCertHighAssuranceCA-3.crt - OK
    CRLs (from CDP) - http://crl3.digicert.com/ca3-2010d.crl - OK
    OCSP (from AIA) - http://ocsp.digicert.com - Failed
    CRLs (from CDP) - http://ocsp.digicert.com - Success

     

    With IE proxy and winhttp as default value direct access...

     


    ftornell | Personal Blog: http://www.logicspot.NET
    • Edited by [fredrik] Thursday, May 27, 2010 9:09 PM
    Thursday, May 27, 2010 7:49 PM
  • ftornell,

    I think part of the problem may actually be having  *.digicert.com in the bypass list.  There was one person that was able to get it to work by adding it into the bypass list, but it was a very specific scenario where they didn't actually have a proxy, but it was picking settings up from somewhere, so telling it to not try to send traffic destined for *.digicert.com through the proxy fixed the issue.
    The reason we normally do not want *.digicert.com in the bypass list is because that would tell winhttp to not use the proxy to communicate with digicert sites, which essentially means it wouldn't leave the network at all.

    You will probably want to clear your proxy settings first:
    netsh winhttp reset proxy

    Next, set the proxy again, making sure that the bypass has *.internaldomain.lcoal and *.servername.internaldomain.local.  Microsoft's article about this lists only the *servername.internaldomain.local being required, but it won't hurt to have both.

    netsh winhttp set proxy-server="http=PROXYNAME:88;https=SECUREPROXYNAME:88" bypass-list= "*.FQDN;*.NAME.FQDN"

    Next, clear the cached certificate information:
    certutil -urlcache ocsp delete
    certutil -urlcache crl delete

    Finally, just reboot the server and try again.

    If it's still not working, give us a call using our number on our website.


    -Todd DigiCert Support
    Thursday, May 27, 2010 9:06 PM
  • Hello

    I'll just mention that I had the same problem for a migartion last week, and that we all try the solutions mentioned. I by pass the proxy too.
    In our case is that the firewall allowed only the port 80 and 443 and 25. But it seems that we must open other ports, since we opened all the ports out and everything was working.

    Maybe it not the same ting but for me it working

    Monday, May 31, 2010 10:43 AM
  • Running 2x HUB,CAS,Mailbox servers on Server 2008 R2.

    I also had to change the winhttp proxy settings.

    On the MS KB article for this particular issue states that only the HTTP string needs to be entered and it doesn't mention anything about ports, this is wrong, the HTTPS string ALSO needs to be entered as in DigiCert Todd's top post and also the ports (if you use them).

    Another lovely unclear MS KB.

    FYI my complete command:

    netsh winhttp set proxy proxy-server="http=172.16.16.100:8080;https=172.16.16.100:8080" bypass-list="172.*;*.mydomain.com;*.local".

    After fiddling around, taking bits out and putting bits back in, it finally worked, i didnt even have to close and re-open EX2010 MMC.

    I can now assign Assign Services to my Cert, yay i havnt wasted $400!

    James.

    Tuesday, June 01, 2010 2:34 PM
  • For those among us who are experiencing a similar problem with a certificate generated from an Active Directory Certificate server, you might want to check your CRL distribution point.
    Probably only LDAP has been activated. You should also setup HTTP for Your CDP

    All info can be found here, including instructions on how to activate HTTP for your CDP:
    Http://xmstechnology.glve.be/archives/100

    Wednesday, June 30, 2010 2:24 PM
  • I had same issue.  Although I have an ISA 2006 proxy running, I do allow direct access through my firewall.  I did the winhttp show proxy and it always said direct connection.  I discovered after that for some reason all winhttp traffic was going through the ISA 2006...even though I specified no proxy direct connection.

     

    My workaround was to add a rule in ISA 2006 that allowed all users and anonymous users access to my certificate issuer (for me it was *.godaddy.com). Once i did that the certificate showed perfectly fine in Exchange console.

     

    Hope that helps others with an ISA server.

    • Proposed as answer by ThomasIsr Saturday, June 02, 2012 7:10 PM
    Wednesday, August 18, 2010 6:17 PM
  • I just wanted to add that a similar issue exists on Windows 7 when a proxy is in use.  Windows 7 clients will attempt to use OCSP/CRL but won't use the proxy settings in IE (if they are manually set).  This results in slow loading of https pages that use certain certificates as the Win 7 client attempts to check on the cert but doesn't use the proxy, so it fails.

    Opening our firewall was not a sutiable solution.  If you use "Automatically detect settings" in Internet Explorer with a sutiable wpad.dat file placed on an IIS or ISA box then winhttp will use the proxy settings specified.

    We also noted that we had to delete the user profiles on the Windows 7 client before IE's automatic config would work correctly.

    This site was very helpful with regards to the configuration http://techblog.mirabito.net.au/?p=21

     

    Tuesday, September 14, 2010 6:58 AM
  • FALCC: I am having the same issue.  My workaround worked for exchange 2010 certs...however my IE8/Win 7 machines all seem to get the certificate error when they go to ssl sites.

     

    Can you provide more info on how to eliminate the issue?? Thanks

    Tuesday, September 14, 2010 7:51 PM
  • I can add one more possible reason for getting this error: wrong date on the server clock. When I rebuilt the server and brought it back up after a crash at 2:00 A.M., I checked the time and it was correct so I didn't pay any attention to the date. After a day and a half of getting this "revocation check failed" error, I finally noticed that the date was wrong. After changing the date, all was well again.
    Saturday, October 02, 2010 6:47 PM
  • Just for information, somebody may find useful.

    In case you use Symantec Backup Exec for Exchange, in order to do any restore, you have to reset proxy (netsh winhttp reset proxy) before running restore. After you finish, you can set it back.

    Sunday, October 03, 2010 9:18 AM
  • Hi I use GoDaddy's certs what step suggested above I did try but not working at all
    Monday, May 02, 2011 8:51 PM
  • Hi Everyone,

     

    I have just completed troubleshooting this issue for a GoDaddy UC certificate. These are the steps that I followed.

     

    Infrastructure is built on Win 2008 R2 SP1 using Exchange 2010 SP1

     

    Install GoDaddy UC Certificate on exchange 2010

    1.       Configure winhttp proxy.

    Netsh winhttp set proxy proxy-server=”http://proxyaddress:port;https://proxyaddress:port” bypass-list= “*.internaldomainname”

    2.       Install Intermediate Certificates

    Open MMC and launch certificates

    Browse to intermediate certificate store and import “gd_iis_intermediates”

    3.       Disable “Go Daddy Class 2 Certification Authority” certificate in the Trusted Root CA Store.

    4.       Disable  “Starfield Class 2 Certification Authority” certificate in the Trusted Root CA Store.

    5.       Import-ExchangeCertificate -Path "certificatepath.crt"

    6.       Enable-ExchangeCertificate -Thumbprint [thumbprint] -Services "Required Services"

     



    Tuesday, May 24, 2011 6:17 AM
  • Thanks to Digicert Todd and tantl for solutions

    On our Exchange 2010 sp1 and Windows 2008 R2 this worked:

     

    netsh winhttp set proxy proxy-server="http=myproxy.mydomain.com:8000;https=myproxy.mydomain.com:8000" bypass-list= "*.internalDomain"

    where *.internalDomain is your domain, I had to bypass this for winhttp proxy to work.

     

     

    Monday, June 06, 2011 4:06 AM
  • In some cases, for whatever reason, perhaps your CAS server does not have Internet access,

    You can still assign it through the Exchange Management Shell. If you need to enable the certificate that’s in the RevocationCheckFailure status, you can use the Enable-ExchangeCertificate cmdlet from the shell. The EMC is more restrictive in how it treats certificates with a failed revocation check. It errs on the side of caution to prevent a revoked certificate from being assigned to a service, and thus impacting service.

    See the following Link regarding "EMC and certificates with failed revocation checks in Exchange 2010"

    http://blogs.technet.com/b/exchange/archive/2010/07/26/3410505.aspx

     


    Noel Stephenson Microsoft AD & Messaging Consultant MCSE, MCITP, MCTS
    Wednesday, July 06, 2011 7:41 PM
  • Hi Guys,

    facing the same issue. i have tried setting the proxy through netsh howvever no luck. also when i set up https proxy through netsh, i cannot connect to management console, even though i set the local server in the bypass-list.

    also did a restart or the server.

     

    any ideas?

    Monday, July 25, 2011 2:11 AM
  • I am having the exact same issue as stated by Todd.

     

    I tried the commands to no avail.

     

    To fix this issue we had to modify the host file on both CAS/HUB servers to:

    127.0.0.1 wpad.domain.com

    127.0.0.1 wpad

     

    Thanks

     

     

    • Proposed as answer by spirouzbe Thursday, August 25, 2011 2:48 PM
    Wednesday, August 17, 2011 3:28 PM
  • Hi,

    Wanted to add to this with the solution to my issue.  Again along the same lines as everyone else but my enviornment needed the winhttp defined as there was a proxy environment that was not defined for the CAS servers.

    Server 2008R2

    netsh winhttp set proxy proxy-server="http=10.1.41.30:3128;https=10.1.41.30:3128"

    No bypass just the defination and all was good.


    Regards Peter
    Sunday, September 18, 2011 3:14 AM
  • Hi,

    Please review the post:

    http://blogs.microsoft.co.il/blogs/yuval14/archive/2011/09/20/how-to-resolve-exchange-2010-error-message-the-certificate-status-could-not-be-determined-because-the-revocation-check-failed.aspx

     

    Thanx


    בברכה, יובל סיני, יועץ טכנולוגיות, אתר אינטרנט: http://www.ben-shushan.net Blog: http://blogs.microsoft.co.il/blogs/yuval14/
    Thursday, September 22, 2011 11:00 PM
  • - Another update -

    I just worked with another customer of ours that had this same problem. 

    The server was originally behind a proxy, but no matter what we did, we could not get it to verify the certificate.  We then removed all winhttp proxy settings (the netsh winhttp show proxy command reported that no proxy was configured) and moved the server from behind the proxy so it had unrestricted access, but it still wouldn't work.

    Through packet traces, our customer found that it was still trying to go through a proxy, even though the show proxy command reported that it had direct access to the internet.

    In the end, our customer put the server back behind the proxy and set the bypass list to include any and all domains used for OCSP or CRL checks (this could be *.digicert.com, *.entrust.net, *.verisign.com, etc).

    Doing this got things working for him.

    Good luck to anyone still working through one of these issues,

    -Todd
    DigiCert, Inc.
    -Todd DigiCert Support

    I'am seeing exactly the same thing but now on our Windows 7 pc's.

    We have a proxy, but this requires authentication and http/1.1 and for some reason the pc's are trying to connect with http/1.0 and authentication failes.

    We opened up port 80 and 443 for the pc's and I used the netsh winhttp reset proxy command. The proxy config displays it's now Direct Access, but when running a wiretrace I see it is still connecting to the proxy. Rebooting the computer doesn't seem to work either.

    Is it possible to force WinHttp trafic to Http/1.1 bij a GPO?

    Tuesday, April 24, 2012 2:56 PM
  • IlyaD's suggestion of allowing unauthenticated access through ISA server to *.godaddy.com worked brilliantly. Combined with netsh winhttp set proxy ... (not really sure if that was actually necessary, but it was active when it went through)
    Saturday, June 02, 2012 7:13 PM
  • how can i know if my exchange server does not use proxy server

    Thursday, June 21, 2012 4:59 PM
  • Thanks very much for this - cant believe 2 years on this is still an issue.

    rob

    Thursday, August 23, 2012 11:19 AM
  • Hi Todd, i can see a nice discussion here but i want to see if you can help with my case my setup as follow: i have my Exchange servers connected directly to the internet through NAT and i have ISA 2006 as a proxy server but not configured in the Exchange servers and my SSL certificates was working fine on all servers and suddenly it stopped working and give me the error 'The certificate status could not be determined because the revocation check failed.' nothing changed the only change that my ISA team add proxy per users so when i connect to Exchange with my user account i start getting errors and after they remove me from that proxy group i still having errors and when i configure Winhhtp configuration and create ISA rule to allow Winhttp traffic the certificate error disappear but the problem that we want it to work as before without winhttp configuration another problem that i have a Hybrid server for Office 365 migration and it's not working when i use winhttp settings so my question is 1- do you have any clue what happened. 2- how can i check from where Exchange server getting this proxy settings as when i ran the command netsh winhttp show proxy it give me Current WinHTTP proxy settings: Direct access (no proxy server). Thanks

    Tarek Khairy

    Sunday, November 18, 2012 11:37 AM
  • We use a transparent Web-proxy and we only added digicert.com to our whitelist, waiting a few minutes and then restart EMC to have everything working.

    Regards,

    Kristian Eklund,

    Secure Networks Sweden AB

    Monday, December 02, 2013 10:11 AM