Certificate Authority server (Windows 2003)

LANm0nk3y

Limp Gawd
Joined
Mar 28, 2007
Messages
446
Hey guys, just wondering if anyone is an expert at CA servers on Windows 2003 domain.

I want to be able to install a test CA (not Computer Associates) server and install certificates for our intranet sites so that I can authorize scripts and programs w/o getting security prompts for end-users.

If I install it on a test server, if removed is there going to be remenance left on AD and if so, any way of checking where it is?

If test server is successful, any recommendation whether to place it on a DC?

Can it be used in place of other certs (thawte or verisign) for servers in public domain?
 
I'm no expert, my experience is limited to setting up a CA for use with an L2TP VPN.

Once you set up the CA it's added to Active Directory, and that computer goes into the "Domain Controllers" OU. I've noticed no ill effects from this, and simply deleting it from the OU again had no real effect. I might be wrong here though. I set up CA on a separate server from the DC, mostly because I never want to touch the DC. No idea on whether its better to do it that way, or to put it on the DC.

I think the point of CA is to allow you to serve up those verisign or thawte certs no?
 
You should be able to remove it successfully; it'll just invalidate any certs issue by that authority.

I have it running on a DC and its fine. It can replace thawte for publicly facing sites, but your users (unless they're remote users of yours) are going to get certificate trust errors (because they don't trust your DC as a root CA). This may or may not be acceptable.
 
Ideally you want at least two servers, one for the root CA and one for the issuing CA. Note that the root CA should be offline.
 
You should be able to remove it successfully; it'll just invalidate any certs issue by that authority.

I have it running on a DC and its fine. It can replace thawte for publicly facing sites, but your users (unless they're remote users of yours) are going to get certificate trust errors (because they don't trust your DC as a root CA). This may or may not be acceptable.

You can set up group policy so that your clients add the certificates into their stores automatically. Then there are no issues with the certificates at all.

If you have just a few users, they can go to the certificates request web interface, download a copy of the root certificate and add it to their local root store that way as well.

The only errors you would have then are if the certificate had expired, or doesn't match the web site name. That's what I do to secure my home OWA web site. Even works for OS X, but you have to specify a different encoding from the default so it imports properly.
 
You can set up group policy so that your clients add the certificates into their stores automatically. Then there are no issues with the certificates at all.

If you have just a few users, they can go to the certificates request web interface, download a copy of the root certificate and add it to their local root store that way as well.

The only errors you would have then are if the certificate had expired, or doesn't match the web site name. That's what I do to secure my home OWA web site. Even works for OS X, but you have to specify a different encoding from the default so it imports properly.

Right, because if they're remote users of his it won't be an issue because he can take those steps. If they're not his uses (ie clients), they're going to get certificate warnings because they don't trust his CA.
 
Ideally you want at least two servers, one for the root CA and one for the issuing CA. Note that the root CA should be offline.

I'm not quite understand what you mean to have root CA offline -- Turned off?


You can set up group policy so that your clients add the certificates into their stores automatically. Then there are no issues with the certificates at all.

If you have just a few users, they can go to the certificates request web interface, download a copy of the root certificate and add it to their local root store that way as well.

The only errors you would have then are if the certificate had expired, or doesn't match the web site name. That's what I do to secure my home OWA web site. Even works for OS X, but you have to specify a different encoding from the default so it imports properly.

Yea I figured that CA can be imported through GPO.


Anyone know if there's anything that it ties the CA root /issue server to AD? I don't want to screw up AD if i'm going to use a test CA root server.
 
One of the best ways to implement an "offline" root CA is to create it in a virtual machine. Then, shut it down and burn a few copies of that VM image and put them in safes, safty deposit boxes, etc..

Also, if you're going to be using file encryption and whatnot, then be sure that you're using roaming profiles. Any certificates that a user obtains are stored in their profile.

For example, a User A site down at computer A and requests a certificate. That cert is then put in their profile. User A now encrypts a file on the network.

Later on, the user wants to move the file to a laptop, computer B. They login and try to access the file and get an access denied.

The reason is because the certificate used to encrypt the file is stored in user A's profile on computer A. When user A logs into the laptop they don't have the same profile and thus no certificate. This can be fixed by using roaming profiles or Certificate roaming.

Another issue is if you have Autoenrollment enabled and you're not using roaming profiles or certificate roaming. When a user logs in they automatically "enroll" and get any certificates you push to them. This stems back to the fact that a cert is stored in the profile, so everytime a user logs into a different PC, they get a new, different certificate..

Bottom line is if you have users on more then one PC/terminal server you'd better be using roaming profiles or certificate roaming..

Riley
 
I think I might've confused some of you. I'm just concern that if in the event that the CA server is not on (failure of some sort) that actual domain computers are not able to log in.
 
Back
Top