Fehler beim Zugriff auf den Backend-Dienst – WSO2 hat das Passwort vergessen

Ich hatte WSO2 erfolgreich konfiguriert und NGINX-Reverse-Proxy ist ebenfalls eingerichtet. Wenn ich jedoch auf den Link „Passwort vergessen“ auf den Anmeldeseiten des Herausgeber- oder Entwicklerportals klicke, erhalte ich den Fehler – Fehler beim Zugriff auf den Back-End-Dienst und schauen Sie sich die wso2carbon.log an Datei gibt weitere Informationen preis:

"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".

Nun, der Fehler weist eindeutig darauf hin, dass die localhost-URL von WSO2 verwendet wird, um eine Verbindung zum Endpunkt der Kennwortwiederherstellung herzustellen, während das für tg.com ausgestellte SSL-Zertifikat verwendet wird. Daher die SSLHandshakeException „No subject alternative DNS name matching localhost found“. Das Problem hierbei ist, dass das SSL-Zertifikat von der Let’s Encrypt-Zertifizierungsstelle ausgestellt wurde und der Subject Alternative Name (SAN) nicht auf „localhost“ gesetzt ist ', offensichtlich. Klicken Sie hier, um zu erfahren, warum Let’s Encrypt localhost nicht als SAN unterstützt.

Obwohl WSO2 so konfiguriert wurde, dass es den Hostnamen als tg.com verwendet, verbindet der Dienst immer noch localhost um auf den Endpunkt für die Kennwortwiederherstellung zuzugreifen. So wird der Server-Hostname in repository/conf/deployment.toml konfiguriert .

[server]
hostname = "tg.com"

Wie lassen wir also WSO2 wissen, dass es den Hostnamen des Servers verwenden soll, anstatt sich auf localhost zu verlassen?

WSO2 verlässt sich auf localhost für interne API-Aufrufe und Sie können dies in den meisten Konfigurationsdateien sehen (fest codiert mit localhost). Diese Konfiguration wird zum Erstellen der internen absoluten URLs eines Dienstendpunkts verwendet und verbraucht, wenn interne API-Aufrufe generiert werden. Ersetzen Sie daher „localhost ‘ mit dem Server-Hostnamen direkt in den Konfigurationsdateien kann zu verschiedenen anderen Problemen führen.

Um den internen Hostnamen zu konfigurieren, folgen Sie einer der beiden Optionen:

Option 1 :Setzen des internal_hostname Variable in deployment.toml Datei.

Öffnen Sie die deployment.toml Datei, die sich unter „repository/conf/ befindet ‘-Ordner und fügen Sie die folgende Zeile unter [server] hinzu Abschnitt.

internal_hostname = "tg.com"

Denken Sie daran, ihn durch den gewünschten Hostnamen zu ersetzen.

Option 2: Fügen Sie localhost als alternativen Antragstellernamen hinzu

Nun, eine andere Option wäre, ein neues selbstsigniertes Zertifikat zu generieren, wobei localhost zum SAN-Attribut hinzugefügt wird.

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 825

Hinweis: Ein selbstsigniertes Zertifikat kann nur in den Entwicklungs- und Testumgebungen verwendet werden.

In dieser Anleitung erfahren Sie, wie Sie Keystore für WSO2 einrichten.