GNU/Linux >> Znalost Linux >  >> Linux

Chyba při přístupu k backendové službě – WSO2 zapomnělo heslo

Úspěšně jsem nakonfiguroval WSO2 a je také nastaven reverzní proxy NGINX. Po kliknutí na odkaz zapomenuté heslo na přihlašovací stránce portálu vydavatele nebo vývojáře se však zobrazí chyba – Chyba při přístupu k backendové službě a podívejte se na wso2carbon.log soubor odhaluje další informace:

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

Chyba jasně naznačuje, že adresu URL localhost používá WSO2 k připojení ke koncovému bodu obnovení hesla při použití certifikátu SSL vydaného pro tg.com. Proto byla výjimka SSLHandshake „Nenalezen žádný alternativní název DNS subjektu odpovídající localhost“. Problém je v tom, že SSL certifikát byl vydán certifikační autoritou Let’s Encrypt a nemá Subject Alternative Name (SAN) nastavený na ‘localhost ', očividně. Kliknutím sem zjistíte, proč Let’s Encrypt nepodporuje localhost jako SAN.

Přestože byl WSO2 nakonfigurován tak, aby používal název hostitele jako tg.com, služba stále připojuje localhost pro přístup ke koncovému bodu obnovení hesla. Zde je návod, jak je název hostitele serveru nakonfigurován v repository/conf/deployment.toml .

[server]
hostname = "tg.com"

Jak tedy dáme WSO2 vědět, že by měl používat název hostitele serveru namísto spoléhání se na localhost?

WSO2 spoléhá na localhost pro interní volání API a můžete to vidět ve většině konfiguračních souborů (pevně zakódovaných pomocí localhost). Tato konfigurace se používá pro vytváření interních absolutních adres URL koncového bodu služby a je spotřebována při generování interních volání API. Proto nahrazení „localhost s názvem hostitele serveru přímo v konfiguračních souborech může vést k různým dalším problémům.

Chcete-li nakonfigurovat interní název hostitele, postupujte podle jedné ze dvou možností:

Možnost 1 :Nastavení internal_hostname proměnná v deployment.toml soubor.

Otevřete soubor deployment.toml soubor umístěný pod ‘repository/conf/ ‘ a přidejte řádek níže pod [server] sekce.

internal_hostname = "tg.com"

Nezapomeňte jej změnit na požadovaný název hostitele.

Možnost 2: Přidat localhost jako Subject Alternative Name

No, další možností by bylo vygenerovat nový certifikát s vlastním podpisem s localhost přidaným do atributu 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 825

Poznámka: Certifikát s vlastním podpisem lze použít pouze ve vývojovém a testovacím prostředí.

Informace o tom, jak nastavit úložiště klíčů pro WSO2, naleznete v této příručce.


Linux
  1. [OpenStack-Devstack]:Chyba:Služba n-net neběží při provádění stack.sh

  2. Načítání veřejného klíče není povoleno – chyba WSO2 MySQL

  3. Chyba při použití GRANT s IDENTIFIKOVANÝM heslem v MySQL

  1. Přístup k odběru v Plesk má za následek chybu

  2. Oprava „chyby manipulace s autentizačním tokenem“ v Ubuntu Linux

  3. CHYBA 1045 (28000):Přístup odepřen uživateli 'root'@'localhost' (pomocí hesla:ANO)

  1. Přístup k Mysql pomocí terminálu v Ubuntu 13.04?

  2. CHYBA:Výjimka PleskMainDBE

  3. Příkaz „ntpq -pn“ se vrátí s chybou „Název nebo služba není známa“