Windows 7 consent.exe attempting to access the internet

You asked 1) if consent.exe is a legitimate program, 2) if its use of the network is legit (why does it attempts to connect to an external server), and 3) if there is any reason to allow it.

Your questions (and some commentary) follow. The short answer is that it is OK, and no, you don't want to block it:

  1. Legit? Kudos for checking the genuine M$ origins of the file on your system.
    Assuming that the copy of consent.exe on your system is good, then what is it doing anyway?
    Consent, is part of the user access control (UAC) system. Among many other things, before it allows anything to run based on signatures & certificates, it wants to check to see if any certificates have been revoked.

  2. To check the revocation information consent has to 'phone a friend'. Consent does this for all of your certificates each time that it does not have current, trusted information.

  3. Can you block it from network access? Well there are 2 reasons that you may not want to do this:

    1. Going back to a really trusted root gives you a bit more safety. It is of course your choice, but as for me and my machines, we will check the root.

    2. For me, when I did not provide access to all of the Trusted Roots the UAC prompt took almost 30 seconds to come up.
      This was a mystery to me, and might be to you. I was using self-signed machine-specific code-signing certificates rooted from my machines at work. These certificates were being checked via a ROOT that was not accessible. Unfortunately, the internal work network is usually behind a firewall. This means that the revocation check has to timeout.

So in summary:

  1. Yes
  2. Yes
  3. Yes

Happy hunting.

Ah, so what did I do? I removed all of the offending certificates -- my UAC prompt now comes up faster than I can blink.


A legitimate reason for consent.exe to connect to the Internet is to figure out whether a certificate was revoked (by updating the certificate revocation list, CRL).

I was however unable to confirm this with Wireshark. Using the Wireshark filter http contains "crl" didn't give any results on my machine. This could be, because traffic encrypted.

Each certificate contains information about where that CRL list is stored:

CRL URL in certificate details