certificate copy risk

The SSL certificate was signed for your domain only.  Unless the person you contracted to do the install for you wants to spoof a site and pretend to be your domain, then I'd say you are relatively safe.  I'd also have to question your level of trust with a vendor if you thought they would go to such lengths to stick it to you.
I'm not above reasonable precautions, however, in my estimation, there would be significant work on the vendor's part to make your CA signed SSL cert do them any good.

As long as it *IS* just the certificate, it doesn't matter. The certificate is (by definition) sent to every client that connects to your server.

However, the certificate can only be installed to the system that generated its CSR in the first place, and then may well be re-exported as a pfx (pkcs #12) file - those have a couple of issues, primarily that any packet captures made from internet explorer (but not firefox) can be decrypted using wireshark if you have access to the pfx.  The odds of that being in any way practical are low however.

It is really good to know that certificate can only be installed to the system that generated its CSR in the first place. the csr was generated by one of our iis servers. this guy we hired is trying to install the ssl in an appliance firewall , and he told me to that he is having some problems installing it! do you thing he will be able to? or i should tell him to get the csr from the appliance and get a new certificate from the ca, because we should terminate the ssl on the firewall.

I would have to ask exactly what your purpose is for the SSL cert?  There are particular reasons to have it on an IIS server, and there are other reasons to have it in a Firewall appliance.

It's possible he is trying to set up SSL bridging through the firewall, but then the firewall vendor should have explicit instructions on how to accomplish this.

we were planning to have the ssl on the iis before, but the firewall vendor recommended to terminate the ssl on the firewall for performance issue. now he is trying to install the cert on the firewall but he did not succeeded  yet

do you think he will be able to do the ssl termination on the firewall with csr generated from iis?

As DaveHowe mentioned "the certificate can only be installed to the system that generated its CSR."  So if the IIS server created the CSR, then that is where it needs to be installed, otherwise, you will have to generate another CSR from the firewall and go from there.

Ok, I will take this from the top.

SSL uses a system of encryption called "public key"  - effectively the key comes in two halves, the public half which is given to the client, and the private half, which is kept secure and never leaves the server.

Normally, you will generate the private key and a certificate signing request at the same time. the private key remains on the server, and the CSR is sent to the CA to sign and return as a certificate. The certificate is then imported into the server that generated the CSR, where it is matched to its original private key to form a full keypair - only a full keypair can be used for SSL.

In operation, the certificate (with its public key and signature) is sent to the client (usually a browser) which verifies the signature, verifies the hostname in the certificate, and then uses the public key to encrypt the data it sends to the server. The server can then use the private key to decrypt the data it received, and continues with its conversation.

once the keypair is formed, it can usually be exported again as a keypair - this is a pfx (pkcs12) file, rather than a certificate. pfx files are usually exported as soon as the certificate is imported, for backup/recovery purposes. usually a pfx will have a password set so that it is not usable by a third party without knowing the password.

IF you generated the CSR on a different system, AND that system has the correct name (usually the CSR will generate with the server's name, and hence the resulting cert is only valid for a server with that name) You can usually import that cert to the generating system, re-export as a pfx, and import that to the target system.

you can also generate the CSR, key, pfx etc separately - the easiest tool for this is free from http://sourceforge.net/projects/xca (with instructions at http://xca.sourceforge.net/ )

Thank you all for your help
Dear DaveHowe
I understand your reply until the third paragraph! , the rest is over my head.
Let me put the question in another way
If there is a secure communication between a client and a web server using ssl, and someone has a copy the certificate for that server. If he could sniff the traffic between the client and the server, will he be able to decrypt  the traffic using that certificate?
I appreciate your reply

No.

Everyone who ever visits a server will have the certificate - in fact, if you go to any https website, and look for a padlock icon in your brower (on the toobar in firefox, and to the right of the url in ie) it will show you, in full, the certificate for that site.

The certificate has three parts, all important in different ways.
It has the public key for the encryption (more on that in a moment)
it has the certificate information (which includes the name of the site and the dates for which the certificate is valid)
it has a signature from a CA.

first, the signature is verified - this ensures that the certificate has not been tampered with (substituting a different site name or public key, for example)

Then, the CA is asked if the certificate has been revoked (just in case it was cancelled due to being stolen)

next, the data in the cert is matched against site name, current date, etc etc to ensure that it is the correct cert for the site the browser thinks it is talking to.

finally, the public key is extracted and used to encrypt the data to the server.

the best way to imagine the difference between the private key and the public key is to imagine that the public key is, in fact, a lock, and the private key the key that fits that lock

using the public key, the transmission from the browser is *locked* and sent to the server, where the private key is used to unlock it.

anyone can have the public key - it is given away by the server every time you talk to it - but it can only be used to lock messages, not unlock them. for that you need the private key, and that is never taken away from the server - it must be protected, so that the server can unlock messages but nobody else can.

In practice, the "message" sent by the browser is something called a premaster secret, but that doesn't matter - the important thing is that it gets to the server securely by using the public key from the certificate, which need not be (and in fact, isn't) kept secret.

Dear DaveHowe
thanks a lot this information is helpful for me, the bottom line now is the private key, what do u mean whey u said that the private key is never taken a way? you mean it  can not be copied or used outside the server?

Ideally it should never leave the server - it is never needed outside the server, and exporting it creates a security risk. However, it often *can* be exported, for backup purposes, and usually in a password protected pfx file with the certificate it matches.

Another confusing thing about the private key, someone told me that you can create csr fire in my labtop, send it to the ca, then when I get the certificate from the ca I can make export and import from the labtop to the webserver! So where is the private key now? Is it in my labtop or in the webserver?