none
Implications of placing issuing CAs behind a firewall?

    Soru

  • 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

    20 Şubat 2012 Pazartesi 13:41

Yanıtlar

  • 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

    :

    • Yanıt Olarak İşaretleyen pb3000 20 Şubat 2012 Pazartesi 16:40
    20 Şubat 2012 Pazartesi 16:07
  • 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

    • Yanıt Olarak İşaretleyen pb3000 20 Şubat 2012 Pazartesi 16:36
    • Yanıt İşaretini Geri Alan pb3000 20 Şubat 2012 Pazartesi 16:41
    • Yanıt Olarak Öneren Brian Komar [MVP]MVP 20 Şubat 2012 Pazartesi 16:48
    • Yanıt Olarak İşaretleyen pb3000 20 Şubat 2012 Pazartesi 17:05
    20 Şubat 2012 Pazartesi 13:52
  • 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

    • Yanıt Olarak İşaretleyen pb3000 22 Şubat 2012 Çarşamba 19:48
    20 Şubat 2012 Pazartesi 17:29
  • 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

    • Yanıt Olarak Öneren Tom Aafloen 22 Şubat 2012 Çarşamba 10:38
    • Yanıt Olarak İşaretleyen pb3000 22 Şubat 2012 Çarşamba 19:48
    22 Şubat 2012 Çarşamba 10:29

Tüm Yanıtlar

  • 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

    • Yanıt Olarak İşaretleyen pb3000 20 Şubat 2012 Pazartesi 16:36
    • Yanıt İşaretini Geri Alan pb3000 20 Şubat 2012 Pazartesi 16:41
    • Yanıt Olarak Öneren Brian Komar [MVP]MVP 20 Şubat 2012 Pazartesi 16:48
    • Yanıt Olarak İşaretleyen pb3000 20 Şubat 2012 Pazartesi 17:05
    20 Şubat 2012 Pazartesi 13:52
  • 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

    :

    • Yanıt Olarak İşaretleyen pb3000 20 Şubat 2012 Pazartesi 16:40
    20 Şubat 2012 Pazartesi 16:07
  • 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

    20 Şubat 2012 Pazartesi 16:40
  • I believe Vadims also deserves an answer indication too <G>

    Brian

    20 Şubat 2012 Pazartesi 16:49
  • 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

     

    20 Şubat 2012 Pazartesi 17:01
  • 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 :)

    20 Şubat 2012 Pazartesi 17:05
  • 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

    • Yanıt Olarak İşaretleyen pb3000 22 Şubat 2012 Çarşamba 19:48
    20 Şubat 2012 Pazartesi 17:29
  • 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

    • Yanıt Olarak Öneren Tom Aafloen 22 Şubat 2012 Çarşamba 10:38
    • Yanıt Olarak İşaretleyen pb3000 22 Şubat 2012 Çarşamba 19:48
    22 Şubat 2012 Çarşamba 10:29
  • 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.

    22 Şubat 2012 Çarşamba 19:50