none
Implications of placing issuing CAs behind a firewall?

    Question

  • Hi Everyone,

    I'm interested in opinions as to whether placing issuing CAs behind a firewall is recommended best practice, and what the challenges and pitfalls are!

    The background is that the company where I work is looking at implementing a 3-tier PKI based on Microsoft Certificate Services 2008, along with a centralized certificate and encryption management solution.

    A recommendation from consultants is that the issuing CAs be placed behind a firewall, as this would help in securing them from internal compromise. This would be in addition to other measures such as HSMs.

    Now - I can see some issues with placing the issuing CAs  behind a firewall:

    • Difficulty in the issuing CAs communicating with Active Directory through the firewall
    • Autoenrollment would not work - eg for domain controller certficates ?
    • Tools such as certutil, certreq and the certficates MMC would not work remotely (I assume they use RPC?). Some of these are useful for troubleshooting.
    • The Certification Authority MMC would not work remotely - would need to be run on the  issuing CA - not necessarily a bad thing :)

    I understand that Windows 2008 certficate services supports a firewall friendly protocol (SCEP), though I believe (speaking under correction) that clients have to be Windows Vista and above to support this?  Most of our estate is Windows XP clients and Windows 2003 servers/domain controllers.

    I would value any thoughts from the group on this.  Are the concerns I have above valid?

    Best Wishes

    Peter

    Monday, February 20, 2012 1:41 PM

Answers

  • Your consultant should be familiar with the port requirements of deploying CAs behind firewalls. I have done this at numerous clients, and if you know your port ladders, it is an easy process. If you consultant does not know how to do this, I would be looking at a different consultant <G>.

    Now, looking at your questions

    1) You can lock the CA to us a signal port (rather than a range of ports) for certificate issuance (after connecting to TCP 135 the RPC port mapper)

    2) Autoenrollment will work with correct port assignments

    3) All command line tools will work from the network segments allowed RPC/DCOM connectivity to the issuing CAs

    4) For the CA MMC, I typically have the users connect to the CA using RDP. The option to allow RPC access would swiss cheese the firewall

    5) As Vadims stated, SCEP enrollment is not supported by XP and 2003 clients (nor Vista or Windows 7)

    6) If you deply Windows Server 2008 R2 (instead of Windows 2008) then you could use CEP/CES to allow external enrollment. My company has created a CEP/CES client for Windows XP/Server 2003/Vista/Server 2008 called CertDeploy (www.certdeploy.com) that allows enrollment through firewalls using CEP/CES (this means internet connected and non-domain joined scenario)

    Bottom line, you consultants should be aware of all of this. If they are not, look to other consultants. <G>

    Brian

    :

    • Marked as answer by pb3000 Monday, February 20, 2012 4:40 PM
    Monday, February 20, 2012 4:07 PM
  • you can put CA server behind firewall, but allow required protocls (LDAP, kerberos, enrollment and, possible, management).

    BTW, SCEP is a protocol for devices, such smartphones, network equipment (switches, routers) and so on. SCEP client is not supported by Windows operating system.


    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Windows PKI reference: on TechNet wiki

    • Marked as answer by pb3000 Monday, February 20, 2012 4:36 PM
    • Unmarked as answer by pb3000 Monday, February 20, 2012 4:41 PM
    • Proposed as answer by Brian Komar [MVP]MVP Monday, February 20, 2012 4:48 PM
    • Marked as answer by pb3000 Monday, February 20, 2012 5:05 PM
    Monday, February 20, 2012 1:52 PM
  • just to note. This article describes how to lock AD CS to use single port for DCOM connections (DCOM is used for both, enrollment and administration protocols): http://social.technet.microsoft.com/wiki/contents/articles/how-to-set-a-static-dcom-port-for-ad-cs.aspx

    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Windows PKI reference: on TechNet wiki

    • Marked as answer by pb3000 Wednesday, February 22, 2012 7:48 PM
    Monday, February 20, 2012 5:29 PM
  • The Microsoft PKI Team has blogged about ports that are needed to be open on an CA server:

    http://blogs.technet.com/b/pki/archive/2010/06/25/firewall-roles-for-active-directory-certificate-services.aspx

    Althought they have missed port TCP/135 in the table. I've noted that in the comments over a year ago, but it hasn't been added to the list.


    Tom Aafloen, IT-security Consultant Onevinn AB

    • Proposed as answer by Tom Aafloen Wednesday, February 22, 2012 10:38 AM
    • Marked as answer by pb3000 Wednesday, February 22, 2012 7:48 PM
    Wednesday, February 22, 2012 10:29 AM

All replies

  • you can put CA server behind firewall, but allow required protocls (LDAP, kerberos, enrollment and, possible, management).

    BTW, SCEP is a protocol for devices, such smartphones, network equipment (switches, routers) and so on. SCEP client is not supported by Windows operating system.


    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Windows PKI reference: on TechNet wiki

    • Marked as answer by pb3000 Monday, February 20, 2012 4:36 PM
    • Unmarked as answer by pb3000 Monday, February 20, 2012 4:41 PM
    • Proposed as answer by Brian Komar [MVP]MVP Monday, February 20, 2012 4:48 PM
    • Marked as answer by pb3000 Monday, February 20, 2012 5:05 PM
    Monday, February 20, 2012 1:52 PM
  • Your consultant should be familiar with the port requirements of deploying CAs behind firewalls. I have done this at numerous clients, and if you know your port ladders, it is an easy process. If you consultant does not know how to do this, I would be looking at a different consultant <G>.

    Now, looking at your questions

    1) You can lock the CA to us a signal port (rather than a range of ports) for certificate issuance (after connecting to TCP 135 the RPC port mapper)

    2) Autoenrollment will work with correct port assignments

    3) All command line tools will work from the network segments allowed RPC/DCOM connectivity to the issuing CAs

    4) For the CA MMC, I typically have the users connect to the CA using RDP. The option to allow RPC access would swiss cheese the firewall

    5) As Vadims stated, SCEP enrollment is not supported by XP and 2003 clients (nor Vista or Windows 7)

    6) If you deply Windows Server 2008 R2 (instead of Windows 2008) then you could use CEP/CES to allow external enrollment. My company has created a CEP/CES client for Windows XP/Server 2003/Vista/Server 2008 called CertDeploy (www.certdeploy.com) that allows enrollment through firewalls using CEP/CES (this means internet connected and non-domain joined scenario)

    Bottom line, you consultants should be aware of all of this. If they are not, look to other consultants. <G>

    Brian

    :

    • Marked as answer by pb3000 Monday, February 20, 2012 4:40 PM
    Monday, February 20, 2012 4:07 PM
  • Thanks for taking the time to reply Vadims, and thank you for your clarification on SCEP. I probably got that confused with something that I read elswhere.

    Glad to hear that it is possible. I will do some futher research into the specifics.

    Peter

    Monday, February 20, 2012 4:40 PM
  • I believe Vadims also deserves an answer indication too <G>

    Brian

    Monday, February 20, 2012 4:49 PM
  • Thanks for taking time out to reply Brian.

    Hmm... If you are who I think you are then I have your Windows 2003 PKI and Firewalls for Dummies books on my shelf :)

    In fairness the consultant was working at a high level - feasibility study and recommending deployment options and management products given our requirements.

    I'm glad to hear that it is indeed possible (and relatively painless)  to host the issuing CAs behind a firewall. I assume the process is similar in concept to "fixing" the NTDS and FRS ports on  domain controllers in order to facilitate placement behind a firewall.  I'll have a look into this - should make interesting bedtime reading :)

    Best wishes

    Peter

     

    Monday, February 20, 2012 5:01 PM
  • I believe Vadims also deserves an answer indication too <G>

    Brian

    Yes Indeed 

    Bear with me - I'm still coming to terms with using the forums :)

    Monday, February 20, 2012 5:05 PM
  • just to note. This article describes how to lock AD CS to use single port for DCOM connections (DCOM is used for both, enrollment and administration protocols): http://social.technet.microsoft.com/wiki/contents/articles/how-to-set-a-static-dcom-port-for-ad-cs.aspx

    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Windows PKI reference: on TechNet wiki

    • Marked as answer by pb3000 Wednesday, February 22, 2012 7:48 PM
    Monday, February 20, 2012 5:29 PM
  • The Microsoft PKI Team has blogged about ports that are needed to be open on an CA server:

    http://blogs.technet.com/b/pki/archive/2010/06/25/firewall-roles-for-active-directory-certificate-services.aspx

    Althought they have missed port TCP/135 in the table. I've noted that in the comments over a year ago, but it hasn't been added to the list.


    Tom Aafloen, IT-security Consultant Onevinn AB

    • Proposed as answer by Tom Aafloen Wednesday, February 22, 2012 10:38 AM
    • Marked as answer by pb3000 Wednesday, February 22, 2012 7:48 PM
    Wednesday, February 22, 2012 10:29 AM
  • Thank you Vadmins for your followup and to Tom wrt to the port list.

    I have plenty of info to follow up on. I'll have a play with this in the test lab.

    Wednesday, February 22, 2012 7:50 PM