In case it helps anybody, I upgraded to forest_liana 7.22 and followed these instructions from @Yoad_Snapir, updating my FOREST_CLIENT_ID with the returned value, before it would work for me:
🚨 Forest down (SSL issue) - Trouble logging in 🚨 - #12 by Yoad_Snapir.
The same thing as @Maicol_Bentancor, we are not using static client id and did restart, still not working, any other suggestions?
@Maicol_Bentancor @nmelentjevs
If you did not use a static client id before, we recommend not to use one, because it is more complicated to set-up and more prone to errors.
If you are using rails, you have to:
- upgrade to the latest version of the major that you are using (6.6.3 or 7.2.2)
- make sure to clear the cache of your application
If you are using node, you just need to restart it and it should generate a valid client id on the first authentication call.
2 Likes
Hello again,
We’re using node and none of the fixes above did work for us 
The curl request works, we tried to set the FOREST_CLIENT_ID with the value returned from it, we restarted the server multiple times but we still can’t login.
We’re using Node, and no we didn’t use a FOREST_CLIENT_ID before
It did fix forest for our local environment, however, the staging Heroku app still has the same error even after upgrading to 7.2.2 and restarting
Hi @GuillaumeGautreau
Please consider that, as per your documentation, there are situations (banckend load balancing) where we can’t do anything else than using a static FOREST_CLIENT_ID:
So this suggestion
If you did not use a static client id before, we recommend not to use one, because it is more complicated to set-up and more prone to errors.
is not applicable to all situations and it’s misleading.
As far as I can tell, not using static client id in not the solution to prevent similar problems.
But if I’m wrong, please tell me. Because I’m willing to know if I can improve resiliency on my side.
Thank you!
Regards,
Matteo
Hello @nmelentjevs can you please open a separate thread for your problem? This way it’ll be easier to regroup all the info you can give about your issue.
Hello @kmcb can you please open a separate thread in order to share the specific info about your setup and your problem? It’ll be easier for us to follow and help you directly.
Hello @Matteo,
Indeed there are situations where using a static FOREST_CLIENT_ID is required in order for the authentication to work properly.
If, before the incident, you were using successfully the agent in the same major version, there are no reason for you to use this static FOREST_CLIENT_ID.
If you are deploying multiple instances of the agent behind a load balancer, then all these instances need to share the same FOREST_CLIENT_ID, that’s why you need to use a static one.
We recommend not to use it if you are not in this situation, because it implies manual operations to generate it, which are more error prone.
For those having the same client ID issue, my solution was to update the client ID with the value returned from
curl -H “Content-Type: application/json”
-H “Authorization: Bearer FOREST_ENV_SECRET”
-X POST
-d ‘{“token_endpoint_auth_method”: “none”, “redirect_uris”: [“APPLICATION_URL/forest/authentication/callback”]}’
https://api.forestadmin.com/oidc/reg
It looks like the previous one expired with the SSL bug
1 Like
Thank you @GuillaumeGautreau
Yes, yes. We’re using a load balancer, that’s the reason because we did what your documentation sais at the previously provided link. 
Now I understand from your answer that in these condition we have no way on our side to improve our resilience more than this.
So my suggestion is that you should implement some kind of handshake at boot time from my forest-express to you central forest backend in order to manage the auth of my endpoints on your side. If the client JWT needs to be updated (even if only in extreme situations) you should make the process automatic (i.e. including the signed secret that must be shared between the load balanced hosts as a variable in the JWT itself - or something like that…), in order not to rely upon a manual intervention to generate a new client id on my side. For example, you may implement the client id generation in my backend forest libs at boot time, starting from the information my backend already knows (the involved secrets/variables are FOREST_ENV_SECRET and my public hostname).
Requiring a manual intervention on my side is not acceptable at all in common situations. But in extreme and uncommon situations, asking me just to reboot is better than asking me to have a complex manual procedure.
To complete the manual procedure I was supposed to have available the required information and I spent time to gather all the required parameters. And I had no first level procedures to do this with my operation support team. Because this was a completely unexpected situation. But a generic reboot procedure, only in extreme situations (I mean once in ten years…
), would be simpler, thus feasible and acceptable on our side, reducing the seniority level required for the intervention on our side.
If you just asked me to reboot, my recover time would have been much smaller.
Hope I better clarified my point this time and I hope you will find useful these suggestions.
Thank you.
Matteo
1 Like
Thanks for your feedback @Matteo,
We are thinking about a way to reduce the pain introduced with these FOREST_CLIENT_ID and APPLICATION_URL configuration variables that are sources of errors when deploying Forest Admin. I guess that your answer is showing that this need is also present when maintaining a working installation.
1 Like
I guess that your answer is showing that this need is also present when maintaining a working installation.
In my perspective, the more resilient (even to external problem sources) the better 
Matteo
I have already upgraded the gem to 6.6.3 and also moved to usage of FOREST_CLIENT_ID. Still we are facing the issue where API is returning 403 with message “IP whitelist not retrieved”.
Please someone help.
Also getting this issue when trying to run console on our ENV. “Forest 
Cannot send the apimap to Forest. Forest might currently be in maintenance.”
Still having the same issue as @Prateek_mittal.
We upgraded to 6.6.3.
We regenerated the client id.
Added the new client id to our env vars
Checked that the new client id has been well added
We still get the error : {“errors”:[{“status”:500,“detail”:“SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate has expired)”}]}
When running the console : Forest Cannot send the apimap to Forest. Forest might currently be in maintenance.
Please help 
Hello @Imad_Wakidi and @Prateek_mittal.
Could you please run a curl https://api.forestadmin.com on the server on which you are experiencing the issue?
Lower versions than 6.6.3 rely on a library that does not support the new root certificate of Let’s encrypt. In order to bypass this, we included a monkey-patch of the underlying library, in order to make it use the system certificates.
But some OSs that have not been updated do not embed this new certificate either. The curl command to run the same environment than your liana will allow to detect if the problem comes from your OS.
Ok, then it means that the problem does not come from your OS, but likely from the rails lib again.
Just to be sure, can you run gem query --local on your server, in the directory where you deployed your rails app ?