X.509 es amplio y versátil y, en teoría, todo vale.
En la práctica, asumo que está hablando de una situación SSL / TLS, probablemente como parte de un sitio web de HTTPS. El servidor envía su certificado (que el cliente valida), y luego, el servidor le pide al cliente que muestre también un certificado, que el servidor validará.
En esa situación, no puede haber muchos datos específicos del cliente que el servidor pueda validar. El punto importante es que la validación del certificado cliente ocurre en el servidor (necesariamente: el certificado del cliente trata de convencer al servidor). Por lo tanto, si el servidor desea validar algunos datos específicos del cliente (por ejemplo, la dirección IP), el servidor debe tener acceso a una dirección IP del cliente aparente y ver si coincide con lo que se escribiría en el certificado . Sin embargo, en el ecosistema HTTPS, NAT y proxies ocurren. Por lo tanto, el servidor no puede obtener de manera confiable la dirección IP "verdadera" del cliente (por ejemplo, mi verdadera dirección IP es 10.0.1.101, pero eso no es lo que vería un servidor HTTPS, porque estoy detrás de un NAT y un proxy SOCKS). Así que no hay nada para que el servidor valide.
En los sistemas implementados existentes, los servidores SSL / TLS generalmente no validan los certificados de clientes con respecto a la información específica del cliente. Nunca lo he visto. En su lugar, el servidor valida el certificado in abstracto (todo el negocio de firma por CA, hasta una CA raíz), independientemente de la procedencia aparente de la conexión entrante. Y si el certificado se valida, entonces la identidad del usuario se extrae del certificado (utilizando un método específico del servidor, pero IIS tenderá a mirar la extensión del Nombre del sujeto y extraer el 'UPN', para coincide con lo que hay en su servidor de Active Directory) y el servidor está contento con eso.
En realidad, eso es bastante similar a lo que sucede en la otra dirección: la validación del certificado del servidor por parte del cliente. El cliente desea asegurarse de que habla con el servidor correcto, por lo que verifica que el nombre del servidor esté presente en el certificado. La dirección IP del servidor, por otro lado, no está en el certificado del servidor; Se resolvió a través del DNS. Desde el punto de vista del cliente SSL, en lo que respecta a la seguridad, cómo los flujos de datos son irrelevantes; podría ir a cualquier dirección IP o transmitirse en un enlace serie sin IP o transportarse en la parte posterior de los camellos.
Respuesta corta: su certificado de cliente (probablemente) no está vinculado a una máquina específica, aunque solo sea porque hacer cumplir tal vinculación sería, en el mejor de los casos, difícil. Puede transferirlo de una máquina a otra (siempre que transfiera el certificado con su clave privada , por supuesto).