This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(201.6, 6%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESN%3C/text%3E%3C/svg%3E)
Hi,
Just wanted to know if I add a second subordinate Certificate Authority (We have a two-tier PKI) in one of our sites for redundancy, do I need to choose "existing private key" or "a new key" when I am adding the CA role to my new server?
Is there a step-by-step document for this very particular approach?
You have to choose new private key. You cannot install same CA twice. That is, you cannot take a backup of existing subordinate CA and deploy it in another site. You have to install a brand new subordinate CA (with different name) under existing root. Follow same guide you used to deploy existing subordinate CA.
Do I need to use common CDP/AIA locations or they should be different?
My current setup keeps CDP/AIA locally on the subordinate server instead of a network share(unfortunately) I am not sure if this can cause issues?
The reason for this request is to have a second subordinate available in the Asia region as well(we currently have only one in the US).
Hi @Sam Na
You need to select a new key and remember You can have two certificates issued for the same domain and same server from different providers and it will cause no disruptions. It is possible to have two sub-CAs. In an ideal configuration, one should have two subs ca for high availability based on usage /requirement.
AD CS Step by Step Guide: Two Tier PKI Hierarchy Deployment
https://social.technet.microsoft.com/wiki/contents/articles/15037.ad-cs-step-by-step-guide-two-tier-pki-hierarchy-deployment.aspx#Install_Subordinate_Issuing_CA
Hope this resolves your Query!!
--------
--If the reply is helpful, please Upvote and Accept it as an answer--
Do I need to use common CDP/AIA locations or they should be different?
My current setup keeps CDP/AIA locally on the subordinate server instead of a network share(unfortunately) I am not sure if this can cause issues?
The reason for this request is to have a second subordinate available in the Asia region as well(we currently have only one in the US).
Do I need to use common CDP/AIA locations or they should be different?
I personally never host CDP/AIA on CA itself. I always use common server with installed IIS as CDP/AIA hosting server. This gives me better security (you don't install additional roles on CA, smaller attack surface) and maintainability (easy to migrate to another server with different host name). Here is the guidance I'm using in my installations: https://www.sysadmins.lv/blog-en/designing-crl-distribution-points-and-authority-information-access-locations.aspx
I have inherited the two-tier CA and I was asked to add a new issuing subordinate CA, looking at CDP/AIA, I can see that both are pointing at the host name of subordinate CA, and I am wondering about the next steps now.
Adding a new subordinate requires a new cert from offline root CA which is already pointing at the old subordinate CA for CDP/AIA location (http://old subordinate CA/CertEnroll), so how do I overcome this issue?
If I a setup a new server to host CDP/AIA as per your suggestion, what happens to old cert issued by old subordinate CA.
Adding a new subordinate requires a new cert from offline root CA which is already pointing at the old subordinate CA for CDP/AIA location (http://old subordinate CA/CertEnroll), so how do I overcome this issue?
you are stuck with this configuration. You can't change this for existing environment without a complete rebuild. Lack of design and planning results in problems you cannot fix without a complete rebuild.
However, you can start migration/transition process by applying new practices for new CAs and keep existing practices for current CAs until they are renewed. That is, you can build a common server to serve CDP/AIA endpoints and configure existing root CA to use that new endpoint (and keep maintaining existing endpoint on sub CA for compatibility with existing CAs and certificates) and then deploy new subordinate CA. It adds extra overhead, but it is the only choice you have that doesn't require a complete rebuild.
We are asked to migrate both offline root CA and current enterprise subordinate CA to Azure.
Considering the above and adding the new ask to add a 2nd subordinate CA in another site, would this plan work:
1- Add two subordinates in Azure. (one in each region).
2- Keep the current CDP/AIA path(it is pointing at the http:\hostname of the subordinate).
3- Migrate both Root CA and Subordinate to Azure(new servers and migrating settings from on-prem).
4- Remove the services from the current subordinate to be just an IIS to be used as a common server going forward. (not sure if DNS ALIAS can be helpful)
Not sure if the above is a good plan to basically keep things as is and not break anything?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(307.2, 11%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3E8%3C/text%3E%3C/svg%3E)
How did it go with a 2nd issuing CA? I am curious because we were asked to set ours up the same way with a different region for each issuing CA just like you only from scratch for our project. We were able to get everything looking right on pkiview.msc. We are still having trouble though with the second issuing CA, it doesn't seem to be communicating as online on the mmc snap in certificates. But in pkiview, it depends on which server I am testing. When I am on the south (1st issuing server), it shows the 2nd issuing CA as offline and everything on the 1st is good, and when I and on the north (2nd issuing server) it is the exact opposite. We ran tests and got the following results. I should mention we were asked to place the 2nd issuing CA in a different subnet and region. So we ran the following test with our Azure testing vms in windows 10. And the results reflect if we received a mmc certificate from the issuing CA or not. The only issuing CA that responded was the 1st one in the same region as the root CA. The y or n below is to show if they are turned on or off starting with root, then 1st and 2nd issuing CAs, the results are MMC snap in certificate results.
Name Subnet Root CA 1st Issuing CA South 2nd Issuing CA North Results
test-vm-01 South y y y Successful through 1st Issuing CA
test-vm-02 South y y n Successful through 1st Issuing CA
test-vm-03 South y n y Failed
test-vm-04 South n y y Successful through 1st Issuing CA
test-vm-05 South n n y Failed
test-vm-06 South n y n Successful through 1st Issuing CA
test-vm-07 North n y n Failed
test-vm-08 North n n y Failed
Steps we followed
1 Create VM
2 Turn Servers on or off
3 Join new vm to domain
4 Check for cert
It doesn't line up in here with the headings but same order as the results. The most surprising result to me is test 7 because the subnet and region of the testing vm is the only difference I found. Not sure why but it seems like the machines will only get a cert if on the same subnet as the issuing CA, any ideas?
Any advice would be appreciated. Thanks
@Vadims Podāns any suggestions on my issue above?
Thanks
We talked about a load balancer? We found that the subnets are connected in other cases but when setting up A Record to a url across the subnets, it failed. We also asked for these ports opened, haven't got that done yet.
Application protocol Protocol Ports
RPC TCP 135
SMB TCP 445, 139
Randomly allocated high ports TCP Random port numbers between 49152 – 65535
For the web-based portions of PKI, you will also need the standard web ports:
Application protocol Protocol Ports
Web TCP 80
Web SSL TCP 443