search

wso2 / analytics-apim

Analytics for APIM
Apache License 2.0
55 stars 126 forks source link

wso2am-analytics-3.1.0-beta:-Analytics dashboard is redirecting to localhost after changing the host name #1024

Closed premchandragupta closed 2 years ago

premchandragupta commented 4 years ago

wso2am-analytics-3.1.0-beta:-Analytics dashboard is redirecting to localhost after changing the host name

After changing the host name, Analytics dashboard is redirecting to localhost. Therefore can't access the Analytics dashboard

Dashboard URL:-https://myhostname:9643/analytics-dashboard Redirecting URL when accessing analytics dashboard:-https://localhost:9443/oauth2/authorize?response_type=code&client_id=VACHtG8hNxzG2au1EcA3sNmmXooa&scope=apim_analytics%3Aadmin%20apim_analytics%3Aproduct_manager%20apim_analytics%3Aapi_developer%20apim_analytics%3Aapp_developer%20apim_analytics%3Adevops_engineer%20apim_analytics%3Aanalytics_viewer%20apim_analytics%3Aeveryone%20openid%20apim%3Aapi_view%20apim%3Asubscribe&redirect_uri=https%3A%2F%2Flocalhost%3A9643%2Flogin%2Fcallback%2Fanalytics-dashboard%2Flogin

Supporting Information:- 1. Using wso2am-3.1.0-beta and wso2am-analytics-3.1.0-beta

  1. Able to access publisher and devportal
RAVEENSR commented 4 years ago

Can you share your auth.configs in the dashboard deployment.yaml file?

premchandragupta commented 4 years ago

Hi Raveen, Thanks for responding. Please find below config-

Authentication configuration

auth.configs: type: apim ssoEnabled: true properties: adminScope: apim_analytics:admin_carbon.super allScopes: apim_analytics:admin apim_analytics:product_manager apim_analytics:api_developer apim_analytics:app_developer apim_analytics:devops_engineer apim_analytics:analytics_viewer apim_analytics:everyone openid apim:api_view apim:subscribe adminServiceBaseUrl: https://localhost:9443 adminUsername: admin adminPassword: admin kmDcrUrl: https://localhost:9443/client-registration/v0.16/register kmTokenUrlForRedirection: https://localhost:9443/oauth2 kmTokenUrl: https://localhost:9443/oauth2 kmUsername: admin kmPassword: admin portalAppContext: analytics-dashboard businessRulesAppContext : business-rules cacheTimeout: 900 baseUrl: https://localhost:9643 grantType: authorization_code publisherUrl: https://localhost:9443

storeUrl: https://localhost:9443

externalLogoutUrl: https://localhost:9443/oidc/logout

Note:- Please note that in the process of changing host name I've followed two steps:-

  1. Changed host name in deployment.toml in APIM
  2. Changed host name in service providers in carbon-admin_sp_analytics_dashboard, admin_apim_publisher, admin_apim_devportal

Please let me know if you need more information.

RAVEENSR commented 4 years ago

Hi @premchandragupta,

adminServiceBaseUrl, kmDcrUrl, kmTokenUrlForRedirection,kmTokenUrl,publisherUrl and externalLogoutUrl should be pointed to APIM hostname according to your use case. So please change the hostname of these fields accordingly. baseUrl is where your APIM Analytics server is running. Change the value of that field as well according to your need.

premchandragupta commented 4 years ago

Hi @RAVEENSR , I updated the config according to your suggestion. I am getting below error in the log while accessing analytics dashboard URL-

Unmapped exception feign.RetryableException: No subject alternative DNS name matching myhostname found. executing GET https://myhostname:9443/api/am/admin/v0.16/custom-urls/carbon.super at feign.FeignException.errorExecuting(FeignException.java:67) at feign.SynchronousMethodHandler.executeAndDecode(SynchronousMethodHandler.java:104) at feign.SynchronousMethodHandler.invoke(SynchronousMethodHandler.java:76) at feign.ReflectiveFeign$FeignInvocationHandler.invoke(ReflectiveFeign.java:103) at com.sun.proxy.$Proxy77.getCustomUrlInfo(Unknown Source) at org.wso2.analytics.apim.idp.client.ApimIdPClient.getCustomUrlInfo(ApimIdPClient.java:759) at org.wso2.analytics.apim.idp.client.ApimIdPClient.login(ApimIdPClient.java:303) at org.wso2.carbon.analytics.auth.rest.api.impl.LoginApiServiceImpl.loginAppNamePost(LoginApiServiceImpl.java:147) at org.wso2.carbon.analytics.auth.rest.api.LoginApi.loginAppNamePost(LoginApi.java:82) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.wso2.msf4j.internal.router.HttpMethodInfo.invokeResource(HttpMethodInfo.java:187) at org.wso2.msf4j.internal.router.HttpMethodInfo.invoke(HttpMethodInfo.java:143) at org.wso2.msf4j.internal.MSF4JHttpConnectorListener.dispatchMethod(MSF4JHttpConnectorListener.java:218) at org.wso2.msf4j.internal.MSF4JHttpConnectorListener.lambda$onMessage$57(MSF4JHttpConnectorListener.java:129) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching vtsredaldev02.sr.test.jse.co.za found. at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:646) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:465) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:361) at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:450) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:427) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1515) at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527) at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:334) at feign.Client$Default.convertResponse(Client.java:152) at feign.Client$Default.execute(Client.java:74) at feign.SynchronousMethodHandler.executeAndDecode(SynchronousMethodHandler.java:97) ... 18 more Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching vtsredaldev02.sr.test.jse.co.za found. at java.base/sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:207) at java.base/sun.security.util.HostnameChecker.match(HostnameChecker.java:98) at java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455) at java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:415) at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229) at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129) at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:630)

fazlan-nazeem commented 4 years ago

@premchandragupta have you imported the certificate of the apim node to the analytics client trust store?

ruks commented 4 years ago

@premchandragupta looks like APIM run on different hostname and analytics dashboard runs on different hostname. In such a case, APIM and Analytics hostname should be there in the certification as alternative hostnames. So you need to generate certificates again and try this out.

gmcoder76 commented 4 years ago

Hi @ruks , could you please advise on the steps that need to be followed for setting it up? I am following the same issue while trying to set up analytics with apim - both version 3.1.0

kavisva commented 4 years ago

I am also facing the same issue. I need to run analytics on server ip instead of localhost. I have followed till above mentioned modification of deployment.yml file. Now getting exception with certificate liie below : "Exception occurred :java.security.cert.CertificateException: No subject alternative names matching IP address xxxxx found executing GET https://xxxxxx:yyy/api/am/admin/v0.16/custom-urls/carbon.super " Pls provide insight for the same.

vfbaldovin commented 3 years ago

@kavisva Can you tell me how you have managed the issue. I am facing the same problem, with server ip and I got stucked.

ruks commented 3 years ago

basically, this is a certificate issue. If you are run APIM and Analytics with default in the same host(localhost) this issue will not be an issue. But the hosts are different then you face this issue. I see the following solutions

  1. Run both APIM and analytics with a common certificate. ex: cn=*.portals.example.org. So apim.portals.example.org and analytics.portals.example.org will be the hosts
  2. Setup two certificates for APIM and analytics. Import APIM certificate to dashboard truststore.
  3. If you have a common certificate, but not use a wild card hostname, you can include other server hostnames as SAN ex: cn=analytics.portals.example.org. So apim.portals.example.org and analytics.portals.example.org are the hostnames. So you have to include APIM hostname as SAN.

But I recommend going with option 2.

vfbaldovin commented 3 years ago

I am fully grateful for your help! The fact is that I am running these applications on an internal IP(in order to be accessible in our WAN) and I do not need a DNS.  So my question is, I have to import the existing APIM certificate or I have to create new ones and the import into dashboard truststore?

ganapathy-it commented 3 years ago

basically, this is a certificate issue. If you are run APIM and Analytics with default in the same host(localhost) this issue will not be an issue. But the hosts are different then you face this issue. I see the following solutions

  1. Run both APIM and analytics with a common certificate. ex: cn=*.portals.example.org. So apim.portals.example.org and analytics.portals.example.org will be the hosts
  2. Setup two certificates for APIM and analytics. Import APIM certificate to dashboard truststore.
  3. If you have a common certificate, but not use a wild card hostname, you can include other server hostnames as SAN ex: cn=analytics.portals.example.org. So apim.portals.example.org and analytics.portals.example.org are the hostnames. So you have to include APIM hostname as SAN.

But I recommend going with option 2.

Am running both APIM and analytics on same server. APIM can't able to access publisher portal So I changed the server ip instead of localhost. After configured server ip am able to access publisher portal. The same process I have done in analytics dashboard deployment.yaml file but am getting below exception

Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 10.01.40.34 found

vfbaldovin commented 3 years ago

Ok, so finally I solved this problem. I have to say that i used an IP as host. So the steps are the following(assuming that you have analytics and api manager already installed and also the the configs mentioned above):

  1. Open a command prompt and go to the /repository/resources/security/ directory
  2. Execute:

keytool -genkey -alias newcert -keyalg RSA -keysize 2048 -keystore newkeystore.jks -ext SAN=IP:10.200.xx.xx -storepass wso2carbon -keypass wso2carbon

You can also try with ' -dname "CN=, OU=Home,O=Home,L=SL,S=WS,C=LK" ' instead of ' -ext SAN=IP:10.200.xx.xx ' ( in my case it was suitable with SAN)

So now, you now have a keystore (.jks file) with a private key and a self-signed public key certificate.

  1. Export the public key from your .jks file using the following command:

keytool -export -alias newcert -keystore newkeystore.jks -file newcert.pem

  1. Import the public key you extracted in the previous step to the client-truststore.jks file using the following command:

keytool -import -alias newcert -file newcert.pem -keystore client-truststore.jks -storepass wso2carbon

  1. Go to deployment.yaml file and find wso2cabron.jks and change it with newkeystore.jks

  2. Now, open a command prompt and go to the /resources/security/ directory and do the commands from step 2, 3, 4 (exactly the same)

  3. Go to /resources/security/deployment.toml and change all the wso2carbon.jks occurrences with newkeystore.jks

  4. VERY IMPORTANT! Import the newcert.pem file from /repository/resources/security to the client client-truststore.jks of API Analytics. For me the path was the following:

keytool -import -alias newcert1 -file ../../../wso2am-3.2.0/repository/resources/security/newcert.pem -keystore client-truststore.jks -storepass wso2carbon

Make note that I changed the alias from newcert to newcert1 because you cannot have duplicates in the client-truststore.

The last step helps API Analytics to recognize API Manager as a trusted application.

ganapathy-it commented 3 years ago

Ok, so finally I solved this problem. I have to say that i used an IP as host. So the steps are the following(assuming that you have analytics and api manager already installed and also the the configs mentioned above):

  1. Open a command prompt and go to the /repository/resources/security/ directory
  2. Execute:

keytool -genkey -alias newcert -keyalg RSA -keysize 2048 -keystore newkeystore.jks -ext SAN=IP:10.200.xx.xx -storepass wso2carbon -keypass wso2carbon

You can also try with ' -dname "CN=, OU=Home,O=Home,L=SL,S=WS,C=LK" ' instead of ' -ext SAN=IP:10.200.xx.xx ' ( in my case it was suitable with SAN)

So now, you now have a keystore (.jks file) with a private key and a self-signed public key certificate.

  1. Export the public key from your .jks file using the following command:

keytool -export -alias newcert -keystore newkeystore.jks -file newcert.pem

  1. Import the public key you extracted in the previous step to the client-truststore.jks file using the following command:

keytool -import -alias newcert -file newcert.pem -keystore client-truststore.jks -storepass wso2carbon

  1. Go to deployment.yaml file and find wso2cabron.jks and change it with newkeystore.jks
  2. Now, open a command prompt and go to the /resources/security/ directory and do the commands from step 2, 3, 4 (exactly the same)
  3. Go to /resources/security/deployment.toml and change all the wso2carbon.jks occurrences with newkeystore.jks
  4. VERY IMPORTANT! Import the newcert.pem file from /repository/resources/security to the client client-truststore.jks of API Analytics. For me the path was the following:

keytool -import -alias newcert1 -file ../../../wso2am-3.2.0/repository/resources/security/newcert.pem -keystore client-truststore.jks -storepass wso2carbon

Make note that I changed the alias from newcert to newcert1 because you cannot have duplicates in the client-truststore.

The last step helps API Analytics to recognize API Manager as a trusted application.

I did same thing but am getting exception Caused by: java.security.SignatureException: Signature does not match. at sun.security.x509.X509CertImpl.verify(X509CertImpl.java:424) ~[?:1.8.0_111] at sun.security.provider.certpath.BasicChecker.verifySignature(BasicChecker.java:166) ~[?:1.8.0_111] at sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:147) ~[?:1.8.0_111] at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125) ~[?:1.8.0_111] at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:219) ~[?:1.8.0_111] at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140) ~[?:1.8.0_111] at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79) ~[?:1.8.0_111] at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292) ~[?:1.8.0_111] at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:347) ~[?:1.8.0_111] at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:260) ~[?:1.8.0_111] at sun.security.validator.Validator.validate(Validator.java:260) ~[?:1.8.0_111] at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) ~[?:1.8.0_111] at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229) ~[?:1.8.0_111] at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124) ~[?:1.8.0_111] at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491) ~[?:1.8.0_111]

vfbaldovin commented 3 years ago

Ok, so finally I solved this problem. I have to say that i used an IP as host. So the steps are the following(assuming that you have analytics and api manager already installed and also the the configs mentioned above):

  1. Open a command prompt and go to the /repository/resources/security/ directory
  2. Execute:

keytool -genkey -alias newcert -keyalg RSA -keysize 2048 -keystore newkeystore.jks -ext SAN=IP:10.200.xx.xx -storepass wso2carbon -keypass wso2carbon You can also try with ' -dname "CN=, OU=Home,O=Home,L=SL,S=WS,C=LK" ' instead of ' -ext SAN=IP:10.200.xx.xx ' ( in my case it was suitable with SAN) So now, you now have a keystore (.jks file) with a private key and a self-signed public key certificate.

  1. Export the public key from your .jks file using the following command:

keytool -export -alias newcert -keystore newkeystore.jks -file newcert.pem

  1. Import the public key you extracted in the previous step to the client-truststore.jks file using the following command:

keytool -import -alias newcert -file newcert.pem -keystore client-truststore.jks -storepass wso2carbon

  1. Go to deployment.yaml file and find wso2cabron.jks and change it with newkeystore.jks
  2. Now, open a command prompt and go to the /resources/security/ directory and do the commands from step 2, 3, 4 (exactly the same)
  3. Go to /resources/security/deployment.toml and change all the wso2carbon.jks occurrences with newkeystore.jks
  4. VERY IMPORTANT! Import the newcert.pem file from /repository/resources/security to the client client-truststore.jks of API Analytics. For me the path was the following:

keytool -import -alias newcert1 -file ../../../wso2am-3.2.0/repository/resources/security/newcert.pem -keystore client-truststore.jks -storepass wso2carbon Make note that I changed the alias from newcert to newcert1 because you cannot have duplicates in the client-truststore. The last step helps API Analytics to recognize API Manager as a trusted application.

I did same thing but am getting exception Caused by: java.security.SignatureException: Signature does not match. at sun.security.x509.X509CertImpl.verify(X509CertImpl.java:424) ~[?:1.8.0_111] at sun.security.provider.certpath.BasicChecker.verifySignature(BasicChecker.java:166) ~[?:1.8.0_111] at sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:147) ~[?:1.8.0_111] at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125) ~[?:1.8.0_111] at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:219) ~[?:1.8.0_111] at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140) ~[?:1.8.0_111] at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79) ~[?:1.8.0_111] at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292) ~[?:1.8.0_111] at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:347) ~[?:1.8.0_111] at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:260) ~[?:1.8.0_111] at sun.security.validator.Validator.validate(Validator.java:260) ~[?:1.8.0_111] at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) ~[?:1.8.0_111] at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229) ~[?:1.8.0_111] at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124) ~[?:1.8.0_111] at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491) ~[?:1.8.0_111]

I forgot to mention... Repeat the last step, but import the certificate from Analytics to the client trustore of WSOAM and you are done.

ganapathy-it commented 3 years ago

I forgot to mention... Repeat the last step, but import the certificate from Analytics to the client trustore of WSOAM and you are done. În lun., 7 dec. 2020 la 16:12, ganapathy-it notifications@github.com a scris:

After import the certificate from Analytics to the client trustore of WSOAM am getting exception Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 10.9.47.76 found at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) at sun.security.ssl.Handshaker.process_record(Handshaker.java:914) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)

vfbaldovin commented 3 years ago

I forgot to mention... Repeat the last step, but import the certificate from Analytics to the client trustore of WSOAM and you are done. În lun., 7 dec. 2020 la 16:12, ganapathy-it notifications@github.com a scris:

After import the certificate from Analytics to the client trustore of WSOAM am getting exception Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 10.9.47.76 found at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) at sun.security.ssl.Handshaker.process_record(Handshaker.java:914) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)

In my case, the problem has been solved by generating the certs, importing in theirs trust-stores and also reversly.

milad-aminzade commented 3 years ago

Ok, so finally I solved this problem. I have to say that i used an IP as host. So the steps are the following(assuming that you have analytics and api manager already installed and also the the configs mentioned above):

  1. Open a command prompt and go to the /repository/resources/security/ directory
  2. Execute:

keytool -genkey -alias newcert -keyalg RSA -keysize 2048 -keystore newkeystore.jks -ext SAN=IP:10.200.xx.xx -storepass wso2carbon -keypass wso2carbon

You can also try with ' -dname "CN=, OU=Home,O=Home,L=SL,S=WS,C=LK" ' instead of ' -ext SAN=IP:10.200.xx.xx ' ( in my case it was suitable with SAN)

So now, you now have a keystore (.jks file) with a private key and a self-signed public key certificate.

  1. Export the public key from your .jks file using the following command:

keytool -export -alias newcert -keystore newkeystore.jks -file newcert.pem

  1. Import the public key you extracted in the previous step to the client-truststore.jks file using the following command:

keytool -import -alias newcert -file newcert.pem -keystore client-truststore.jks -storepass wso2carbon

  1. Go to deployment.yaml file and find wso2cabron.jks and change it with newkeystore.jks
  2. Now, open a command prompt and go to the /resources/security/ directory and do the commands from step 2, 3, 4 (exactly the same)
  3. Go to /resources/security/deployment.toml and change all the wso2carbon.jks occurrences with newkeystore.jks
  4. VERY IMPORTANT! Import the newcert.pem file from /repository/resources/security to the client client-truststore.jks of API Analytics. For me the path was the following:

keytool -import -alias newcert1 -file ../../../wso2am-3.2.0/repository/resources/security/newcert.pem -keystore client-truststore.jks -storepass wso2carbon

Make note that I changed the alias from newcert to newcert1 because you cannot have duplicates in the client-truststore.

The last step helps API Analytics to recognize API Manager as a trusted application.

I'm implied by this problem for one week and finally by this solution rescued. thank you very much

wikavisperd commented 3 years ago

basically, this is a certificate issue. If you are run APIM and Analytics with default in the same host(localhost) this issue will not be an issue. But the hosts are different then you face this issue. I see the following solutions

  1. Run both APIM and analytics with a common certificate. ex: cn=*.portals.example.org. So apim.portals.example.org and analytics.portals.example.org will be the hosts
  2. Setup two certificates for APIM and analytics. Import APIM certificate to dashboard truststore.
  3. If you have a common certificate, but not use a wild card hostname, you can include other server hostnames as SAN ex: cn=analytics.portals.example.org. So apim.portals.example.org and analytics.portals.example.org are the hostnames. So you have to include APIM hostname as SAN.

But I recommend going with option 2.

Am running both APIM and analytics on same server. APIM can't able to access publisher portal So I changed the server ip instead of localhost. After configured server ip am able to access publisher portal. The same process I have done in analytics dashboard deployment.yaml file but am getting below exception

Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 10.01.40.34 found https://stackoverflow.com/questions/68343827/wso2-api-manager-analytics-certificateexception-no-subject-alternative-names/68344803#68344803

wikavisperd commented 3 years ago

please check tfollowing address to solve your problem. https://stackoverflow.com/questions/68343827/wso2-api-manager-analytics-certificateexception-no-subject-alternative-names/68344803#68344803

ruks commented 2 years ago

Close the issue since a solution is provided.