Error accessing backend service – WSO2 forgot password

Updated on November 26, 2021

I had configured WSO2 successfully and NGINX reverse proxy is set up as well. However, clicking forgot password link from the publisher or developer portal login pages lands me with the error – Error while accessing the backend service and looking at the wso2carbon.log file reveals more information:

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

error accessing backend service

Well, the error clearly indicates that the localhost URL is used by WSO2 to connect to the password recovery endpoint while using the SSL certificate issued for tg.com. Hence, the SSLHandshakeException “No subject alternative DNS name matching localhost found”. The issue here is, the SSL certificate was issued by the Let’s Encrypt certificate authority and it does not have Subject Alternative Name (SAN) set to ‘localhost‘, obviously. Click here to know why Let’s Encrypt does not support localhost as SAN.

Though WSO2 has been configured to use the hostname as tg.com, the service still connects localhost to access the password recovery endpoint. Here’s how the server hostname is configured in repository/conf/deployment.toml.

[server]
hostname = "tg.com"

So how we do let WSO2 know that it should be using the server hostname instead of relying on localhost?

WSO2 relies on localhost for internal API calls and you can see that in most of the configuration files (hardcoded with localhost). This configuration is utilized for building the internal absolute URLs of a service endpoint and is consumed when internal API calls are generated. Hence replacing ‘localhost‘ with the server hostname directly in the configuration files might lead to various other issues.

To configure the internal hostname, follow one of the two options:

Option 1: Setting the internal_hostname variable in the deployment.toml file.

Open the deployment.toml file located under ‘repository/conf/‘ folder and add the below line under [server] section.

internal_hostname = "tg.com"

Remember to change it with the desired hostname.

Option 2: Add localhost as Subject Alternative Name

Well, another option would be to generate a new self-signed certificate with localhost added to the SAN attribute.

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

Note: A self-signed certificate can only be used in the development and test environments.

Refer to this guide on how to set up Keystore for WSO2.

Was this article helpful?

Related Articles

Leave a Comment