J'avais configuré WSO2 avec succès et le proxy inverse NGINX est également configuré. Cependant, en cliquant sur le lien Mot de passe oublié depuis les pages de connexion du portail de l'éditeur ou du développeur, j'obtiens l'erreur - Erreur lors de l'accès au service backend et en regardant le wso2carbon.log le fichier révèle plus d'informations :
"ERROR {org.wso2.carbon.identity.mgt.endpoint.util.client.ApiClient} -
Error while performing the request method: GET on the resource: https://localhost:9443/api/identity/recovery/v0.9/captcha?tenant-domain=carbon.super&captcha-type=ReCaptcha&recovery-type=password-recovery com.sun.jersey.api.client.ClientHandlerException:
javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching localhost found".
Eh bien, l'erreur indique clairement que l'URL localhost est utilisée par WSO2 pour se connecter au point de terminaison de récupération de mot de passe tout en utilisant le certificat SSL émis pour tg.com. Par conséquent, l'exception SSLHandshakeException "Aucun nom DNS alternatif de sujet correspondant à l'hôte local n'a été trouvé". Le problème ici est que le certificat SSL a été émis par l'autorité de certification Let's Encrypt et qu'il n'a pas de nom alternatif de sujet (SAN) défini sur 'localhost ', évidemment. Cliquez ici pour savoir pourquoi Let's Encrypt ne prend pas en charge localhost en tant que SAN.
Bien que WSO2 ait été configuré pour utiliser le nom d'hôte en tant que tg.com, le service se connecte toujours à localhost pour accéder au point de terminaison de récupération de mot de passe. Voici comment le nom d'hôte du serveur est configuré dans repository/conf/deployment.toml .
[server] hostname = "tg.com"
Alors, comment faire savoir à WSO2 qu'il devrait utiliser le nom d'hôte du serveur au lieu de s'appuyer sur localhost ?
WSO2 s'appuie sur localhost pour les appels d'API internes et vous pouvez le voir dans la plupart des fichiers de configuration (codés en dur avec localhost). Cette configuration est utilisée pour créer les URL absolues internes d'un point de terminaison de service et est consommée lorsque des appels d'API internes sont générés. D'où le remplacement de 'localhost ' avec le nom d'hôte du serveur directement dans les fichiers de configuration peut entraîner divers autres problèmes.
Pour configurer le nom d'hôte interne, suivez l'une des deux options :
Option 1 :Définition du internal_hostname variable dans le deployment.toml fichier.
Ouvrez le deployment.toml fichier situé sous ‘repository/conf/ ' dossier et ajoutez la ligne ci-dessous sous [server] rubrique.
internal_hostname = "tg.com"
N'oubliez pas de le remplacer par le nom d'hôte souhaité.
Option 2 : Ajouter localhost comme nom alternatif du sujet
Eh bien, une autre option serait de générer un nouveau certificat auto-signé avec localhost ajouté à l'attribut SAN.
keytool -genkey -alias <alias_name> -keyalg RSA -keysize 2048 -keystore <keystore_name>.jks -dname "CN=<hostname>, OU=<organizational_unit>,O=<organization>,L=<Locality>,S=<State/province>,C=<country_code>" -storepass <keystore_password> -keypass <confirm_keystore_password> -ext SAN=dns:localhost -ext ExtendedKeyUsage=serverAuth -validity 825Remarque : Un certificat auto-signé ne peut être utilisé que dans les environnements de développement et de test.
Reportez-vous à ce guide pour savoir comment configurer Keystore pour WSO2.