In caso di autenticazione del certificato client, chi dovrebbe emettere il certificato client?
Il fornitore di servizi che espone l'API o il consumatore cliente che consuma l'API?
Nella mia esperienza, ho visto entrambi gli approcci, ma mi piacerebbe sapere cosa dicono i testi sacri.
Il consumatore dell'API dovrebbe generare una CSR, solitamente, in modo tale che ci sia la certezza che il consumatore sia l'unica parte con la chiave privata corrispondente per il certificato. L'emissione del certificato può quindi essere eseguita dal fornitore di servizi (firmati dal servizio), dal client (autofirmato) o da una CA di terze parti (firmata dalla CA).
Se il fornitore di servizi crea la CSR del cliente, esiste un problema di integrità, in quanto potrebbe potenzialmente rilasciare lo stesso certificato a più utenti finali. Questo non è sempre un problema, se il certificato viene utilizzato per proteggere un canale e se ad esempio sono necessari ulteriori passaggi per l'autenticazione o se viene utilizzato per una connessione iniziale in cui è possibile trasferire una chiave pubblica specifica del client, ma non è l'ideale.
Analogamente, se il servizio richiede che il certificato client sia firmato da una terza parte fidata, che non funzionerà se il servizio lo genera, i passaggi di verifica da parte di terzi si applicheranno quindi al servizio, piuttosto che all'effettivo utente finale, annullando i benefici. Non è particolarmente raro che i service provider firmino i certificati client, tuttavia, che consente loro di avere una lista molto piccola di certificati radice affidabili (i propri), e non richiede che il client esponga la chiave privata a nessuno. Invece, il client invia un CSR al servizio, ottiene un certificato in risposta e può utilizzarlo insieme alla chiave, che non ha mai lasciato il controllo.
who should issue the client certificate?
Un'autorità approvata che è considerata affidabile dal fornitore di servizi API. Non è necessario il fornitore di servizi API stesso (sebbene sia comune), questa attività può essere delegata a un'altra entità che seguirà i requisiti stabiliti dal provider API. Se delegato, il provider API deve essere certo che solo i client legittimi e debitamente autenticati ricevono i certificati client.
Certamente, non è compito del cliente creare certificati client.
A seconda dei casi particolari, potrebbero esserci diversi scenari comuni:
Questo è l'approccio più semplice. Il client genera CSR e lo invia alla CA del fornitore di servizi. Quando la richiesta è correttamente autenticata e convalidata, il client riceve un certificato firmato che viene poi utilizzato per accedere all'API.
Pro: il provider di servizi tiene traccia di tutti i singoli client e i loro certificati.
Contro: il fornitore di servizi deve mantenere tutta l'infrastruttura per lavorare con la convalida delle richieste dei clienti e mantenerle (rinnovare, riemettere, revocare, ecc.). Potrebbe avere un notevole overhead (per entrambe le parti) quando le entità client non sono strettamente definite. Cioè, quando hai solo 5 clienti, questo approccio è certamente buono. Quando ne hai migliaia, questo potrebbe essere un problema, perché il fornitore di servizi dovrà seguire lo SLA.
Questa opzione è necessaria per disporre di un PKI privato operabile in entrambe le organizzazioni, provider di servizi e organizzazione client. L'organizzazione cliente può avere un numero elevato di entità client a cui è consentito accedere al fornitore di servizi.
Pro: riduce i costi di gestione dei certificati sul fornitore di servizi. Soprattutto quando il numero esatto e il nome delle entità client non sono noti in anticipo (ad esempio, l'accesso è concesso su base di partenza). Consente una migliore gestione del ciclo di vita dei certificati all'interno dell'organizzazione del cliente.
Contro: richiede un trust qualificato tra l'organizzazione del cliente e l'organizzazione del fornitore di servizi. Ciò apre un buco quando l'organizzazione del cliente può erroneamente valutare i certificati client e non è considerata attendibile. Questa domanda viene comunemente risolta utilizzando le verifiche PKI da parte di una società di revisione di terze parti. Ci sarà una politica scritta che descrive tutte le relazioni tecniche e legali tra le organizzazioni. Ma questo approccio è anche costoso (audit, politiche di scrittura, ecc.).
In alcuni casi, questo scenario è cresciuto a più di solo 2 organizzazioni e per limitare un numero di certificati incrociati, una CA Bridge è costruita per organizzare un trust tra le organizzazioni.
Non sono d'accordo con la risposta di Crypt32.
(Suppongo per "problema" che intendi "segno")
Dovrebbe essere un'entità fidata sia dal fornitore del servizio che dal client, e dovrebbe essere qualcuno altro rispetto al fornitore di servizi e al client.
Poiché il fornitore di servizi presumibilmente si fida del client una volta autenticato, non è irragionevole affidarsi all'organizzazione del cliente per firmare il certificato del cliente, tuttavia in termini pratici rende molto più difficile la manutenzione del fornitore di servizi di un numero elevato di Certificati CA.
Lo scopo del certificato è quello di identificare pubblicamente un'entità, quindi, mentre è verosimile che il client possa fidarsi del provider per firmare un certificato per loro, questo di solito fornisce solo un certificato che può essere convalidato dal fornitore di servizi . Se il certificato è stato utilizzato nelle interazioni con altri fornitori, fornisce al fornitore originale il controllo sulle interazioni dei clienti con gli altri.
Utilizzo di una terza parte poiché la CA fornisce protezione sia al cliente che al fornitore e separa i problemi tecnici e organizzativi (contrattuali) relativi alla gestione dei certificati dalla relazione esistente attorno al servizio.
Leggi altre domande sui tag authentication tls certificates