Configuré WSO2 con éxito y el proxy inverso NGINX también está configurado. Sin embargo, al hacer clic en el enlace de contraseña olvidada de las páginas de inicio de sesión del portal de editores o desarrolladores, aparece el error:Error al acceder al servicio backend y mirando el wso2carbon.log archivo revela más información:
"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".
Bueno, el error indica claramente que WSO2 usa la URL del host local para conectarse al punto final de recuperación de contraseña mientras usa el certificado SSL emitido para tg.com. Por lo tanto, la SSLHandshakeException "No se encontró ningún nombre de DNS alternativo del asunto que coincida con el host local". El problema aquí es que el certificado SSL fue emitido por la autoridad de certificación de Let's Encrypt y no tiene el nombre alternativo del sujeto (SAN) establecido en 'localhost ', obviamente. Haga clic aquí para saber por qué Let's Encrypt no es compatible con localhost como SAN.
Aunque WSO2 se configuró para usar el nombre de host como tg.com, el servicio aún se conecta a localhost para acceder al punto final de recuperación de contraseña. Así es como se configura el nombre de host del servidor en repository/conf/deployment.toml .
[server] hostname = "tg.com"
Entonces, ¿cómo le hacemos saber a WSO2 que debería usar el nombre de host del servidor en lugar de confiar en localhost?
WSO2 se basa en localhost para llamadas API internas y puede verlo en la mayoría de los archivos de configuración (codificados con localhost). Esta configuración se utiliza para crear las direcciones URL absolutas internas de un punto de conexión de servicio y se consume cuando se generan llamadas de API internas. Por lo tanto, reemplazando 'localhost ' con el nombre de host del servidor directamente en los archivos de configuración podría generar otros problemas.
Para configurar el nombre de host interno, siga una de las dos opciones:
Opción 1 :Configuración del internal_hostname variable en deployment.toml archivo.
Abra el deployment.toml archivo ubicado en 'repository/conf/ ‘carpeta y agregue la siguiente línea debajo de [server] sección.
internal_hostname = "tg.com"
Recuerde cambiarlo con el nombre de host deseado.
Opción 2: Agregue localhost como nombre alternativo del sujeto
Bueno, otra opción sería generar un nuevo certificado autofirmado con localhost agregado al atributo 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
Consulte esta guía sobre cómo configurar Keystore para WSO2.