Activation de la communication SSL pour le conteneur du client d'application Liberty
Le conteneur du client d'application Liberty peut nécessiter une configuration SSL afin de pouvoir communiquer avec un serveur. La configuration de SSL pour le conteneur du client d'application requiert l'utilisation de la même fonction SSL, ssl-1.0, que celle requise par le serveur pour l'activation SSL. Les éléments et les attributs de configuration sont les mêmes pour le client d'application que pour le serveur ; toutefois, pour le conteneur du client d'application, ces valeurs sont spécifiées dans le fichier client.xml.
Pourquoi et quand exécuter cette tâche
Ce dernier est une série de messages échangés sur le protocole SSL entre un client et un serveur pour négocier les modalités de protection de la connexion. Pour activer SSL pour le conteur du client d'application Liberty, la fonction SSL, ssl-1.0 doit inclure les informations minimales qui sont nécessaires pour former une configuration SSL utilisée par le client. Les informations minimales nécessaires pour former une configuration SSL sont un magasin de clés et un mot de passe.
Vous pouvez utiliser securityUtility createSSLCertificatecommand pour créer le magasin de clés du client et pour vous fournir les informations relatives à la configuration. L'utilisation de l'outil est facultative, car vous pouvez aussi créer un magasin de clés et la configuration associée à d'autres fins définies par le client.
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, voir Profil 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.