Comunicazioni sicure tramite Secure Sockets Layer (SSL)

Il protocollo Secure Sockets Layer (SSL) fornisce la sicurezza del livello di trasporto inclusa l'autenticità, la firma dei dati e la crittografia dei dati per garantire una connessione sicura tra un client e un server che utilizza WebSphere® Application Server. La tecnologia di base per SSL è la crittografia a chiave pubblica, che garantisce che quando un'entità crittografa i dati utilizzando la sua chiave pubblica, solo le entità con la chiave privata corrispondente possono decrittografare tali dati.

WebSphere Application Server utilizza Java™ Secure Sockets Extension (JSSE) come implementazione SSL per connessioni sicure. JSSE fa parte di Java 2 Standard Edition ( J2SE ) specifica ed è inclusa nella IBM® implementazione della Java Runtime Extension (JRE). JSSE gestisce le funzionalità di negoziazione e protezione dell'handshake fornite da SSL per garantire che esista una connettività sicura nella maggior parte dei protocolli. JSSE si basa su X.509 coppie di chiavi asimmetriche basate su certificato per la protezione sicura della connessione e la crittografia dei dati. Le coppie di chiavi crittografano in modo efficace le chiavi segrete basate sulla sessione che crittografano blocchi di dati più grandi. L'implementazione SSL gestisce il file X.509 certificati.

WebSphere Application Server spedisce Java SE7. Per impostazione predefinita Java SE 7 abilita l'indicazione del nome del server (SNI). SNI è un'estensione del protocollo TLS. SNI consente a un client di specificare il nome host a cui sta tentando di connettersi. Vengono generate eccezioni se il certificato restituito non corrisponde al nome host previsto.

In alcuni ambienti proxy ciò causerà errori. Il client si aspetta di ricevere il certificato del proxy, ma riceve invece il certificato del server endpoint.

Gestire X.509 certificati

Comunicazioni sicure per WebSphere Application Server richiedono la firma digitale X.509 certificati. Il contenuto di un X.509 certificato, come il nome distinto e la scadenza, sono firmati da un'autorità di certificazione (CA), firmati da un certificato radice inNodeDefaultRootStore ODmgrDefaultRootStore o sono autofirmati. Quando una CA attendibile firma un X.509 certificato, WebSphere Application Server identifica il certificato e lo distribuisce liberamente. Un certificato deve essere firmato da una CA perché rappresenta l'identità di un'entità per il pubblico in generale. Le porte lato server che accettano connessioni dal pubblico generale devono utilizzare certificati firmati CA. La maggior parte dei client o browser dispone già del certificato del firmatario in grado di convalidare il file X.509 certificato in modo che lo scambio di firmatari non sia necessario per una connessione riuscita.

Puoi fidarti dell'identità di un autofirmato X.509 certificato solo all'interno di un peer in un ambiente controllato, come le comunicazioni di rete interne, accetta il certificato del firmatario. Per completare un handshake attendibile, devi prima inviare una copia del certificato dell'entità a ogni peer che si connette all'entità.

CA, concatenato e autofirmato X.509 i certificati risiedono in Javakeystores . JSSE fornisce un riferimento all'archivio chiavi in cui risiede un certificato. È possibile scegliere tra molti tipi di archivi di chiavi, inclusi archivi di chiavi basati su Java Cryptographic Extension (JCE) e basati su hardware. In genere, ogni configurazione JSSE ha due riferimenti al keystore Java: un keystore e un filetruststore . Il riferimento al keystore rappresenta un oggetto del keystore Java che contiene certificati personali. Il riferimento al truststore rappresenta un oggetto keystore Java che contiene i certificati del firmatario.

Un certificato personale senza chiave privata è un X.509 certificato che rappresenta l'entità che lo possiede durante un handshake. I certificati personali contengono sia chiavi pubbliche che private. Un certificato del firmatario è un file X.509 certificato che rappresenta un'entità peer o se stesso. I certificati del firmatario contengono solo la chiave pubblica e verificano la firma dell'identità ricevuta durante un handshake peer-to-peer.

Per ulteriori informazioni, vedere Aggiunta dei certificati SSL Signer corretti all'archivio chiavi del plug-in

Per ulteriori informazioni sui keystore, vedere Configurazioni dell'archivio chiavi per SSL.

Scambio di firmatari

Quando configuri una connessione SSL, puoi scambiare i firmatari per stabilire la fiducia in apersonal certificate per un ente specifico. Lo scambio di firmatari consente di estrarre il file X.509 certificato dal keystore peer e aggiungerlo al truststore di un'altra entità in modo che le due entità peer possano connettersi. Il certificato del firmatario può anche provenire da una CA come certificato del firmatario root o certificato del firmatario root di un certificato concatenato o certificato del firmatario intermedio. Puoi anche estrarre asigner certificate direttamente da un certificato autofirmato, che è il file X.509 certificato con la chiave pubblica.

La Figura 1 illustra un'ipotetica configurazione del keystore e del truststore. Una configurazione SSL determina quali entità possono connettersi ad altre entità e le connessioni peer considerate attendibili da un handshake SSL. Se non si dispone del certificato del firmatario necessario, l'handshake fallisce perché il peer non può essere considerato attendibile.

Figura 1. Scambio di firmatari

In questo esempio, il truststore per l'entità A contiene tre firmatari. L'entità A può connettersi a qualsiasi peer purché uno dei tre firmatari convalidi il proprio certificato personale. Ad esempio, l'Entità A può connettersi all'Entità B o all'Entità C perché i firmatari possono fidarsi di entrambi i certificati personali firmati. Il truststore per l'entità B contiene un firmatario. L'entità B è in grado di connettersi solo all'entità C e solo quando l'endpoint peer utilizza il certificato Entity-C Cert 1 come identità. Le porte che utilizzano l'altro certificato personale per l'entità C non sono considerate attendibili dall'entità B. L'entità C può connettersi solo all'entità A.

Nell'esempio, la configurazione autofirmata sembra rappresentare una relazione uno a uno tra il firmatario e il certificato. Tuttavia, quando una CA firma un certificato, in genere ne firma più certificati alla volta. Il vantaggio di utilizzare un singolo firmatario CA è che può convalidare i certificati personali generati dalla CA per l'utilizzo da parte dei peer. Tuttavia, se il firmatario è una CA pubblica, è necessario tenere presente che i certificati firmati potrebbero essere stati generati per un'altra società diversa dall'entità di destinazione. Per le comunicazioni interne, le CA private e i certificati autofirmati sono preferibili alle CA pubbliche perché consentono di isolare le connessioni che si desidera che si verifichino e di impedire che si verifichino quelle che non si desidera che si verifichino.

Configurazioni SSL

Una configurazione SSL comprende una serie di attributi di configurazione che è possibile associare a un endpoint o a una serie di endpoint nel file WebSphere Application Server topologia. La configurazione SSL consente di creare un oggetto SSLContext, che è l'oggetto JSSE fondamentale utilizzato dal server per ottenere factory di socket SSL. È possibile gestire i seguenti attributi di configurazione:

Un alias per l'oggetto SSLContext
Una versione del protocollo di handshake
Un riferimento al keystore
Un riferimento al truststore
Un manager chiave
Uno o più gestori del trust
Una selezione del livello di sicurezza di un raggruppamento di suite di crittografia o di un elenco di suite di crittografia specifico
Una scelta di alias di certificato per le connessioni client e server

Per comprendere le specifiche di ciascun attributo di configurazione SSL, vedere Configurazioni SSL.

Nota: WebSphere non consente ilRC4 suite di crittografia inHIGH elenco di codici per mantenere il server più sicuro per impostazione predefinita. È possibile che unRC4 la crittografia veniva utilizzata per impostazione predefinita negli handshake SSL prima di questa modifica. Con la rimozione delRC4 cifre, è probabile che anAES viene invece utilizzata la cifratura. Gli utenti possono riscontrare un calo delle prestazioni con l'utilizzo di soluzioni più sicureAES cifre.

Selezione delle configurazioni SSL

Nelle versioni precedenti di WebSphere Application Server, puoi fare riferimento a una configurazione SSL solo selezionando direttamente l'alias di configurazione SSL. Ogni endpoint sicuro è stato indicato da un attributo alias che fa riferimento a una configurazione SSL valida all'interno di un repertorio di configurazioni SSL. Quando apportavi una singola modifica alla configurazione, dovevi riconfigurare molti riferimenti alias nei vari processi. Sebbene la versione corrente supporti ancora la selezione diretta, questo approccio non è più consigliato.

La versione attuale fornisce funzionalità migliorate per la gestione delle configurazioni SSL e maggiore flessibilità quando si selezionano configurazioni SSL. In questa versione è possibile scegliere tra i seguenti approcci:

Selezione programmatica: È possibile impostare una configurazione SSL sul thread in esecuzione prima di una connessione in uscita. WebSphere Application Server garantisce che la maggior parte dei protocolli di sistema, compresi Internet Inter-ORB Protocol (IIOP), Java Message Service (JMS), Hyper Text Transfer Protocol ( HTTP ) e Lightweight Directory Access Protocol (LDAP), accettino la configurazione. Vedere Specificazione a livello di codice di una configurazione SSL in uscita utilizzando l'API JSSEHelper

Selezione dinamica

È possibile associare dinamicamente una configurazione SSL a un host, una porta o un protocollo in uscita di destinazione specifico utilizzando criteri di selezione predefiniti. Quando stabilisce la connessione, WebSphere Application Server controlla se l'host e la porta di destinazione corrispondono a criteri predefiniti che includono la parte di dominio dell'host. Inoltre, puoi predefinire il protocollo per una specifica configurazione SSL in uscita e la selezione dell'alias del certificato. Vedere Selezione dinamica in uscita delle configurazioni Secure Sockets Layer per maggiori informazioni.

La selezione dinamica in uscita delle configurazioni Secure Sockets Layer si basa sulle informazioni di connessione disponibili per il server in modo che il server possa corrispondere al protocollo in uscita, all'host o alla porta quando avviene la creazione del socket client in com.ibm.websphere.ssl.protocol.SSLSocketFactory. Per WebSphere connettori di amministrazione come SOAP e Remote Method Invocation (RMI), le informazioni di connessione vengono inserite nel thread e sono disponibili per la selezione dinamica in uscita. Il processo di selezione dinamica in uscita risponde alle informazioni di connessione impostate quando le proprietà SSL vengono recuperate in modo simile a quanto descritto in Specificazione a livello di codice di una configurazione SSL in uscita utilizzando l'API JSSEHelper.

Quando la connessione in uscita viene stabilita da richieste scritte dal cliente, alcune parti delle informazioni sulla connessione potrebbero non essere disponibili. Alcune di queste applicazioni effettuano chiamate API a un protocollo per stabilire la connessione. Alla fine l'API chiama uno dei file createSocket() metodi in com.ibm.websphere.ssl.protocol.SSLSocketFactory per completare il processo. Tutte le informazioni sulla connessione per la selezione dinamica in uscita potrebbero non essere disponibili e potrebbe essere necessario modificare il filtro di connessione per la selezione dinamica in uscita e inserire un asterisco (*) per la parte mancante delle informazioni sulla connessione. Ad esempio, la chiamata openConnection( ) su un oggetto URL richiama in definitiva createSocket(java.net.Socket socket, String host, int port, boolean autoClose). Le informazioni di connessione possono essere create con l'host e la porta forniti, ma non viene fornito alcun protocollo. In questo caso, è necessario utilizzare un carattere jolly, asterisco (*), per la parte relativa al protocollo delle informazioni sulla connessione di selezione dinamica.

La maggior parte del createSocket() accettano un host o un indirizzo IP e una porta come parametri. Il filtro di connessione di selezione in uscita dinamica può essere creato con l'host e la porta. Il metodo predefinito, createSocket(), senza parametri non contiene alcuna informazione per creare il filtro di connessione di selezione in uscita a meno che il socket factory non sia stato istanziato con informazioni di connessione. Se non sono disponibili informazioni di connessione, dovresti prendere in considerazione l'utilizzo di uno degli altri metodi di selezione di una configurazione SSL descritta in questo argomento, "Selezione programmatica" può essere una buona scelta.

Evitare problemi: WebSphere Application Server si basa sulle informazioni su host, porta e protocollo passate al WebSphere Application Server Presa SSL di fabbrica. IL WebSphere Application Server Il socket SSL Factory può essere bypassato dalle impostazioni di configurazione o dall'applicazione, ovvero:

IL java.security il file non contiene le specifiche per il file WebSphere Application Server presa di fabbrica
l'applicazione chiama direttamente un'altra socket factory. Se si verifica il caso (1) o (2), il processo di selezione in uscita SSL dinamico viene ignorato e la connessione non viene stabilita.

Selezione diretta: È possibile selezionare una configurazione SSL utilizzando un alias specifico, come nelle versioni precedenti. Questo metodo di selezione viene mantenuto per compatibilità con le versioni precedenti poiché molte applicazioni e processi si basano su riferimenti alias.
Selezione ambito: È possibile associare una configurazione SSL e il relativo alias del certificato, che si trova nel keystore associato a tale configurazione SSL, con un WebSphere Application Server ambito gestionale. Questo approccio è consigliato per gestire le configurazioni SSL a livello centrale. È possibile gestire gli endpoint in modo più efficiente perché si trovano in una vista topologica della cella. La relazione di ereditarietà tra gli ambiti riduce il numero di assegnazioni di configurazione SSL che è necessario impostare.; Ogni volta che si associa una configurazione SSL a un ambito di cella, l'ambito del nodo all'interno della cella eredita automaticamente le proprietà di configurazione. Tuttavia, quando assegni una configurazione SSL a un nodo, la configurazione del nodo sovrascrive la configurazione che il nodo eredita dalla cella. Allo stesso modo, tutti i server delle applicazioni per un nodo ereditano automaticamente la configurazione SSL per quel nodo a meno che non si sovrascrivano queste assegnazioni. A meno che non si sovrascriva una configurazione specifica, la topologia si basa sulle regole di ereditarietà dal livello della cella fino al livello dell'endpoint per ciascun server delle applicazioni.
Nota: Se le tue applicazioni si basano su configurazioni SSL impostate come impostazioni individuali per ciascuna configurazione SSL nella topologia, ma i tuoi server delle applicazioni hanno ereditato la configurazione SSL distribuita dal livello della cella fino al livello dell'endpoint, allora esiste la possibilità di comunicazione errori che si verificano tra i server (ad esempio, errori di handshake). È necessario garantire che le applicazioni funzionino in modo coerente con la gestione centrale delle configurazioni SSL.; La vista della topologia mostra un albero in entrata e un albero in uscita. È possibile effettuare diverse selezioni di configurazione SSL per ciascun lato della connessione SSL in base a ciò a cui si connette il server come connessione in uscita e a ciò a cui si connette il server come connessione in entrata. Vedere Gestione centralizzata delle configurazioni SSL per maggiori informazioni.

Il runtime utilizza un ordine di precedenza per determinare quale configurazione SSL scegliere poiché sono disponibili molti modi per selezionare le configurazioni SSL. Considera il seguente ordine di precedenza quando selezioni un approccio di configurazione:

Selezione programmatica. Se un'applicazione imposta una configurazione SSL sul thread in esecuzione utilizzando il file com.ibm.websphere.ssl.JSSEHelper interfaccia di programmazione dell'applicazione (API), alla configurazione SSL è garantita la massima precedenza.
Criteri di selezione dinamici per host e porta o protocollo in uscita.
Selezione diretta.
Selezione dell'ambito. L'ereditarietà dell'ambito garantisce che l'endpoint selezionato sia associato a una configurazione SSL e venga ereditato da ogni ambito sottostante che non sovrascriva questa selezione.

Configurazione predefinita dei certificati concatenati

Per impostazione predefinita, WebSphere Application Server crea un certificato concatenato univoco per ciascun nodo. Il certificato concatenato viene firmato con una root, un certificato autofirmato archiviato nel fileDmgrDefaultRootStore ONodeDefaultRootStore . WebSphere Application Server non si basa più su un certificato autofirmato o sul certificato predefinito o fittizio fornito con il prodotto. ILkey.p12 archivio chiavi predefinito e il file trust.p12 truststore sono archiviati nel repository di configurazione all'interno della directory del nodo. Il certificato radice predefinito è archiviato nel file root-key.p12 nel repository di configurazione nella directory del nodo.

Quando si federa un server delle applicazioni di base, si verificano le seguenti situazioni: il keystore e il truststore vengono inclusi e il certificato del firmatario viene aggiunto al truststore comune del gestore distribuzione, che si trova nella directory della cella del repository di configurazione.

Tutti i nodi inseriscono i certificati del firmatario dal certificato radice predefinito in questo truststore comune (trust.p12 ). Inoltre, dopo aver federato un nodo, la configurazione SSL predefinita viene modificata automaticamente per puntare al truststore comune, che si trova nella directory della cella. Il nodo ora può comunicare con tutti gli altri server nella cella.

Tutte le configurazioni SSL predefinite contengono un archivio di chiavi con il suffisso del nome DefaultKeyStore, un truststore con il suffisso del nome DefaultTrustStore e un rootstore con il suffisso del nome DefaultRootStore. Questi suffissi predefiniti istruiscono il WebSphere Application Server runtime per aggiungere il firmatario root del certificato personale al truststore comune. Se il nome di un truststore non termina con DefaultKeyStore, i certificati del firmatario root del keystore non vengono aggiunti al truststore comune quando si federa il server. È possibile modificare la configurazione SSL predefinita, ma è necessario assicurarsi che venga stabilita la corretta attendibilità, tra le altre, per le connessioni amministrative.

Per ulteriori informazioni, vedere Configurazione predefinita del certificato concatenato in SSL [ AIX Solaris HP-UX Linux Finestre] E Configurazione predefinita del plug-in del server Web in SSL.

Monitoraggio della scadenza dei certificati

Il monitoraggio dei certificati garantisce che il certificato concatenato predefinito per ciascun nodo non possa scadere. La funzione di monitoraggio della scadenza del certificato emette un avviso prima che i certificati e i firmatari scadano. I certificati e i firmatari che si trovano negli archivi chiavi gestiti da WebSphere Application Server la configurazione può essere monitorata. È possibile configurare il monitoraggio della scadenza per sostituire automaticamente un certificato. Un certificato concatenato verrà ricreato in base agli stessi dati utilizzati per la creazione iniziale e lo firmerà con lo stesso certificato radice che ha firmato il certificato originale. Viene ricreato anche un certificato autofirmato o un certificato concatenato in base agli stessi dati utilizzati per la creazione iniziale.

Il monitor può anche sostituire automaticamente i vecchi firmatari con i firmatari dei nuovi certificati concatenati o autofirmati negli archivi chiavi gestiti da WebSphere Application Server. Gli scambi di firmatari esistenti avvenuti dal runtime durante la federazione e dall'amministrazione vengono conservati. Per ulteriori informazioni, vedere Monitoraggio della scadenza del certificato in SSL.

Il monitoraggio della scadenza è configurato per sostituire i certificati personali concatenati firmati da un certificato radice in DmgrDefaultRootStore O NodeDefaultRootStore. Il certificato viene rinnovato utilizzando lo stesso certificato radice utilizzato per firmare il certificato originale.

Il monitor può anche sostituire automaticamente i vecchi firmatari con i firmatari dei nuovi certificati autofirmati negli archivi chiavi gestiti da WebSphere Application Server. Gli scambi di firmatari esistenti avvenuti dal runtime durante la federazione e dall'amministrazione vengono conservati. Per ulteriori informazioni, vedere Monitoraggio della scadenza del certificato in SSL.

Importante: Per una catena di certificati scaduta o una catena di certificati di un'autorità di certificazione (CA) scaduta, è necessario aggiornare il file intero catena. È necessario generare una nuova catena di certificati con i singoli certificati del firmatario. Per una catena di certificati CA, ciò potrebbe richiedere l'importazione di una nuova catena di certificati, in genere tramite un nuovo file di richiesta di certificato (CSR).

WebSphere Application Server client: requisiti di scambio di firmatari

Un nuovo certificato concatenato viene generato per ciascun nodo durante il suo avvio iniziale. Per garantire la fiducia, ai client devono essere forniti i firmatari root per stabilire una connessione. L'introduzione dei certificati concatenati nella versione corrente rende questo processo più semplice. Invece di scambiare il firmatario di un certificato autofirmato di breve durata, è possibile scambiare il firmatario root di lunga durata che consentirà di preservare la fiducia durante i rinnovi dei certificati personali. Inoltre, puoi accedere ai certificati del firmatario dei vari nodi a cui il client deve connettersi con una qualsiasi delle seguenti opzioni (per ulteriori informazioni, vedere Installazione sicura per il recupero del firmatario del client in SSL):

Una richiesta di scambio firmatario consente di importare certificati del firmatario che non sono ancora presenti nei truststore durante una connessione a un server. Per impostazione predefinita, questa richiesta è abilitata per le connessioni amministrative e può essere abilitata per qualsiasi configurazione SSL del client. Quando questa richiesta è abilitata, qualsiasi connessione effettuata a un server in cui il firmatario non è già presente offre al firmatario del server insieme alle informazioni sul certificato e un digest Secure Hash Algorithm (SHA) del certificato per la verifica. All'utente viene data la possibilità di scegliere se accettare queste credenziali. Se le credenziali vengono accettate, il firmatario viene aggiunto al truststore del client finché non viene rimosso esplicitamente. La richiesta di scambio del firmatario non si ripresenta quando ci si connette allo stesso server a meno che non venga modificato il certificato personale.
Attenzione: Non è sicuro fidarsi di una richiesta di scambio di firmatari senza verificare il digest SHA. Una richiesta non verificata può provenire da un browser quando un certificato non è attendibile.
Puoi eseguire a retrieveSigners script amministrativo da un client prima di effettuare connessioni ai server. Per scaricare i firmatari non è richiesta alcuna autorità amministrativa. Per caricare i firmatari, è necessario disporre dell'autorità del ruolo di Amministratore. Lo script scarica tutti i firmatari da un truststore del server specificato nel truststore del client specificato e può essere chiamato per scaricare solo un alias specifico da un truststore. Puoi anche chiamare lo script per caricare i firmatari sui truststore del server. Quando selezioni il CellDefaultTrustStore truststore come truststore del server specificato e truststore comune per una cella, tutti i firmatari di quella cella vengono scaricati nel truststore del client specificato, che in genere è ClientDefaultTrustStore. Per ulteriori informazioni, vedere retrieveSigners comando.
Puoi distribuire fisicamente ai clienti il file trust.p12 truststore comune che si trova nella directory della cella del repository di configurazione. Quando si esegue questa distribuzione, tuttavia, è necessario assicurarsi che sia stata specificata la password corretta nel filessl.client.props file di configurazione SSL del client. La password predefinita per questo truststore èWebAS . Modificare la password predefinita prima della distribuzione. La distribuzione fisica non è efficace quanto le opzioni precedenti. Quando vengono apportate modifiche ai certificati personali sul server, lo scambio automatizzato potrebbe non riuscire.

Modifiche alla configurazione SSL dinamica

Il runtime SSL per WebSphere Application Server mantiene gli ascoltatori per la maggior parte delle connessioni SSL. Una modifica alla configurazione SSL fa sì che i listener della connessione in entrata creino un nuovo oggetto SSLContext. Le connessioni esistenti continuano a utilizzare l'oggetto SSLContext corrente. Le connessioni in uscita utilizzano automaticamente le nuove proprietà di configurazione quando vengono tentate.

Apporta modifiche dinamiche alla configurazione SSL durante le ore non di punta per ridurre la possibilità di problemi legati alla tempistica e per impedire la possibilità che il server si riavvii. Se abiliti il runtime ad accettare modifiche dinamiche, modifica la configurazione SSL e salva il filesecurity.xml file. Le modifiche avranno effetto al momento del nuovosecurity.xml il file raggiunge ciascun nodo.

Mancia: Se le modifiche alla configurazione causano errori di handshake SSL, possono verificarsi anche errori di connettività amministrativa, che possono portare a interruzioni. In questo caso, è necessario riconfigurare le connessioni SSL quindi eseguire la sincronizzazione manuale del nodo per correggere il problema. È necessario completare con attenzione qualsiasi modifica dinamica. Si consiglia vivamente di apportare modifiche alle configurazioni SSL in un ambiente di test prima di apportare le stesse modifiche a un sistema di produzione. Per ulteriori informazioni, vedere Aggiornamenti dinamici della configurazione in SSL.

Gestione dei certificati integrata

Gestione dei certificati paragonabile a iKeyMan la funzionalità è ora integrata nei pannelli di gestione del keystore della console amministrativa. Utilizza la gestione dei certificati integrata per gestire i certificati personali, le richieste di certificato e i certificati del firmatario che si trovano negli archivi chiavi. Inoltre, puoi gestire in remoto gli archivi chiavi. Ad esempio, è possibile gestire un archivio chiavi basato su file che si trova all'esterno del repository di configurazione su qualsiasi nodo del gestore distribuzione. È inoltre possibile gestire in remoto gli archivi di chiavi crittografiche hardware dal gestore distribuzione.

Con la gestione dei certificati integrata, puoi sostituire un certificato concatenato o autofirmato insieme a tutti i certificati del firmatario sparsi in molti truststore e recuperare un firmatario da una porta remota collegandoti all'host e alla porta SSL remoti e intercettando il firmatario durante la stretta di mano. Il certificato viene prima convalidato in base al digest SHA del certificato, quindi l'amministratore deve accettare il certificato convalidato prima che possa essere inserito in un truststore.

Quando effettui una richiesta di certificato, puoi inviarla a un'autorità di certificazione (CA). Quando il certificato viene restituito, è possibile accettarlo nella console di amministrazione. Per ulteriori informazioni, vedere Gestione dei certificati in SSL.

Mancia: Sebbene iKeyMan la funzionalità viene ancora fornita con WebSphere Application Server, configurare gli archivi chiavi dalla console di gestione utilizzando la funzionalità di gestione dei certificati integrata. iKeyMan è ancora un'opzione quando non è conveniente utilizzare la console di amministrazione. Per ulteriori informazioni, vedere Gestione dei certificati utilizzando iKeyman prima dell'SSL.

AdminTask gestione della configurazione

I pannelli di gestione della configurazione SSL nella console di amministrazione si basano principalmente su attività amministrative, che vengono mantenute e migliorate per supportare la funzione della console di amministrazione. È possibile utilizzare i comandi wsadmin da un prompt della console Java per automatizzare la gestione di archivi chiavi, configurazioni SSL, certificati e così via.

Verifica del nome host e dell'indirizzo IP

La verifica del nome host e dell'indirizzo IP è abilitata per impostazione predefinita per le comunicazioni SSL. La verifica verifica che il nome host o l'indirizzo IP nel sito URL corrisponda al Subject Alternative Name (SAN) nel certificato SSL del server. Se la SAN non viene trovata, la proprietà si assicura che il nome host in URL corrisponda al nome comune (CN). Se esiste una mancata corrispondenza, la connessione SSL viene rifiutata.

In genere, durante la verifica dell'hostname, quando il nome dell'host viene utilizzato nella richiesta, si controlla la voce DNSName nella SAN. Se la SAN non contiene una voce DNSName, la verifica dell'hostname utilizza il nome comune (CN) del proprietario del certificato. Quando nella richiesta viene utilizzato un indirizzo IP, la verifica dell'hostname si basa solo sulle informazioni dell'indirizzo IP nella SAN. Per ulteriori informazioni, vedere Contenuto del truststore predefinito.

Configurazione delle proprietà del client SSL

Le seguenti proprietà controllano la verifica del nome host e dell'indirizzo IP.

La proprietà com.ibm.ssl.verifyHostname consente di verificare il nome dell'host e l'indirizzo IP. Per impostazione predefinita è impostato su true.
La proprietà com.ibm.ssl.skipHostnameVerificationForHosts è un elenco separato da virgole di nomi di host, indirizzi IP o entrambi. La verifica del nome host e dell'indirizzo IP per gli elementi dell'elenco viene saltata anche se la proprietà com.ibm.ssl.verifyHostname è impostata su true. Per impostazione predefinita, questa proprietà è una stringa vuota, il che significa che tutti i nomi di host e gli indirizzi IP sono verificati.

Per ulteriori informazioni sulla configurazione di queste proprietà per il file ssl.client.props del client, vedere ssl.client.props file di configurazione del client.

Per ulteriori informazioni sulla configurazione di queste proprietà nel file security.xml, vedere Configurazione della verifica del nome host e dell'indirizzo IP nel file security.xml.

Ricordare: Il flag della proprietà com.ibm.ssl.performURLHostNameVerification impone la verifica dell'hostname solo quando viene usato l'oggetto javax.net.ssl.HttpsURLConnection, mentre com.ibm.ssl.verifyHostname si applica a tutte le connessioni che usano i socket factory WebSphere.

Risoluzione degli errori SSL

La verifica del nome host e dell'indirizzo IP è abilitata per impostazione predefinita. È possibile che si verifichino errori di handshake SSL se esiste una mancata corrispondenza tra il nome host o l'indirizzo IP di URL e il certificato SSL.

Ad esempio, si potrebbe visualizzare un errore del tipojava.security.cert.CertificateException: No subject alternative DNS name matching MYHOST.com. Assicurarsi che il nome host o l'indirizzo IP di URL corrisponda al Subject Alternative Name (SAN) del certificato SSL del server. Se la SAN non viene trovata, verificare che il nome host o l'indirizzo IP in URL corrisponda invece al nome comune (CN).

Per ulteriori informazioni, vedere java.security.cert.CertificateException: Nessun soggetto che corrisponde a un nome DNS alternativo MYHOST.com.