views:

945

answers:

6

Here is the situation. I am making changes to an application but I do not have test environment. There is a QA server for the testing team to use, but I would rather test the application on my local machine (deploying changes to that server might interrupt the testers). I have setup the environment on my local machine, but there is a problem.

The application reads data from a third party application. It needs an SSL certificate to connect to the third party.

My question is, why can't I use the SSL certificate from the QA server on my local machine?

I have done a cursory search on Stack Overflow, and to me it seems once the certificate is issued from the CA that any computer could use it. My guess is that I have misunderstood some part of the SSL process.

+5  A: 

The SSL Cert is bound to the actual host name. If you have an SSL cert for "qa.example.com", it won't work on your machine named "dev.example.com".

Perhaps that's the issue you're having.

Will Hartung
That makes sense. So the SSL certificate is specific to that machine. I was imagining it was just a really long password. Thanks.
Kyle Jones
@kyle: It's not that the certificate is bound to a *machine* it's bound to a *hostname*. Multiple machines that answer to the same name (such as, in a load balancing configuration) can (and should) use the same certificate.
nsayer
+2  A: 

My question is, why can't I use the SSL certificate from the QA server on my local machine?

Imagine if a malicious user wanted to impersonate your site/server...

Someone could simply get a copy of the certificate (trivial), and then pretend to be the authoritative owner of the certificate.

For example, I could get Paypal's certificate and setup a copy-cat site and steal users' money. All the while, the certificate would appear valid...

That is the reason why the certificates are bound to a domain.

Ben S
Getting a copy of the certificate is useless without also getting the private key.
nsayer
A: 

I think you need to elaborate on your environment a bit more, but maybe you have not copied the private key part of the certificate to your local machine. Both private and public key are necessary to use the certificate. I am assuming since you write "read from a third party" that you are using a client certificate.

Jonas Klemming
+1  A: 

This is definitely possible to do, how else would servers work in a web farm? All servers in a web farm have the same certificate installed.

I don't have experience on Apache but for IIS the process is documented here http://support.microsoft.com/kb/313299

Sijin
They must be in the same domain or subdomain, depending on how the certificate is configured. Most load-balanced setups use one main gateway and forward the requests on a private network.
Ben S
That's true......
Sijin
You can also load balance simply using the hostname (in DNS) resolve to multiple machines, each configured with the same certificate and private key, each answering requests as the same name.It's true that in most enterprise scale installations, there is instead a crypto proxy that does the SSL encapsulation for the entire farm and forwards unencrypted connections on a private network back to the machines in the farm, but you don't have to do it that way.
nsayer
A: 

In these situations, the third party generally will do one of two things. Provide you access to a QA sandbox that does not require a cert. or allow you to make a temporary cert that they will accept that is not validated by a certificate authority. It would be strange for a third party web service provider to not provide for the need to have different QA and prod. environments.

JP Alioto
+1  A: 

I'm assuming that what you describe is performing SSL client authentication to a remove third party. That your product initiated the connection to the third parts as a client and the third party decides if your certificate is good enough for the connection.

A certificate is essentially three things:

  • A private key - that should only be possessed by the entity represented by the certificate
  • A public key - a key that is shared with the world
  • certificate information that includes the public key as well as readable data identifying the key holder - this is signed cryptographically by the certificate's issuer.

So... it's a bit more than just a password, but it is all data, in the end.

The answer to whether you can install an SSL client certificate in multiple locations is both yes and no. Mostly it depends on the security requirements of the third party system and also how you've stored that private key.

It is possible to store a private/public key pair and certificate in a file - one standard for this is the PKCS12. PKCS12s are usually then secured with a password. Many softare tools will let you create the key pair, store it in a PKCS12, and do the various certificate protocols needed to request and finish certificate issuance from a third party (I would suspect that your third party requires that your certificate be signed by one of a list of trusted issuers). Every application server I've seen has then let you configure the certificate file as your client side certificate.

If that's how the QA SSL Certificate is stored, then there should not be a problem installing it on your machine.

Here's the catch - sometimes security policy mandates that certificates be stored on a hardware token. This is typically a security measure to guarantee that only one entity can use the certificate. Copying software certificate files works fine in a test environment, but it's a pretty poor security practice for a working product installation. If the QA server is using a hardware token, the hardware is likely to protect the copying of the private key pair to another location. Without access to the private key pair, you will be unable to perform the SSL request to the third-party - demonstration of access to the private key is part of the protocol.

In that case, you'll need to request your own certificate and key pair for accessing the third party - unless your company offers a mechanism for sharing hardware tokens. That's not entirely crazy - some server farms do that - all servers have the configuration to tap into a common, networked HSM (hardware security module) and to use the key pair. This is often true for SSL site certificates, so that all servers in the collection can appear to be the same server. The trick is - that sort of hardware is pretty high end. If you're running some quick and dirty testing, I'd think it would be unlikely to have access to that sort of system.

I'd ask about software certs and if it's viable for you to have a copy. There may be policy reasons forbidding it... but it's not hard to install them, and if you're just doing some testing, you really aren't risking anything.

bethlakshmi
Thanks for your detailed response, it has given me a better understanding. I will look into getting a cert and if my company has any policies that would disallow this.
Kyle Jones
The problem he's having is likely much, much simpler than what you've outlined. He's trying to use the certificate and private key for machine A on machine B. The hostnames don't match, though, so a browser rejects it.
nsayer
A browser doens't have to reject on certificate/DNS hostname mismatch. With some settings you can manually approve the usage and get by this problem.
bethlakshmi