Why can't one SSL certificate be used for multiple machines?

Question

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.

Answer 1

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.

Answer 2

I'm assuming that what you describe is performing SSL client authentication to a remote 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 PKCS #12. PKCS12s are usually then secured with a password. Many software 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.

Answer 3

I know this is an older post and I may be missing something, but it seems that everyone missed the real answer here. If you want to have a single certificate that works on multiple servers using multiple hostnames/domains, then you just have to buy a SAN certificate. We do it all the time at work...

Answer 4

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

Answer 5

SSL certificates are bound to a host name. So to be able to use it your dev machine you should make the host name resolve to you dev machine (i.e. using hosts file)

Answer 6

Typically during SSL handshake, the host name that is part of the certificate is matched to the hostname of the other side of an SSL connection. That's why a certificate is tied to a host name.

There are several ways out of this.

1. Use a wild card certificate.
2. Disable hostname verification and accept the increased risk.
3. Customize hostname verification.

See http://support.godaddy.com/help/article/567/what-is-a-wildcard-ssl-certificate and http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HostnameVerifier.html

Answer 7

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

@autonomatt -- Sub-question: VeriSign and other companies ask you how many server you are installing the SSL cert on ... getting the odd customer calling up saying their browser reports a problem w/ certificate ...

Legally? You can install the SSL Cert on more than one computer, but may not be able to do so legally. The Signing CA company, like Network Solutions, has a legal limitation on your purchase. When you purchase an SSL Cert, you purchase it for installing only on one computer. You should read the terms of the signing CA you purchase the cert from.

Technically? Technically, except for some hardware accelerated SSL servers, yes you can copy the KEY and the CRT to any web server for serving a valid SSL connection. Note that some SSL certs are shipped/provided from the CA with a certificate chain that must also be installed on the servers side. Without the cert chain installed, the client web browser cannot validate the SSL cert properly. You should check to see if a CA Chain is provided with the SSL cert provided from the signing CA.

IP Resolution Requirements. And the SSL cert is bound to a hostname. When a client web browser makes a request to a server, it connects to an IP address resolved from a domain name, then begins the SSL/TLS handshake process. The Web Server responding on that IP address must present the SSL certificate with a common name the client web browser is requesting via IP Address. This means that only one SSL Certificate per one IP address can be configured. The client only sends encrypted HTTP 1.1 requests, so the server has no idea what the actual domain request of the client is until after the SSL/TLS handshake.

Non-production IP Resolution. To install elsewhere, the web browser must resolve the hostname to IP address properly. So if you are in a non-production environment, the client must resolve the IP address differently from the production environment. This can be performed with alternate DNS servers, or the local hosts file of all machines needed the alternate DNS resolution.

Technical installation process. To install the SSL cert on another machine, copy the KEY, SSL CRT, and the CA Chain in the appropriate files configured for the Web Server. If Apache, it can all go in the one PEM file for the SSL Cert.

Then make sure the web server is serving this PEM file on the IP address that resolves for the common name in the SSL Certificate.

Wildcard SSL Certs. Some CA's also provide Willdcard SSL Certificates, like *.domain.com . Note that the web browser must recognize this type of cert, and it only protects one subdomain level. So www.domain.com can be protected, but www.sub1.domain.com will cause the client web browser to give the client user a validation error.

Some reasons why client web browsers receive SSL Cert validation errors:

1. if the CA Chain is needed but not provided by the web server.
2. if the Root signing CA is not a trusted CA in the client web browser SSL authorities - this is always true for self-signed SSL Certificates.
3. if the client web browser is requesting a domain via SSL that does not match the SSL certificate's common name.
4. if the client browser cannot access the x509 CRL Distribution Points from the Signing CA - so a client on a restricted or closed network will fail to validate the SSL Cert. The URL for the CRL is provided during the SSL/TLS handshake. See also: http://en.wikipedia.org/wiki/Revocation_list#Problems_with_CRLs .

Answer 8

The certificate contains information: 1) Details like name, domain, address, expiry date of key, etc about the company/indvidual that holds the certificate. 2) It has the public key. 3) Some encrypted data. This is the crux.

This encrypted data is all the userinfo as well as the public key present in the certificate which has been signed by Private key of CA who issued the certificate.

When Browser receives the certificate, it tries to de-sign encrypted data using the public key of CA already embedded in the browser. So if all the information present in the certificate matches after de-signing, then it ensures that owner of that domain mentioned in the certificate has the private key corresponding to the public key mentioned inside the certificate.

So the crux is, if someone publishes (like websites do) that i am the owner of the certificate, that means that, person/company owns the corresponding private key pair.

SO COMING BACK TO ISSUE: The real Problem is that "The application reads data from a third party application. It needs an SSL certificate to connect to the third party."

and this what certificate are meant for. Basically your application wishes to make SSL connection with the third party application, and if you have the certificate, you are all set. So, at first I assume that you have put the certificate in wrong directory so that your application is not able to read it and not able to make ssl connection with the third party. Or there is some configure file issue.

I know that answer is of no use but i thought better to write what i feel.

Answer 9

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.

Answer 10

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.

Answer 11

Well technically, a certificate (exported from these PKI tools out there) will not contain private key. So even in the load-balanced environment, plain copying of certificate will not help??

Also, when we generate certs using PKI tools, you can provide an arbitrary string for the DN (like "CN=xyz, OU=ttr, O=x"). I wonder what would be the behavior if different machines use the same DN to create the certs?

Answer 12

I understand my response for this question is too late in the thread..but I ran into the same issue today while installing the same certificate to 2 servers in a Load Balancer Configuration, OS =Windows 2008/ IIS 7.5 and was able to figure out the solution.

I was able to install it on the first server by clicking on 'Complete Certificate Request' and navigating to the location where the certificate 'abc.cer' is located (Assume you have the certificate already with you). Then I copied the same 'abc.cer' on the second server and tried 'Complete Certificate Request' and it would not work. The certificate would appear as installed but would disappear as soon as I refreshed the IIS Manager. Then I tried the option of 'exporting' the certificate from the first server (it generates a .pfx extension file) and then imported the same on the second server. This method worked.

Answer 13

It depends what you mean by this

One wildcard certificate can be used for multiple hosts with different A records.

For example you have a wildcard certificate for the domain *.stackoverflow.com. You can have CA approved TLS as long as the new servers you are running are using a subdomain of the domain stackoverflow.com

i.e. mail-server.stackoverflow.com