Enabling SSL communication for the Liberty application client container
The Liberty application client container might require some SSL configuration for the client container to communicate with a server. Configuring SSL for the application client container requires the use of the same SSL feature, ssl-1.0, that the server requires for SSL enablement. The configuration elements and attributes are the same for the application client as for the server; however, for the application client container, these values are specified in the client.xml file.
Pourquoi et quand exécuter cette tâche
The SSL handshake is a series of messages that are exchanged over the SSL protocol between a client and a server to negotiate for connection-specific protection. To enable SSL for the Liberty application client container the SSL feature, ssl-1.0, must include the minimal information that is needed to form an SSL configuration that is used by the client. The minimal information that is required to form an SSL configuration is a keystore and a password.
You can use the securityUtility createSSLCertificate command to create the keystore of the client and to provide you with information about the configuration. Using the tool is optional, because you can also create a keystore and the associated configuration for other customer-defined purposes.
Procédure
<keyStore id="defaultKeyStore" password="yourPassword" />
Il s'agit de la configuration minimum requise pour créer une configuration SSL. Avec cette configuration, le client crée le fichier de clés et le certificat s'il n'existe pas lors de l'initialisation SSL. Le mot de passe soumis doit comporter au moins six caractères. JKS est le type de magasin de clés par défaut et il est appelé key.jks, ces valeurs par défaut figurant dans le répertoire <client home>/resources/security.
Le client crée defaultKeyStore au premier démarrage lors de l'utilisation de la configuration précédente. Toutefois, lorsque le client crée le certificat par défaut, cela a un coût en termes de performances. Pour éviter cela, il est recommandé d'utiliser la commande securityUtilitiy createSSLCertificate pour créer le magasin de clés par défaut utilisé dans la configuration defaultKeyStore.
Si vous avez besoin d'une configuration SSL personnalisée, consultez Liberty : attributs de configuration SSL.
- Acceptation des certificats de signataire
- Si le client n'a pas établi de relation de confiance avec le
serveur, la communication avec le client invite l'utilisateur à
accepter le certificat du serveur. Si l'utilisateur répond par
l'affirmative
(yes), le certificat est reçu et stocké dans
la configuration de magasin de clés du client et la commande se
poursuit.
Si l'utilisateur répond
no,
aucune relation de confiance n'est établie et l'appel se termine en
erreur.Voici un exemple de cette invite :
*** SSL SIGNER EXCHANGE PROMPT *** The SSL signer from target host is not found in trust store C:/liberty/workspace/build.image/wlp/usr/clients/myTestClient/resources/security/key.jks. Here is the signer information (verify the digest value matches what is displayed at the server): Subject DN: CN=localhost, O=ibm, C=us Issuer DN: CN=localhost, O=ibm, C=us Serial number: 1327582458 Expires: Sun Jan 04 06:54:18 CST 2099 SHA-1 Digest: 00:6F:25:F1:78:5D:EB:00:B1:E2:99:DB:E8:D7:DF:3B:F8:E0:20:9A Add signer to the trust store now? (y/n)
You might receive the following error message if the user specifies no when asked to add the signer to the truststore:[ERROR ] CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN CN=localhost, O=ibm, C=us sent from the target host. The signer might need to be added to local trust store C:/liberty/workspace/build.image/wlp/usr/clients/myTestClient/resources/security/key.jks, located in SSL configuration alias defaultSSLConfig. The extended error message from the SSL handshake exception is: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: java.security.cert.CertPathValidatorException: The certificate issued by SubjectDN CN=localhost, O=ibm, C=us is not trusted; internal cause is: java.security.cert.CertPathValidatorException: Certificate chaining error throw able: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: PKIX path building failed: java.security.cert.CertPathBuilderException : PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: java.security.cert.CertPathValidatorException: The certificate issued by SubjectDN CN=localhost, O=ibm, C=us is not trusted; internal cause is: java.security.cert.CertPathValidatorException: Certificate chaining error
- Acceptation automatique du certificat de signataire
- Si le client ne souhaite pas être invité à spécifier le certificat de signataire et choisit d'accepter le certificat de signataire de serveur sans examiner le certificat, l'utilisateur peut fournir l'indicateur -autoAcceptSigner sur la ligne de commande de conteneur client.
client run client_name --autoAcceptSigner
- Authentification du client
- Si le client communique avec un serveur sur lequel l'authentification client est activée, il est nécessaire que ce serveur établisse une relation de confiance avec le client tout comme le client fait confiance au serveur. Le client doit avoir une clé, ainsi qu'un certificat personnel, dans son magasin de clés. Si vous utilisez la commande securityUtility createSSLCertificate, le magasin de clés contient un certificat personnel. Le serveur avec lequel communique le conteneur de l'application client doit faire confiance au client ; pour cette raison, le signataire du client doit être ajouté au magasin de clés de confiance du serveur. Vous pouvez utiliser l'outil Java, keytool, pour extraire le signataire du magasin de clés du conteneur de l'application client et ajouter le certificat du client au magasin de clés de confiance du serveur.