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.