Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What, if anything, could or would be embedded into a client-side certificate that would prevent it from "working" when transferred to a new client machine on a new network?

Being unfamiliar with the kind of information that is embedded into a client certificate, I don't know if - for example - the certificate will only validate if it is found on a machine whose NIC is on a particular IP subnet.

I need to copy a client certificate, and get it up and running on a Windows 7 box, and I just want to know what kinds of issues or "gotchas" I may run into.

share|improve this question

migrated from Aug 8 '12 at 18:06

This question came from our site for software developers, mathematicians and others interested in cryptography.

X.509 is wide and versatile and, in theory, anything goes.

In practice, I assume that you are talking about a SSL/TLS situation, probably as part of a HTTPS web site. The server sends his certificate (that the client validates), and then, the server asks the client to also show a certificate, which the server will validate.

In that situation, there cannot be much client-specific data that the server may validate. The important point is that validation of the client certificate happens on the server (necessarily: the certificate from the client is about convincing the server). So, if the server wants to validate some client-specific data (e.g. IP address) then the server must have access to an apparent client IP address, and see if that matches what would be written in the certificate. However, in the HTTPS ecosystem, NAT and proxies happen. Therefore, the client "true" IP address cannot be reliably obtained by the server (e.g. my true IP address is, but that's not what an HTTPS server would see, because I am behind both a NAT and a SOCKS proxy). So there is nothing for the server to validate.

In existing, deployed systems, SSL/TLS servers do not commonly validate client certificates with regards to client-specific information. I have never seen it. Instead, the server validates the certificate in abstracto (the whole signature-by-CA business, up to a root CA), regardless the apparent provenance of the incoming connection. And if the certificate validates, then the user identity is extracted from the certificate (using a server-specific method, but IIS will tend to look at the Subject Alt Name extension and extract the 'UPN', to match against what is in his Active Directory server) and the server is content with that.

Actually that's quite similar to what happens in the other direction: validation of the server certificate by the client. The client wants to make sure that it talks to the right server, so it verifies that the server's name is indeed present in the certificate. The server's IP address, on the other hand, is not in the server's certificate; it was resolved through the DNS. From the point of view of the SSL client, as far as security is concerned, how the data flows is irrelevant; it could go to any IP address or be transmitted on an IP-less serial link or be transported on the back of camels.

Short answer: your client certificate is (probably) not bound to a specific machine, if only because enforcing such a binding would be, at best, difficult. You can transfer it from one machine to another (as long as you transfer the certificate with its private key, of course).

share|improve this answer

The typical gotcha that prevents certs from being transferred to a new machine is that Windows allows private keys to be marked as "non-exportable", and in certain cases this is the default. Since the certificate is useless without the private key, this effectively ties the certificate to a single server unless you have another copy of the key.

Note that it's possible to extract the private key anyway using a little hackery, but it's not trivial.

share|improve this answer

Certificates are considered public information and just bind a key to an identity. Transferring the certificate won't do anything since the machine that received the certificate doesn't have the key that the identity binds.

It's as if I gave you my license. You still can't prove you're me because my license proves that I am me, not whoever holds it.

You need to transfer the private key that the license binds to the identity.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.