Trasferimento certificato client

X.509 è ampio e versatile e, in teoria, qualsiasi cosa vada.

In pratica, presumo che si stia parlando di una situazione SSL / TLS, probabilmente come parte di un sito Web HTTPS. Il server invia il suo certificato (che il client convalida), quindi il server chiede al client di mostrare anche un certificato, che verrà convalidato dal server.

In questa situazione, non ci possono essere molti dati specifici del client che il server può validare. Il punto importante è che la convalida del certificato client avviene sul server (necessariamente: il certificato del client riguarda la convinzione del server). Pertanto, se il server desidera convalidare alcuni dati specifici del client (ad es. Indirizzo IP), il server deve avere accesso a un indirizzo IP client apparente e vedere se corrisponde a ciò che verrebbe scritto nel certificato . Tuttavia, nell'ecosistema HTTPS, si verificano NAT e proxy. Pertanto, l'indirizzo IP "vero" del client non può essere ottenuto in modo affidabile dal server (ad esempio il mio vero indirizzo IP è 10.0.1.101, ma non è quello che vedrebbe un server HTTPS, perché sono dietro sia a NAT che un proxy SOCKS). Quindi non c'è nulla da convalidare per il server.

Nei sistemi esistenti implementati, i server SSL / TLS non convalidano comunemente i certificati client per quanto riguarda le informazioni specifiche del cliente. Non l'ho mai visto. Invece, il server convalida il certificato in abstracto (l'intera attività di firma-da-CA, fino a una CA radice), indipendentemente dalla provenienza apparente della connessione in entrata. E se il certificato viene convalidato, l'utente identità viene estratto dal certificato (utilizzando un metodo specifico del server, ma IIS tenderà a guardare l'estensione del nome alt soggetto e ad estrarre "UPN", per corrisponde a ciò che si trova nel suo server Active Directory) e il server è soddisfatto.

In realtà è abbastanza simile a ciò che accade nell'altra direzione: convalida del certificato del server da parte del client. Il cliente vuole assicurarsi che parli con il server giusto, quindi verifica che il nome del server sia effettivamente presente nel certificato. L'indirizzo IP del server, d'altra parte, non è nel certificato del server; è stato risolto tramite il DNS. Dal punto di vista del client SSL, per quanto riguarda la sicurezza, in che modo i flussi di dati sono irrilevanti; potrebbe andare su qualsiasi indirizzo IP o essere trasmesso su un collegamento seriale senza IP o essere trasportato sul retro dei cammelli.

Risposta breve: il tuo certificato client è (probabilmente) non vincolato a una macchina specifica, se non altro perché imporre tale associazione sarebbe, nel migliore dei casi, difficile. Puoi trasferirlo da una macchina all'altra (a condizione che tu trasferisca il certificato con la sua chiave privata , ovviamente).

Il tipico getcha che impedisce ai certs di essere trasferiti su una nuova macchina è che Windows consente alle chiavi private di essere contrassegnate come "non esportabili" e in alcuni casi questa è l'impostazione predefinita. Poiché il certificato è inutile senza la chiave privata, questo lega efficacemente il certificato a un singolo server a meno che non si abbia un'altra copia della chiave.

Si noti che è possibile per estrarre comunque la chiave privata usando un po 'di hackery, ma non è banale.

I certificati sono considerati informazioni pubbliche e si limitano a legare una chiave a un'identità. Il trasferimento del certificato non comporterà nulla poiché la macchina che ha ricevuto il certificato non ha la chiave che l'identità si lega.

È come se ti avessi dato la mia licenza. Non riesci ancora a dimostrare che tu sia me perché la mia licenza dimostra che I sono io, non chiunque lo tenga.

Devi trasferire la chiave privata che la licenza associa all'identità.