Firewall Rules for Active Directory Certificate Services


 Below is a list of ports that need to be opened on Active Directory Certificate Services servers to enable HTTP and DCOM based enrollment

 The information was developed by Microsoft Consultant Services during one of our customer engagements









Certificate Enrollment Web Services



Domain Controllers (DC)


Source Certificate Enrollment Web Services

Destination: DC

Service: Kerberos (network port tcp/464)



Certificate Enrollment Web Services



Domain Controllers (DC)


Source Certificate Enrollment Web Services

Destination: DC

Service: LDAP (network port tcp/389)



Certificate Enrollment Web Services



Domain Controllers (DC)


Source Certificate Enrollment Web Services

Destination: DC

Service: LDAP (network port tcp/636)


Random port above port 1023

·       Certificate Enrollment Web Services

·        All XP clients requesting certs




Please see for details on RPC/DCOM configuration:



All clients requesting certs

Certificate Enrollment Web Services




Source: Windows 7 client



Service: https (network port tcp/443)

Certificate Enrollment Web Services

Comments (19)

  1. Dukkse says:

    For DCOM/RPC between a 2008R2 CA and 2008R2 webserver, you dont need "Random port above port 1023". Port 49152-65535 is enough.

    But if you still have one of them as 2003, you need the whole range.

  2. Dukkse says:

    If you use 2008 or later on both web server and CA, port 49152-65535 is enough.…/832017

  3. Anonymous says:

    I still get these errors on the Domain Controllers running 2008 R2 to a 2003 Enterprise CA. I have TCP 135 (RPC) open already, but I highly suspect it maybe the "Random port above port 1023" requirement as noted in the table. I hate to have to open up all ports above this. Any other way to make this a specific port? I can map the cahost computer from domain controller as \cahost and I will see CertEnroll Share.

    Event ID: 13

    User: SYSTEM

    Source: CertificateServicesClient-CertEnroll

    Certificate enrollment for Local system failed to enroll for a DomainController certificate with request ID N/A from (The RPC server is unavailable. 0x800706ba (WIN32: 1722)).

    Event ID: 6

    User: N/A

    Source: CertificateServicesClient-AutoEnrollment

    Automatic certificate enrollment for local system failed (0x800706ba) The RPC server is unavailable.

    1. TAuby says:

      Port 135 is only the port RPC advertises what various RPC-based services it supports. The actual services themselves each sit on a random port between 49152 and 65535 (for Win 2008 and above), which is why this large port range must be open (and why firewall admins hate RPC).

  4. I just removed port 440 based on the result of an internal conversation about that port not being needed.

  5. rafi says:

    Port number without specified protocol is useless. Is it TCP or UDP ?

  6. Siki says:

    Just a minor correction. Should DCOM/RPC state: "Random port above port 1023" rather than "1024". I believe RPC uses >=1024 (includes 1024).

    Otherwise, good summary.


  7. Tom Aafloen says:


    Doesn't RPC TCP 135 (RPC Endpoint Mapper) also have to be open? How else can clients find out what random port above 1023 is being used at any given time?

    It is possible to set the random port being used by the CA server to a fixed value (with DCOM, Static Endpoint), is this supported by Microsoft?

    I love this blog, keep it updated!

    Sincerly Yours

    Tom Aafloen, Sweden

  8. Lylian L says:

    Thanks a lot for your article. Not found out There !!!

  9. markus says:

    When did kerberos start using tcp/440?

    My understandin was it used tcp/88, upd/88 and tcp/464.

  10. Sycane says:

    The table data seems to only provide information for Web Enrollment, what ports are required between a requesting host and an Enterprise CA?

    Not wanting to presume anything (but without having tested) I suspect this would be TCP/135 + high ports.

    Some clarity from a point of authority would be appreciated.

  11. Walter Chomak says:

    I can submit and retrieve certs just fine with https. I have also successfully automated the process with certutil. It works perfect on a regular workgroup server – but on the same network. What must be done to do so from a workgroup machine that is outisde the network? 443 access only. THANKS!

  12. Sycane says:

    Has anyone got any relevant information regarding port usage when certificates are requested via MMC and the Certificates snap-in?

  13. Marc Puverel says:

    Following the article at the following URL:…/how-to-troubleshoot-certificate-enrollment-in-the-mmc-certificate-snap-in.aspx

    It appears that port 135 – TCP has to be open for RPC EPM. Basically for mmc and auto-enrollment scenarios.

  14. Tom Aafloen says:

    You can configure the CA server to use a static listening port for DCOM/RPC. This means that you only need to open a single port in your firewall (for DCOM/RPC). The link in the comments column above shows how to decrease the RPC/DCOM port span, but that
    affects all DCOM/RPC on that server. Isn’t it better to lock the CA service to a specific port instead?
    I’ve blogged about it here:

  15. Thomas Langner says:

    If we are using Windows 7 Clients, do we have also to open RPC and high ports to enable autoenrollment?
    Yeah, I know I can configure a single DCOM/ RPC Port, but I tought with Windows 7 443 is the only Thing we need.

  16. mike says:

    When using a Windows Server 2008 R2 client that autoenrolls to retrieve a certificate from a Windows CA, are the firewall config changes being discussed here enough to cause the client to speak RPC DCOM to the CA when asking for a certificate, or are there
    other config changes I need to make this happen ??

  17. Jayesh says:

    I am using stand alone Root and Subordinate CAs, No Ad integration..In that case what are the port requirements

Skip to main content