Rilascio dei certificati SSL per il pacchetto software di automazione dei dispositivi senza nomi di dominio

Penso che ci siano due opzioni qui:

1. Certificato lato server - in questo caso è necessario ottenere un certificato sul server. Hostname invece di indirizzo IP è un must ed è molto preferibile su Internet e farà risparmiare ai tuoi clienti un sacco di problemi in futuro. È presente un campo "altSubject ..." nel certificato in cui è possibile immettere un indirizzo IP che verrà comunque convalidato. Ora, il client necessita solo di un client SSL e il certificato rilasciato da una CA attendibile dal client SSL funzionerà.
2. Certificato sul lato client: puoi essere la CA e rilasciare i tuoi certificati a tutti i tuoi clienti e finché il tuo server Web stabilisce la validità del certificato del cliente in arrivo, dimostra identità e riservatezza dei trasporti. Naturalmente, anche questi possono essere emessi dalla CA. Questo approccio sarebbe leggermente preferibile nel tuo scenario in quanto potresti revocare certs che non pagano il tuo software e comunque vuoi usarlo:)

Il tuo problema è dal lato del cliente. In una connessione SSL, il client deve utilizzare la chiave pubblica del server e, pertanto, deve assicurarsi di conoscere la chiave corretta ; l'obiettivo di un utente malintenzionato sarebbe quello di indurre il cliente a utilizzare una chiave pubblica falsa. SSL definisce che il server invia la sua chiave pubblica come parte di una catena di certificati, che il client quindi convalida (il processo complesso di verificare le firme, le date, lo stato di revoca e molte estensioni). Ma un certificato valido non insegna molto al cliente come se stesso; il client deve assicurarsi di conoscere il certificato del server . Pertanto, il client deve cercare "l'identità del server prevista" nel certificato (valido).

Quindi hai due faccette importanti sull'argomento:

• Il certificato del server deve essere valido rispetto a un determinato insieme di trust anchors (ovvero "certificati radice") che il client considera a priori .

• Il certificato del server deve contenere la sua identità in modo da convincere il cliente.

Nel consueto contesto Web, il client è un browser Web e il fornitore del browser (o fornitore del sistema operativo) lo ha già fornito con un enorme set di "CA radice predefinita". La corrispondenza dell'identità è descritta in RFC 2818 : poiché il client tenta di connettersi a un URL che include un nome host , il client cercherà lo stesso nome host in un paio di punti del certificato (la parte CN del nome soggetto e nell'estensione Nome alt soggetto). Questo è dove "i nomi di dominio" hanno un impatto: il nome che il cliente cerca nel certificato è anche il nome che il client usa contro il DNS per sapere dove in realtà connettersi.

Se controlli sia il codice client sia il codice server , puoi scegliere il meccanismo che desideri. Il client potrebbe "conoscere" la chiave pubblica del server a priori (codificata nel codice o tramite un file di configurazione locale) e ignorare totalmente il certificato del server. Il client può convalidare il certificato per quanto riguarda qualsiasi set di CA che si ritiene opportuno, non necessariamente la stessa CA di quelli inclusi nei browser Web. Potresti mantenerlo tuo: se questo è solo per i tuoi server, la CA emetterà al massimo un paio di certificati all'anno, quindi può usare una tecnologia piuttosto rozza (vorrai tenerlo in una cassastrong, ma può usare software a basso costo e procedure manuali; vedere ad esempio EJBCA o anche OpenSSL ). E, ultimo ma non meno importante, non è necessario cercare l'identità del server negli stessi posti di quanto richiesto dalla RFC 2818. Pertanto, non vi è alcun obbligo di fare scherzi con i nomi di dominio .

Se non controlli il codice cliente (ad esempio il client è un browser Web o un codice di libreria esistente che insiste a utilizzare le stesse regole dei browser Web, ad es. RFC 2818), allora necessità, per definizione, di rispettare gli usi Web: collegamento con nomi di dominio, certificati da una CA "riconosciuta" (una che è considerata affidabile dal sistema client).

Un certificato SSL fornisce l'autenticità di un nome comune , che nel mondo di HTTPS è il nome del dominio. In sostanza, il browser verifica un certificato basato sulla convalida del certificato e sul confronto del nome comune con il dominio corrente. Pertanto, per www.example.com , il certificato deve avere un nome comune che corrisponda a www.example.com . Potrebbe non corrispondere direttamente, poiché sono disponibili certificati di caratteri jolly sottodominio che corrisponderanno a *.example.com . Tuttavia, un certificato generato per foobar.com non potrà mai corrispondere a barfoo.com o viceversa. Tieni presente che l'implementazione è strettamente all'interno del browser.

Tuttavia, in un'implementazione client personalizzata, puoi applicare il nome comune in qualsiasi modo tu ritenga opportuno. Potrebbe essere il nome reale di una persona, un GUID, un indirizzo IP, ecc. In effetti, i dati memorizzati all'interno del campo del nome comune non sono importanti, ma l'applicazione di tali dati rispetto a una vera identità è. Il motivo per cui viene utilizzato un nome di dominio è perché un dominio può rappresentare una varietà di indirizzi IP. I record DNS per un particolare host potrebbero avere un A record (indirizzo IPv4), un AAAA record (indirizzo IPv6), un MX record (server di posta), ecc. In realtà, può avere più di un A record, per bilanciare il carico su più host fisici. Inoltre, gli indirizzi IP possono essere dinamici e vengono spesso riallocati. Ciò significa che un singolo sito non può sempre essere identificato dal suo indirizzo IP. Generare e mantenere certificati SSL per tutti gli indirizzi IP associati al proprio dominio sarebbe ingombrante e richiederebbe la nuova emissione di nuovi certificati se l'indirizzo IP dovesse cambiare. Questo è tutt'altro che ideale, quindi avere un singolo certificato SSL per autenticare il dominio è una soluzione migliore.

Ciò che non capisco è il motivo per cui i tuoi server non dovrebbero essere associati a un nome di dominio. L'emissione manuale dei certificati SSL agli indirizzi IP sarà dolorosa e sarà molto più difficile ottenere una CA notevolissima da firmare per te. Richiederò anche di spingere gli aggiornamenti del prodotto se i tuoi IP del server cambiano, invece di modificare da solo il record DNS. Se i tuoi clienti devono raggiungere il tuo server da un nuovo dispositivo, dovranno annotare il tuo IP e inviarlo, piuttosto che memorizzare semplicemente un nome di dominio facile. Inoltre, puoi raccogliere domini per quasi nulla: solo in alcuni casi $ 10 / anno.