The wonderful world of certificates and CA's

Devilsbane

So I have watched 3 of the 4 nuggets on Certificates (and the 4th one will certainly be tonight) and I have quite a few questions.

The first one that I would like to get out there is a theory question. I had always thought that the certificate contained both the public and private key. But from watching the videos, it looks like certificates are distributed rather carelessly, which means that the private key is most certainly not in it. So where does the private key live?

One of the things that James said was acceptable was to turn off the certificate service on your root CA in order to prevent it from being exploited. I don't understand how this is any safer though. The server is still going to be active and a hacking attempt could lead to someone just turning that service back on, so what is the difference?

I have more questions, I just can't think of them right now. If you could help me with either of these, I'd be very grateful.

Thanks

DragonNOA1

#1: The certificate usually doesn't contain the private key but you can export a cert (and when most people say cert they mean just the public key) with a private key. You can have the private key archived on the CA. It is stored in the registry and the file system. The user cert is stored in the user profile but can be saved to AD. That's why you must be careful when deleting profiles if the user has EFS encrypted files. Google it to find the exact locations in the profile and how to do key archival & recovery. You may be tested on it *wink*

#2: You can't exploit the CA service if it isn't running. You would have to break into the computer another way. But yes, once you break into the computer then you can do anything you like, including turning the CA service back on. It's safer to turn the root server off, not just disable the service.

earweed

I don't know how they do it for 2003 but for Server 2008 the Root is taken completely offline. They actually recommend you having the root server on a removable HDD and totally remove the HDD and store it in a safe and only bring it back online when you need to create more subordinate CAs or to renew the subordiates Cert.

Psoasman

earweed wrote: »

I don't know how they do it for 2003 but for Server 2008 the Root is taken completely offline. They actually recommend you having the root server on a removable HDD and totally remove the HDD and store it in a safe and only bring it back online when you need to create more subordinate CAs or to renew the subordiates Cert.

That's one of the ways M$ suggests doing it in the 293 exam. The Root CA is kept locked up and only used to issue or renew certs for the subordinate CA's, which do the issuing for the clients.

Devilsbane

Psoasman wrote: »

That's one of the ways M$ suggests doing it in the 293 exam. The Root CA is kept locked up and only used to issue or renew certs for the subordinate CA's, which do the issuing for the clients.

Thats what I would think. I don't think that stopping a service is enough security, but maybe thats just me.

He also suggested taking the whole server offline and securing it, or if you are on a budget to pull the HDD and put it in a safe, and then you can install a new HDD and use that same box as a file server or something. That way you don't have a server completely unused.

Thanks for all of the replies. If anyone else has CA/Certificate questions feel free to hijack the thread with them.

docrice

For an enterprise PKI, I believe Microsoft recommends using a stand-alone (non-enterprise) root CA which signs the certificates of enterprise subordinate CAs. I think I read this in the 70-640 MS Press Training Kit. Then you completely offline the root so the top-level of the PKI hierarchy can't be exploited via discovered 0-days, etc.. The problem, of course, is that if you need to bring another subordinate CA online (or to revoke it's certificate and issue a new one, etc.), then that root CA is going to be out of date on patches, anti-virus signatures, etc..

Probably best to have a procedure in place to bring the root CA online (without it being connected to the network at first), patch it / update other security areas before plugging in the network cable, and then shutting it down again once the ongoing PKI need is addressed.

And as others have already answered, a certificate which is shown to another entity for identification and SSL / TLS negotiation is only going to contain the public key. The private key is held in guarded secret by the said certificate holder. If the private key is compromised, then it's game over unless the issuing CA is notified and that cert is put on a revocation list ... and assuming that the client negotiating with the certificate holder actually checks the revocation list (or uses OCSP) to verify it's current validity.

If both the public key and private key need to be exported together (to migrate SSL / TLS operations to another server, for example) then it gets put into a PKCS12 file which is encrypted with a password (a good password, one hopes). Otherwise, the certificate shown to other parties during SSL / TLS negotiation doesn't contain the private key.

Devilsbane

docrice wrote: »

And as others have already answered, a certificate which is shown to another entity for identification and SSL / TLS negotiation is only going to contain the public key. The private key is held in guarded secret by the said certificate holder.

Thanks for the reply.

So lets say that I am setting up my PKI, and I have configured auto-enrollment. Client01 logs in and requests a certificate. My CA accepts the request and sends a ticket over. Does it then send the private key over separately? Because Client01 needs to get its own private key somehow.

docrice

In general, a client will auto-generate it's own public / private key pair first. Then it will create the CSR (Certificate Signing Request) which contains the public key, it's Common Name, etc. and sends that over to the CA. The CA looks the CSR over, downs a few beers, blesses it, then rubber-stamps / signs it (the SHA digest of the cert) with the CA's private key (which becomes the digital signature), and sends this certificate back with a validity date range.

I know in some operations such as web-based enrollment ("h t t p s /my-ca.mycompany.com/certsrv/") for third-party devices or clients, there is an option to generate a new key set on the server-side. In that case both the public and private keys are handed down to the client over HTTPS.

Devilsbane

So I've been through the CBT's and it made sense. Last night I introduced a new server to my network to be my CA. Install went without a hitch. I then installed CA on my Server02 VM (which is also a DC, and DNS server) to be my enterprise CA. Install went fine, I requested a certificate and went back over to Server04 and accepted it. I then attempted to start the service on Server02, but it failed. It was unable to connect to server04, said that the certificate service isn't running. Which it is, and they can ping to each other. But whatever, I go back to server04 and export the certificate and connect to [URL="file://\\server02\c$"]\\server02\c$[/URL] and drop it off. I then attempt to start the sevice, and now I get this error. (attached)

Any idea what I'm doing wrong here?

DragonNOA1

Why was server02 off to begin with? You missed a few steps on what your server names are and when you turned on and off CA services on them.

As a side note, when I tested taking the root offline then my certs wouldn't work anymore because the chain of CA's (root and subordinate) weren't all on. The subordinate was but not the root. There is probably an option somewhere to not check the chain of trust. I don't know. I am just thinking out loud and letting you know mine didn't work but I didn't try too hard.

Devilsbane

DragonNOA1 wrote: »

Why was server02 off to begin with? You missed a few steps on what your server names are and when you turned on and off CA services on them.

As a side note, when I tested taking the root offline then my certs wouldn't work anymore because the chain of CA's (root and subordinate) weren't all on. The subordinate was but not the root. There is probably an option somewhere to not check the chain of trust. I don't know. I am just thinking out loud and letting you know mine didn't work but I didn't try too hard.

Is your root a standalone or enterprise? From my understanding, if you shut an enterprise down, then anything below that goes down too. The ideal configuration is to have your standalone root server, a few intermediate standalone servers (which will also be shut down, but can at least divide your PKI up by location or type) and then the 3rd tier is your enterprise CA's which will actually issue the certs, preferably with auto enrollment.

My network goes like this:
server01 RRAS,DHCP
server02 DC,DNS,CA
server03 DC,DNS
server04 Root CA
server05 Nothing (yet)
Child01 DC,DNS (DC for a child domain)

Right now, only server01, 02, and 04 are on. I haven't shut server04 off yet because I haven't been able to get the service on Server02 to start. Once that is done, I will shut Server04 off and set up auto-enrollment on Server02. (I'm going with a 2 tiered approach just for the learning rather than a full 3 step)

Devilsbane

I did some research online, I think I configured something wrong. I just uninstalled the CA component from both servers. I'm now rewatching the vids and I'm going to follow along, I'm sure I just missed a step somewhere.

Devilsbane

Same thing happened. There seemed to be an issue with connecting to server04 from server02. I took a wild guess, and wondered if it was because my administrator account had a blank password.

I logged into my other account, Admin, which does have a password. Went off without an issue. Although I did notice that on server 4, the requester was server04/admin (I also have a user named admin with the same password on server04). Shouldn't the requester have been Contoso.com\admin?

My guess is that it just passed the credentials over, and since the usernames and passwords are the same I was granted access as the admin account over there. But what would happen if I had a username/password mismatch? Would it prompt for credentials of an account on server04 or would it just deny me?

Anyways, time to try my hand at auto-enrollment.

Devilsbane

Auto enrollment is go. The user part took a lot of time, when I initially configured the template I requested that the private key be backed up. But I had never configured the CA to do that, so it kept failing. Even after editing the template, and even deleting it and building a new one from scratch, I kept getting this error.

I was just about to set the CA up for archiving and decided to test one last time, and it worked. I guess it just took some time. Thank god that is over with.

Devilsbane

I decided to expand my PKI and set up Server03 (also a DC and DNS server) as a backup CA (once installed I intended of shutting the service down, but it would be there if Server02 went offline)

Anyway, I went into control panel and went to install it, but I'm not being given the option of setting it up as a Enterprise CA. Wondering if anyoneone has an idea why. I'm running 2003 enterprise, and it is a DC so the AD component should also be met. The only thing I can think of with this server is that it is also my WSUS server, does that then make it not able to be an enterprise CA?

Devilsbane

Devilsbane wrote: »

Same thing happened. There seemed to be an issue with connecting to server04 from server02. I took a wild guess, and wondered if it was because my administrator account had a blank password.

I logged into my other account, Admin, which does have a password. Went off without an issue. Although I did notice that on server 4, the requester was server04/admin (I also have a user named admin with the same password on server04). Shouldn't the requester have been Contoso.com\admin?

My guess is that it just passed the credentials over, and since the usernames and passwords are the same I was granted access as the admin account over there. But what would happen if I had a username/password mismatch? Would it prompt for credentials of an account on server04 or would it just deny me?

I did investigate this a bit. I had 2 domain accounts with the same positions. We will call them Admin1 and Admin2 (both with passwords). There was also a local Admin1 account (with the same password) on my Root CA. When trying to request a ticket, Admin2 couldn't do it. An error is given that the computer is unable to connect to the server and to check to ensure that the service is running. When I did a runas (runas on the add/remove programs) as Admin1, I was able to submit the request.

So if you are looking to send the request over the wire, make sure that you have an account with the same username and password on each system. Otherwise I believe you will need to save the request to a file and manually bring it over.

That is all.

phoeneous

Devilsbane wrote: »

So if you are looking to send the request over the wire, make sure that you have an account with the same username and password on each system. Otherwise I believe you will need to save the request to a file and manually bring it over.

That is all.

But if they are domain admin accounts, the permissions should replicate over to any dc. Unless I missed something.

Devilsbane

phoeneous wrote: »

But if they are domain admin accounts, the permissions should replicate over to any dc. Unless I missed something.

Your root DC isn't a part of the domain. Well I suppose you could join it without any major security implications. But since you intend to take it offline anyway, I wouldn't bother.