Condividi tramite


Quali sono i certificati in Azure Stack Edge Pro GPU?

SI APPLICA A:Sì perSKU Pro GPU Azure Stack Edge Pro - GPUSì per Pro 2 SKUAzure Stack Edge Pro 2Sì perPro R SKU Azure Stack Edge Pro RSì per Mini R SKUAzure Stack Edge Mini R

Questo articolo descrive i tipi di certificati che possono essere installati nel dispositivo GPU Azure Stack Edge Pro. L'articolo include anche i dettagli per ogni tipo di certificato.

Informazioni sui certificati

Un certificato fornisce un collegamento tra una chiave pubblica e un'entità (ad esempio nome di dominio) firmata (verificata) da una terza parte attendibile (ad esempio un'autorità di certificazione). Un certificato offre un modo pratico per distribuire chiavi di crittografia pubblica attendibili. I certificati garantiscono quindi che la comunicazione sia attendibile e che si inviino informazioni crittografate al server corretto.

Distribuzione di certificati nel dispositivo

Nel dispositivo Azure Stack Edge è possibile usare i certificati autofirmato o portare i propri certificati.

Tipi di certificati

I vari tipi di certificati che è possibile portare per il dispositivo sono i seguenti:

  • Certificati di firma

    • CA radice
    • Intermedio
  • Certificati del nodo

  • Certificati endpoint

    • Certificati Resource Manager di Azure
    • Certificati di archiviazione BLOB
  • Certificati dell'interfaccia utente locale

  • Certificati dei dispositivi IoT

  • Certificati Kubernetes

    • Certificato del Registro contenitori Edge
    • Certificato del dashboard Kubernetes
  • certificati Wi-Fi

  • Certificati VPN

  • Certificati di crittografia

    • Certificati di sessione di supporto

Ogni tipo di certificato è descritto in dettaglio nelle sezioni seguenti.

Certificati della catena di firma

Questi sono i certificati per l'autorità che firmano i certificati o l'autorità di certificazione di firma.

Tipi

Questi certificati possono essere certificati radice o certificati intermedi. I certificati radice sono sempre autofirmati (o firmati da se stessi). I certificati intermedi non sono autofirmati e vengono firmati dall'autorità di firma.

Precisazioni

  • I certificati radice devono firmare i certificati della catena.
  • I certificati radice possono essere caricati nel dispositivo nel formato seguente:
    • DER : sono disponibili come .cer estensione di file.
    • Base-64 codificata : queste sono disponibili come .cer estensione di file.
    • P7b : questo formato viene usato solo per i certificati della catena di firma che includono i certificati radice e intermedi.
  • I certificati della catena di firma vengono sempre caricati prima di caricare altri certificati.

Certificati del nodo

Tutti i nodi del dispositivo comunicano costantemente tra loro e quindi devono avere una relazione di trust. I certificati del nodo consentono di stabilire tale attendibilità. I certificati del nodo vengono inoltre riprodotti quando si esegue la connessione al nodo del dispositivo usando una sessione di PowerShell remota su https.

Precisazioni

  • Il certificato del nodo deve essere fornito in .pfx formato con una chiave privata che può essere esportata.

  • È possibile creare e caricare 1 certificato nodo jolly o 4 certificati di nodo singolo.

  • Se il dominio DNS cambia, è necessario modificare un certificato del nodo, ma il nome del dispositivo non cambia. Se si sta portando il certificato del proprio nodo, non è possibile modificare il numero di serie del dispositivo, è possibile modificare solo il nome di dominio.

  • Usare la tabella seguente per guidarvi durante la creazione di un certificato del nodo.

    Tipo Nome soggetto (SN) Nome alternativo soggetto (SAN) Esempio di nome soggetto
    Nodo <NodeSerialNo>.<DnsDomain> *.<DnsDomain>

    <NodeSerialNo>.<DnsDomain>
    mydevice1.microsoftdatabox.com

Certificati endpoint

Per tutti gli endpoint esposti dal dispositivo, è necessario un certificato per la comunicazione attendibile. I certificati dell'endpoint includono quelli necessari quando si accede all'Resource Manager di Azure e all'archiviazione BLOB tramite le API REST.

Quando si porta un certificato firmato di propria proprietà, è necessaria anche la catena di firma corrispondente del certificato. Per la catena di firma, Azure Resource Manager e i certificati BLOB nel dispositivo, saranno necessari anche i certificati corrispondenti nel computer client per autenticare e comunicare con il dispositivo.

Precisazioni

  • I certificati dell'endpoint devono essere in .pfx formato con una chiave privata. La catena di firma deve essere formato DER (.cer estensione file).

  • Quando si apportano certificati endpoint personalizzati, questi possono essere come singoli certificati o certificati multidominio.

  • Se si sta eseguendo la catena di firma, il certificato della catena di firma deve essere caricato prima di caricare un certificato endpoint.

  • Questi certificati devono essere modificati se il nome del dispositivo o i nomi di dominio DNS cambiano.

  • È possibile usare un certificato endpoint con caratteri jolly.

  • Le proprietà dei certificati endpoint sono simili a quelle di un certificato SSL tipico.

  • Usare la tabella seguente durante la creazione di un certificato endpoint:

    Tipo Nome soggetto (SN) Nome alternativo soggetto (SAN) Esempio di nome soggetto
    Azure Resource Manager management.<Device name>.<Dns Domain> login.<Device name>.<Dns Domain>
    management.<Device name>.<Dns Domain>
    management.mydevice1.microsoftdatabox.com
    Archiviazione BLOB *.blob.<Device name>.<Dns Domain> *.blob.< Device name>.<Dns Domain> *.blob.mydevice1.microsoftdatabox.com
    Certificato singolo multi-SAN per entrambi gli endpoint <Device name>.<dnsdomain> <Device name>.<dnsdomain>
    login.<Device name>.<Dns Domain>
    management.<Device name>.<Dns Domain>
    *.blob.<Device name>.<Dns Domain>
    mydevice1.microsoftdatabox.com

Certificati dell'interfaccia utente locale

È possibile accedere all'interfaccia utente Web locale del dispositivo tramite un browser. Per assicurarsi che questa comunicazione sia sicura, è possibile caricare il proprio certificato.

Precisazioni

  • Il certificato dell'interfaccia utente locale viene caricato anche in un formato con una .pfx chiave privata che può essere esportata.

  • Dopo aver caricato il certificato dell'interfaccia utente locale, sarà necessario riavviare il browser e cancellare la cache. Fare riferimento alle istruzioni specifiche per il browser.

    Tipo Nome soggetto (SN) Nome alternativo soggetto (SAN) Esempio di nome soggetto
    Interfaccia utente locale <Device name>.<DnsDomain> <Device name>.<DnsDomain> mydevice1.microsoftdatabox.com

IoT Edge certificati del dispositivo

Il dispositivo è anche un dispositivo IoT con il calcolo abilitato da un dispositivo IoT Edge connesso. Per qualsiasi comunicazione sicura tra questo dispositivo IoT Edge e i dispositivi downstream che possono connettersi a esso, è anche possibile caricare i certificati IoT Edge.

Il dispositivo dispone di certificati autofirmato che possono essere usati se si vuole usare solo lo scenario di calcolo con il dispositivo. Se il dispositivo è tuttavia connesso ai dispositivi downstream, sarà necessario portare i propri certificati.

Sono disponibili tre certificati IoT Edge che è necessario installare per abilitare questa relazione di attendibilità:

  • Autorità di certificazione radice o autorità di certificazione del proprietario
  • Autorità di certificazione del dispositivo
  • Certificato chiave dispositivo

Precisazioni

  • I certificati di IoT Edge vengono caricati in .pem formato.

Per altre informazioni sui certificati IoT Edge, vedere Informazioni dettagliate sul certificato di Azure IoT Edge e Creare certificati di produzione IoT Edge.

Certificati Kubernetes

I certificati Kubernetes seguenti possono essere usati con il dispositivo Azure Stack Edge.

  • Certificato del Registro contenitori Edge: se il dispositivo dispone di un registro contenitori Edge, sarà necessario un certificato del Registro contenitori Edge per la comunicazione sicura con il client che accede al Registro di sistema nel dispositivo.
  • Certificato dell'endpoint del dashboard: è necessario un certificato dell'endpoint del dashboard per accedere al dashboard kubernetes nel dispositivo.

Precisazioni

  • Il certificato del Registro Contenitori Edge deve:

    • Essere un certificato di formato PEM.
    • Contenere nome alternativo soggetto (SAN) o CName (CN) di tipo: *.<endpoint suffix> o ecr.<endpoint suffix>. ad esempio *.dbe-1d6phq2.microsoftdatabox.com OR ecr.dbe-1d6phq2.microsoftdatabox.com
  • Il certificato del dashboard deve:

    • Essere un certificato di formato PEM.
    • Contenere nome alternativo soggetto (SAN) o CName (CN) di tipo: *.<endpoint-suffix> o kubernetes-dashboard.<endpoint-suffix>. Ad esempio, *.dbe-1d6phq2.microsoftdatabox.com o kubernetes-dashboard.dbe-1d6phq2.microsoftdatabox.com.

Certificati VPN

Se la VPN (da punto a sito) è configurata nel dispositivo, è possibile portare il proprio certificato VPN per assicurarsi che la comunicazione sia attendibile. Il certificato radice viene installato nel Gateway VPN di Azure e i certificati client vengono installati in ogni computer client che si connette a una rete virtuale usando punto a sito.

Precisazioni

  • Il certificato VPN deve essere caricato come formato pfx con una chiave privata.
  • Il certificato VPN non dipende dal nome del dispositivo, dal numero di serie del dispositivo o dalla configurazione del dispositivo. Richiede solo il nome di dominio completo esterno.
  • Assicurarsi che l'OID client sia impostato.

Per altre informazioni, vedere Generare ed esportare certificati per Il punto a sito usando PowerShell.

certificati Wi-Fi

Se il dispositivo è configurato per funzionare in una rete wireless WPA2-Enterprise, sarà necessario anche un certificato Wi-Fi per qualsiasi comunicazione che si verifica sulla rete wireless.

Precisazioni

  • Il certificato Wi-Fi deve essere caricato come formato pfx con una chiave privata.
  • Assicurarsi che l'OID client sia impostato.

Certificati di sessione di supporto

Se il dispositivo riscontra problemi, per risolvere questi problemi, è possibile aprire una sessione di supporto di PowerShell remota nel dispositivo. Per abilitare una comunicazione sicura e crittografata tramite questa sessione di supporto, è possibile caricare un certificato.

Precisazioni

  • Assicurarsi che il certificato corrispondente .pfx con chiave privata sia installato nel computer client usando lo strumento di decrittografia.

  • Verificare che il campo Utilizzo chiavi per il certificato non sia firma certificato. Per verificare questa operazione, fare clic con il pulsante destro del mouse sul certificato, scegliere Apri e nella scheda Dettagli trovare Utilizzo chiavi.

  • Il certificato sessione di supporto deve essere fornito come formato DER con un'estensione .cer .

Passaggi successivi

Esaminare i requisiti del certificato.