Sign in
 
HomeWindows Server 2012Windows Server 2008 R2Windows Server 2003LibraryForums
Windows Server TechCenter >
> 
> 
Secondary Issuing CAs for backward compatibility

Answered Secondary Issuing CAs for backward compatibility

  • Saturday, May 05, 2012 10:05 PM
     
     
    Sign In to Vote
    0

    Hi All,

    I am looking at retrospectively adding a secondary issuing CA to and existing two tier hierarchy. At the moment we have the following hierarchy:

    Root CA (offline)

    • CSP = RSA#Microsoft Software Key Storage Provider
    • Key Length = 2048
    • Digital Signature = RSA
    • Hash Algorithm = SHA-256

    Enterprise Subordinate Issuing CA

    • CSP = RSA#Microsoft Software Key Storage Provider
    • Key Length = 2048
    • Digital Signature = RSA
    • Hash Algorithm = SHA-256

    The issue that I have hit is compatibility. We have some infrastructure that does not support the default Windows Server 2008 R2 CSP and therefore will not accept or interact with certificates issued by that CA. I have had this confirmed by at least one vendor, Citrix Systems. I have hit compatibility issues with others as well including EMC and Cisco.

    The existing design was based upon Brian Komars books with a look towards the future of some algorithms. For example SHA1, as far as I am concerned is still secure however there seems to be a common move to SHA2. To work around the issue, until such time as particular vendors add support for the new CSPs I was considering the option to installing a new issuing CA adjacent to the existing Enterprise Subordinate listed above. The new CA will use an older CSP and SHA1. My design questions on this are:

    1) Is this possible?

    2) If so, with two issuing CAs both integrated into Active Directory how does one select the issuing CA when enrolling for a certificate? Is it as simple as making sure the Published Certificate Templates include a description in the title, e.g. "Web Server V3 (Legacy)" as apposed to "Web Server V3" which is an example of one of our current certificate templates?

    Any help would be great.

    Cheers,

    NSutton


     

All Replies

  • Sunday, May 06, 2012 12:32 AM
     
     Proposed
    Sign In to Vote
    0

    1) The issue is not the use of KSP, the issue is the use of a SHA256 signature

    2) You have to do more testing with your applications and OS's to determine if they can work with a SHA256 bit root CA.

    • If they can work with the SHA256 bit root CA, then they will work with any CA using SHA256
    • If they do not, then you could investigate using a SHA1 root with a SHA1 issuing and a separate SHA256 issuing CA
    • You have to determine if anyone requiring SHA256 will support this

    For certificate templates, you have to do a lot of testing to see what applications support KSP (V3) or CSP (v1 or V2) certificate templates

    Brian

     
  • Sunday, May 06, 2012 12:46 AM
     
     
    Sign In to Vote
    0

    Hi Brian,

    Thanks for the response. I understand what you are saying. What I am trying to establish is whether I can continue to leverage from the existing CA chain or whether I need to establish a new/additional chain. 

    Our existing CA chain is designed to support our internal web based applications that make use of SSL for various pieces. In this scenario the SHA256 root and issuing CA's are fine. However, when we look to use this CA chain to support other vendor solutions, e.g. Citrix XenApp we get into trouble due to the lack of support.

    Given we have an existing root and enterprise issuing CA, it is possible to have two root (and more importantly) two AD integrated Enterprise issuing CA's in the one AD forest? Alternatively do you think it best to collapse the existing CA chain and rebuild it using a SHA-1 hash.

    Once again we went SHA2 because of longevity. We also assumed that various vendors would be supporting SHA2 given how long it has been around and, from how I interpret the current industry, the general movement towards suite B.

    Thanks again,

    NSutton

     
  • Sunday, May 06, 2012 8:02 AM
     
     Answered
    Sign In to Vote
    0

    > it is possible to have two root (and more importantly) two AD integrated Enterprise issuing CA's in the one AD forest?

    of course.

    > Alternatively do you think it best to collapse the existing CA chain and rebuild it using a SHA-1 hash.

    it depends on numerous factors:

    1) do you have additional lienses for separate PKI tree?

    2) do you have additional hardware to run separate PKI tree? It is not a concern if you are using virtualization technology.

    3) do you have additional human resources to manage separate PKI?

    if it is possible, I would retain existing SHA2 PKI and deploy a separate PKI for compatibility purposes and run it untill all used applications will support SHA2 certificates.

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