Server 2008 R2 Root and Subordinate Certificate Authorities on parent domain and RDS server on child domain


I am trying to get a Server 2008 R2 Standard RDS server installed on a child domain. We have a root and subordinate certificate authority established on the parent domain. I am having difficulty attaining a certificate from the subordinate CA because of the network being locked down. The CA's have never been used, they are server 2008 r2 standard as well. I have a few questions on this:
What ports do I need to have opened between the RDS server where I will generate my request for a certificate and the CA's?
Per this article, I need port 135 for RPC, but the other port is randomly generated, how do I establish what it is, and will it stay the same? Also, will it need to remain open?
What is the best way to go about generating a request for a certificate, and what will the steps be to import the certificate once it is generated? Should I generate a request using a .inf file and certreq, or is there a better way? This is the context of the .inf I was using to generate the request file, will this work?:

Signature="$Windows NT$"
ProviderName="Microsoft RSA SChannel Cryptographic Provider"
KeyUsage=0xF0 ;Digital Signature, Key Encipherment, Nonrepudiation, Data Encipherment
OID= ; Server Authentication

I was able to get a certificate over to the RDS server and select it for use w/ RDS, but when i attempt to connect to it from my Windows 7 pc that is not joined to the same domain, I get an error saying that the Certificate revocation list is not available. Is there communication that takes place between the RDS server and the CA when someone logs on remotely to it? An xp machine on the domain does not get a notification about the certificate at all. This RDS server is going to be accessed from non-domain PCs.

One other thing, the parent and child domains are on seperate vlans & subnets, the parent is on the 10.33.1.* range and the child is on the 10.28.1.* range.

Let me know if you need anything else. I'm sure I will have more questions as we go being that I have now thoroughly confused myself.

Who is Participating?
ParanormasticCryptographic EngineerCommented:
Glad you found the .crt file - for the root CA that is created during installation of AD CS, for the subordinates it is issued from the root (or another higher subordinate) CA.

You might try setting up an OCSP responder and adding that path to your AIA ( - for some dumb reason some newer remote connections seem to have a strong preference for OCSP instead of the traditional CRL.  I highly recommend not messing with the /ocsp virtual directory.  The responder may be set up on a regular web server - this is the only AD CS role that is available to a web server edition installation.  I would recommend having a dns alias 'pki' or something like that so you can move it easier some day if you need to or to start load balancing for redundancy.  the actual bandwidth should be pretty nominal unless your company is quite large.
ParanormasticCryptographic EngineerCommented:
Port 135 is necessary, then it will call a large range of high numbered ports.  To declare a static high numbered port of your choosing for DCOM traffic, follow this:

This port only needs to be open during certificate requests - its probably more pain than its worth to try to only open it every now and then but feel free if you want to.  I'd suggest setting calendar reminders as part of that process in case things go crazy.

Here's a list of ports I just put up on my site:

Your request.inf looks fine, although I'm wondering if autoenrollment or just a regular manual enrollment with a template duplicated from the web server template set on the subject name tab to get info from distinguished name / DNS would probably be easier, but I'm not against the concept of manual enrollment for sensitive systems/templates.

Keep in mind that you can always copy the CSR you generate using certreq on the server onto a flash drive and sneakernet that to your workstation or CA to issue, then use the flash drive to move the issued cert back to the originating server - in this case nothing is required to connect to the CA.  Keep in mind you may still need to specify your CRL & OCSP locations in your firewall ruleset.

You can use the Enterprise PKI MMC snapin to get a quick look at your PKI to see if anything is out of date or whatever.  Make sure there is at least one of each for CDP, AIA, and OCSP location.

Note that there are some new things with OCSP if you need to support it in a DMZ, etc. - this is fairly complex but I can point you to more info if needed.

Also, make sure that the child domain's groups DOMAIN\Domain Computers, Domain Users, Domain Controllers are listed in the CERTSRV_DCOM_ACCESS group - this is a local security group on the CA unless your CA is installed on a DC in which case it would be an AD domain local security group.

As far as the subnets go - if they can talk then that's good.  You might want to allow ICMP for testing so you can ping to test connectivity to make sure you don't have a routing issue or something.
advserverAuthor Commented:
Thanks for the thorough response, your steps were very helpful, but I'm still running into the issue with the CRL. When I attempt to connect to the RDS server where the cert is issued, from a non-domain joined pc, I get a CRL issue. I have added an http location to the cert for the client to look and get the CRL, but it does not seem to be looking at it. It says a revocation check could not be performed. I have checked the CRL distribution point listed when I view the certificate, and it has the http listing, and I can manually go and get the CRL via IE, so it shouldn't be a firewall issue. The only thing I can figure is that there needs to be the AIA listing as well, and I have added this and have the .cer file in place, but it seems that with AIA you have to have a .crt extension? I have no idea how to generate a server certificate with that extension... I tried changing the extension on the file to .crt and I can navigate to the location in IE but when I attempt to connect via RDP I get an error saying that an unexpected cert was retrieved...

Apparently this is a known issue with Windows 7 and Server 2008 R2, and a hotfix is available, but I can't do this as we have vendors connecting to the RDS server that I do not have access to, and there are quite a few of them.
advserverAuthor Commented:
Found where to get the .crt files; thought I had to manually create them. Still any input you have would be great. Thanks!
advserverAuthor Commented:
Thanks! Yeah that was kind of the direction I figured that we would have to go with, but unfortunately the 2008 R2 Standard edition does not include functionality for the OCSP responders. I think we're going to have to do an upgrade of our CA's in order to get that across. For now we are going to wait a bit and use the patch provided by MS to fix the issue with Windows 7... Not ideal but hopefully the patch will eventually get released as an update, or another fix will come out for the RDP 7 client. Thanks for your input, it was definitely helpful.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.