Proteggi le comunicazioni utilizzando SSL (Secure Sockets Layer)

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

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

WebSphere Application Server fornisce Java SE7. Per impostazione predefinita, Java SE 7 abilita SNI (Server Name Indication). SNI è un'estensione del protocollo TLS. SNI consente a un client di specificare il nome host a cui sta tentando di connettersi. Le eccezioni vengono generate se il certificato restituito non corrisponde al nome host previsto.

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

Gestione dei certificati X.509

Le comunicazioni protette per WebSphere Application Server richiedono certificati X.509 firmati digitalmente. Il contenuto di un certificato X.509 , come il suo DN (distinguished name) e la sua scadenza, è firmato da un'autorità di certificazione (CA), firmato da un certificato root in NodeDefaultRootStore o DmgrDefaultRootStore, oppure è autofirmato. Quando una CA attendibile firma un certificato X.509 , WebSphere Application Server identifica il certificato e lo distribuisce liberamente. Un certificato deve essere firmato da una CA perché il certificato rappresenta l'identità di un'entità per il pubblico. Le porte lato server che accettano le connessioni dal pubblico devono utilizzare i certificati firmati dalla CA. La maggior parte dei client o dei browser dispone già del certificato firmatario che può convalidare il certificato X.509 in modo che lo scambio del firmatario non sia necessario per una connessione riuscita.

Puoi considerare attendibile l'identità di un certificato X.509 autofirmato solo all'interno di un peer in un ambiente controllato, come le comunicazioni di rete interne, che 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à.

I certificati CA, concatenati e autofirmati X.509 risiedono in Java keystores. JSSE fornisce un riferimento al keystore in cui risiede un certificato. È possibile selezionare da molti tipi di keystore, inclusi i keystore basati su Java Cryptographic Extension (JCE) e quelli basati su hardware. In genere, ogni configurazione JSSE ha due riferimenti keystore Java: un keystore e un truststore. Il riferimento keystore rappresenta un oggetto keystore Java che contiene i certificati personali. Il riferimento truststore rappresenta un oggetto keystore Java che contiene i certificati del firmatario.

Un certificato personale senza una chiave privata è un certificato X.509 che rappresenta l'entità che lo possiede durante un handshake. I certificati personali contengono sia chiavi pubbliche che private. Un certificato del firmatario è un certificato X.509 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, consultare Aggiunta dei certificati del firmatario SSL corretti al keystore del plug-in

Per ulteriori informazioni sui keystore, consultare Configurazioni keystore per SSL.

Scambio firmatario

Quando configuri una connessione SSL, puoi scambiare i firmatari per stabilire l'attendibilità in un personal certificate per una specifica entità. Lo scambio del firmatario consente di estrarre il certificato X.509 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 avere origine da una CA come certificato del firmatario root o come certificato del firmatario root del certificato concatenato o come certificato del firmatario intermedio. È anche possibile estrarre un signer certificate direttamente da un certificato autofirmato, che è il certificato X.509 con la chiave pubblica.

La figura 1 illustra un'ipotetica configurazione di keystore e 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 non riesce perché il peer non può essere attendibile.

Figura 1. Scambio firmatario

In questo esempio, il truststore per l'entità A contiene tre firmatari. L'entità A può connettersi a qualsiasi peer fino a quando uno dei tre firmatari convalida il suo certificato personale. Ad esempio, l'Entità A può connettersi all'Entità B o all'Entità C in quanto i firmatari possono ritenere attendibili entrambi i certificati personali firmati. Il truststore per Entity-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 propria 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, generalmente ne firma molte alla volta. Il vantaggio di utilizzare un singolo firmatario della 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 essere consapevoli 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 vengano eseguite e di impedire quelle che non si desidera vengano eseguite.

Configurazioni SSL

Una configurazione SSL comprende una serie di attributi di configurazione che è possibile associare con un endpoint o una serie di endpoint nella topologia di WebSphere Application Server . La configurazione SSL consente di creare un oggetto SSLContext, che è l'oggetto JSSE fondamentale che il server utilizza per ottenere le produzioni socket SSL. È possibile gestire i seguenti attributi di configurazione:

Un alias per l'oggetto SSLContext
Una versione del protocollo handshake
Un riferimento keystore
Un riferimento truststore
Un gestore chiavi
Uno o più gestori sicuri
Una selezione del livello di sicurezza di un gruppo di suite di cifratura o un elenco di suite di cifratura specifico
Una scelta di alias di certificato per le connessioni client e server

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

Nota: WebSphere non consente alle suite di cifratura RC4 nell'elenco di cifratura HIGH di mantenere il server più sicuro per impostazione predefinita. È possibile che una cifratura RC4 sia stata utilizzata per impostazione predefinita negli handshake SSL prima di questa modifica. Con la rimozione delle cifrature RC4 , è probabile che venga utilizzata una cifratura AES . Gli utenti possono sperimentare una diminuzione delle prestazioni con l'uso di cifrature AES più sicure.

Selezione delle configurazioni SSL

Nelle release precedenti di WebSphere Application Server, era possibile fare riferimento a una configurazione SSL solo selezionando direttamente l'alias di configurazione SSL. Ogni endpoint protetto è stato indicato da un attributo alias che fa riferimento a una configurazione SSL valida in un repertorio di configurazioni SSL. Quando è stata apportata una singola modifica di configurazione, è stato necessario riconfigurare molti riferimenti alias nei diversi processi. Anche se la release corrente supporta ancora la selezione diretta, questo approccio non è più consigliato.

La release corrente fornisce funzioni migliorate per la gestione delle configurazioni SSL e maggiore flessibilità quando si selezionano le configurazioni SSL. In questa release, è 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.

Selezione dinamica

È possibile associare dinamicamente una configurazione SSL a uno specifico host di destinazione, porta o protocollo in uscita utilizzando un criterio di selezione predefinito. Quando stabilisce la connessione, WebSphere Application Server verifica se la porta e l'host di destinazione corrispondono a un criterio predefinito che include la parte di dominio dell'host. Inoltre, è possibile predefinire il protocollo per una configurazione SSL in uscita specifica e la selezione dell'alias del certificato.

La selezione dinamica in uscita delle configurazioni SSL (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 la creazione del socket client avviene in com.ibm.websphere.ssl.protocol.SSLSocketFactory. Per i connettori di gestione WebSphere come SOAP e RMI (Remote Method Invocation), le informazioni di connessione vengono inserite sul thread ed è disponibile per la selezione in uscita dinamica. Il processo di selezione in uscita dinamico risponde quando le informazioni di connessione vengono impostate quando le propriet ... SSL vengono richiamate in modo simile a quanto descritto in Specifica programmaticamente una configurazione SSL in uscita utilizzando l'API JSSEHelper.

Quando la connessione in uscita viene effettuata da applicazioni scritte dal cliente, parti delle informazioni di connessione potrebbero non essere disponibili. Alcune di queste applicazioni effettuano chiamate API a un protocollo per stabilire la connessione. L'API chiama quindi uno dei metodi createSocket() in com.ibm.websphere.ssl.protocol.SSLSocketFactory per completare il processo. Tutte le informazioni di connessione per la selezione in uscita dinamica potrebbero non essere disponibili e potrebbe essere necessario modificare il filtro di connessione di selezione in uscita dinamica e inserire un asterisco (*) per la parte mancante delle informazioni di 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 è stato fornito alcun protocollo. In questo caso, è necessario utilizzare un carattere jolly, l'asterisco (*), per la parte protocollo delle informazioni di connessione della selezione dinamica.

La maggior parte dei metodi createSocket() prende come parametri un host o un indirizzo IP e una porta. Il filtro di connessione di selezione in entrata dinamica può essere creato con l'host e la porta. Il metodo predefinito, createSocket(), senza alcun parametro, non contiene alcuna informazione per costruire il filtro di selezione delle connessioni in uscita, a meno che il socket factory non sia stato istanziato con informazioni sulle connessioni, Se non sono disponibili informazioni sulle connessioni, si dovrebbe considerare l'uso di uno degli altri metodi di selezione di una configurazione SSL descritti in questo argomento, "Selezione programmatica" può essere una buona scelta.

Evitare problemi: WebSphere Application Server si basa sulle informazioni su host, porta e protocollo trasmesse al factory di socket SSL WebSphere Application Server . Il factory del socket SSL di WebSphere Application Server può essere ignorato dalle impostazioni di configurazione o dall'applicazione, ovvero:

Il file java.security non contiene la specifica per il factory di socket WebSphere Application Server .
L'applicazione richiama direttamente un'altra produzione socket.

Se (1) o (2) è il caso, il processo di selezione in uscita SSL dinamico viene ignorato e la connessione non viene effettuata.

Selezione diretta: È possibile selezionare una configurazione SSL utilizzando un alias specifico, come nelle release precedenti. Questo metodo di selezione viene mantenuto per la 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 ambito di gestione WebSphere Application Server . Questo approccio è consigliato per gestire le configurazioni SSL centralmente. È possibile gestire gli endpoint in modo più efficiente perché si trovano in una vista topologia della cella. La relazione di eredità tra gli ambiti riduce il numero di assegnazioni di configurazione SSL che è necessario impostare.; Ogni volta che si associa una configurazione SSL ad un ambito cella, l'ambito nodo all'interno della cella eredita automaticamente le proprietà di configurazione. Tuttavia, quando si assegna una configurazione SSL ad 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 erediteranno 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 eredità dal livello cella al livello endpoint per ciascun server delle applicazioni.
Nota: se le applicazioni si basano su configurazioni SSL che sono state impostate come singole impostazioni per ciascuna configurazione SSL nella topologia, ma i server delle applicazioni hanno ereditato la configurazione SSL come distribuita dal livello cella fino al livello endpoint, è possibile che si verifichino errori di comunicazione tra i server (ad esempio, errori di handshake). È necessario assicurarsi che le proprie applicazioni funzionino in modo coerente con la gestione centrale delle configurazioni SSL.; La vista topologia visualizza una struttura ad albero in entrata e una struttura ad albero in uscita. È possibile effettuare diverse scelte 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. Per ulteriori informazioni, consultare Gestione centrale delle configurazioni SSL .

Il runtime utilizza un ordine di precedenza per determinare quale configurazione SSL scegliere poiché si dispone di molti modi per selezionare le configurazioni SSL. Considerare il seguente ordine di precedenza quando si seleziona un approccio di configurazione:

Selezione programmatica. Se un'applicazione imposta una configurazione SSL sul thread in esecuzione utilizzando l'API (application programming interface) com.ibm.websphere.ssl.JSSEHelper , alla configurazione SSL viene garantita la precedenza massima.
Criteri di selezione dinamici per host e porta o protocollo in uscita.
Selezione diretta.
Selezione ambito. L'eredità dell'ambito garantisce che l'endpoint selezionato sia associato a una configurazione SSL e sia ereditato da ogni ambito al di sotto di esso che non sovrascrive questa selezione.

Configurazione del certificato concatenato predefinito

Per impostazione predefinita, WebSphere Application Server crea un certificato concatenato univoco per ciascun nodo. Il certificato concatenato è firmato con una root, un certificato autofirmato memorizzato in DmgrDefaultRootStore o NodeDefaultRootStore. WebSphere Application Server non si basa più su un certificato autofirmato o sul certificato predefinito o fittizio fornito con il prodotto. Il keystore predefinito di key.p12 e il truststore trust.p12 sono memorizzati nel repository di configurazione all'interno della directory del nodo. Il certificato root predefinito viene memorizzato in root-key.p12 nel contenitore 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 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 root 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 può ora comunicare con tutti gli altri server nella cella.

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

Per ulteriori informazioni, consultare Default chained certificate configuration in SSL [ AIX Solaris HP-UX Linux Windows] e Web server plug-in default configuration in SSL.

Monitoraggio scadenza certificato

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'avvertenza prima che i certificati e i firmatari siano impostati per scadere. I certificati e i firmatari che si trovano nei keystore gestiti dalla configurazione di WebSphere Application Server possono essere monitorati. È possibile configurare il controllo scadenza per sostituire automaticamente un certificato. Un certificato concatenato verrà ricreato in base agli stessi dati utilizzati per la creazione iniziale e firmato con lo stesso certificato root che ha firmato il certificato originale. Un certificato autofirmato o un certificato concatenato viene ricreato in base agli stessi dati utilizzati per la creazione iniziale.

Il monitoraggio può anche sostituire automaticamente i vecchi firmatari con i firmatari dei nuovi certificati concatenati o autofirmati nei keystore gestiti da WebSphere Application Server. Gli scambi di firmatari esistenti che si sono verificati dal tempo di esecuzione durante la federazione e dalla gestione vengono conservati. Per ulteriori informazioni, vedi Monitoraggio della scadenza dei certificati in SSL.

Il monitor di scadenza è configurato per sostituire i certificati personali concatenati che sono firmati da un certificato radice in DmgrDefaultRootStore o NodeDefaultRootStore. Il certificato viene rinnovato utilizzando lo stesso certificato root utilizzato per firmare il certificato originale.

Il monitor può anche sostituire automaticamente i vecchi firmatari con i firmatari dei nuovi certificati autofirmati nei keystore gestiti da WebSphere Application Server. Gli scambi di firmatari esistenti che si sono verificati dal tempo di esecuzione durante la federazione e dalla gestione vengono conservati. Per ulteriori informazioni, vedi Monitoraggio della scadenza dei certificati in SSL.

Importante: per una catena di certificati scaduti o per una catena di certificati CA (Certificate Authority) scaduta, è necessario aggiornare l' intera catena. È necessario creare una nuova catena di certificati che abbia i singoli certificati firmatario. Per una catena di certificati CA, questa operazione potrebbe richiedere l'importazione di una nuova catena di certificati, di solito tramite un nuovo file di richiesta certificato (CSR).

Client WebSphere Application Server : requisiti di scambio del firmatario

Viene generato un nuovo certificato concatenato per ciascun nodo durante l'avvio iniziale. Per garantire l'attendibilità, i client devono disporre dei firmatari root per stabilire una connessione. L'introduzione dei certificati concatenati nella release 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 conservare l'attendibilità tra i rinnovi di certificati personali. Inoltre, è possibile ottenere l'accesso ai certificati del firmatario di vari nodi a cui il client deve connettersi con una delle seguenti opzioni (per ulteriori informazioni, consultare Installazione sicura per il richiamo del firmatario del client in SSL):

Una richiesta di scambio del firmatario consente di importare i 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 di gestione 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 le informazioni sul certificato e un digest SHA (Secure Hash Algorithm) del certificato per la verifica. L'utente ha la possibilità di scegliere se accettare queste credenziali. Se le credenziali vengono accettate, il firmatario viene aggiunto al truststore del client fino a quando il firmatario non viene esplicitamente rimosso. La richiesta di scambio del firmatario non si verifica di nuovo quando ci si connette allo stesso server a meno che il certificato personale non venga modificato.
Attenzione: non è sicuro considerare attendibile una richiesta di scambio del firmatario senza verificare il digest SHA. Una richiesta non verificata può essere originata da un browser quando un certificato non è attendibile.
È possibile eseguire uno script amministrativo retrieveSigners 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 server specificato nel truststore client specificato e può essere richiamato per scaricare solo un alias specifico da un truststore. È anche possibile richiamare lo script per caricare i firmatari nei truststore server. Quando si seleziona il truststore CellDefaultTrustStore come truststore server specificato e truststore comune per una cella, tutti i firmatari per quella cella vengono scaricati nel truststore client specificato, che di solito è ClientDefaultTrustStore. Per ulteriori informazioni, vedere il comando retrieveSigners.
È possibile distribuire fisicamente ai client il truststore comune trust.p12 ubicato nella directory della cella del repository di configurazione. Quando si esegue questa distribuzione, tuttavia, è necessario assicurarsi che la password corretta sia stata specificata nel file di configurazione SSL del client ssl.client.props . La password predefinita per questo truststore è WebAS. Modificare la password predefinita prima della distribuzione. La distribuzione fisica non è efficace come le opzioni precedenti. Quando vengono apportate modifiche ai certificati personali sul server, lo scambio automatico potrebbe non riuscire.

Modifiche alla configurazione SSL dinamica

Il runtime SSL per WebSphere Application Server conserva i listener per la maggior parte delle connessioni SSL. Una modifica alla configurazione SSL fa sì che i listener di 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.

Apportare modifiche dinamiche alla configurazione SSL durante le ore non di picco per ridurre la possibilità di problemi relativi alla tempistica e per impedire il riavvio del server. Se si abilita il runtime ad accettare modifiche dinamiche, modificare la configurazione SSL e salvare il file security.xml . Le modifiche diventano effettive quando il nuovo file security.xml raggiunge ogni nodo.

Nota: se le modifiche alla configurazione causano errori di handshake SSL, possono verificarsi anche errori di connettività di gestione, che possono causare interruzioni. In questo caso, è necessario riconfigurare le connessioni SSL, quindi eseguire la sincronizzazione manuale del nodo per correggere il problema. È necessario completare attentamente tutte le modifiche dinamiche. Si consiglia di eseguire le modifiche alle configurazioni SSL su un ambiente di test prima di effettuare le stesse modifiche su un sistema di produzione.

Gestione dei certificati integrata

La gestione dei certificati, paragonabile alle funzionalità di iKeyMan, è ora integrata nei pannelli di gestione dei keystore della console amministrativa. Utilizzare la gestione dei certificati integrata per gestire certificati personali, richieste di certificato e certificati del firmatario ubicati nei keystore. Inoltre, è possibile gestire in remoto i keystore. Ad esempio, è possibile gestire un keystore basato su file che si trova al di fuori del repository di configurazione su qualsiasi nodo dal gestore distribuzione. È anche possibile gestire in remoto i keystore crittografici hardware dal gestore distribuzione.

Con la gestione dei certificati integrata, è possibile sostituire un certificato concatenato o autofirmato insieme a tutti i certificati del firmatario sparsi in molti truststore e richiamare un firmatario da una porta remota collegandosi all'host e alla porta SSL remota e intercettando il firmatario durante l'handshake. 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 si effettua una richiesta di certificato, è possibile inviarla a un'autorità di certificazione (CA). Quando il certificato viene restituito, è possibile accettarlo nella console di amministrazione.

Consiglio: Sebbene la funzionalità iKeyMan venga ancora fornita con WebSphere Application Server, configurate i keystore dalla console amministrativa utilizzando la funzionalità di gestione dei certificati integrata. iKeyMan è ancora un'opzione quando non è conveniente usare la console amministrativa. Per ulteriori informazioni, vedi Gestione dei certificati utilizzando iKeyman prima di SSL.

Gestione configurazione AdminTask

I pannelli di gestione della configurazione SSL nella console di gestione si basano principalmente sulle attività di gestione, che sono gestite e migliorate per supportare la funzione della console di gestione. È possibile utilizzare i comandi wsadmin da un prompt della console Java per automatizzare la gestione di keystore, 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 usato nella richiesta, si controlla la voce DNSName nella SAN. Se la SAN non contiene una voce DNSName, la verifica del nome host 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 Contenuti del keystore 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 abilita la verifica del nome host e dell'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 client ssl.client.props, 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 di hostname e indirizzo IP nel file security.xml.

Ricordo: Il flag della proprietà com.ibm.ssl.performURLHostNameVerification applica la verifica dell'hostname solo quando viene utilizzato l'oggetto javax.net.ssl.HttpsURLConnection, mentre com.ibm.ssl.verifyHostname si applica a tutte le connessioni che utilizzano i factory socket 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.