# SSL verification error/rest calls in scripting, perspective **URL:** \ **Category:** Ignition\ **Tags:** ignition81, python, ignition80, scripting, perspective\ **Created:** [March 21, 2023, 6:55am UTC](https://forum.inductiveautomation.com/t/ssl-verification-error-rest-calls-in-scripting-perspective/71355 "2023-03-21T06:55:13Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Sabhareeswaran\_Ravi](https://avatars.discourse-cdn.com/v4/letter/s/f6c823/32.png) [@Sabhareeswaran\_Ravi](https://forum.inductiveautomation.com/u/Sabhareeswaran_Ravi)\ **Post date:** [March 21, 2023, 6:55am UTC](https://forum.inductiveautomation.com/t/ssl-verification-error-rest-calls-in-scripting-perspective/71355/1 "2023-03-21T06:55:13Z")
I tried to fetch data using restApi(using GET call), the thing is we have added a wildcard certificate to our platform which provides this API to access. I believe due to this, I am not able to retrieve any data Ignition throws an error as follows, ``` Error running action 'dom.onClick' on test@C/root/XYChart: Traceback (most recent call last): File "", line 11, in runAction File "", line 11, in runAction at com.inductiveautomation.ignition.common.script.builtin.http.JythonHttpClient.send(JythonHttpClient.java:103) at com.inductiveautomation.ignition.common.script.builtin.http.JythonHttpClient.get(JythonHttpClient.java:306) at jdk.internal.reflect.GeneratedMethodAccessor144.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) java.io.IOException: java.io.IOException: ``` Are there any arguments like verify = False to skip the SSL verification or any other workarounds to add the certificate to Ignition's trusted certificate store? Help would be appreciated 🙂 ---
**Author:** ![mpoulsen921](https://avatars.discourse-cdn.com/v4/letter/m/b4bc9f/32.png) [@mpoulsen921](https://forum.inductiveautomation.com/u/mpoulsen921)\ **Post date:** [March 21, 2023, 7:00am UTC](https://forum.inductiveautomation.com/t/ssl-verification-error-rest-calls-in-scripting-perspective/71355/2 "2023-03-21T07:00:50Z")
Hi Sab Try have a look at the function [system.net.httpGet - Ignition User Manual 8.1 - Ignition Documentation](https://docs.inductiveautomation.com/display/DOC81/system.net.httpGet). It has a boolean flag to bypass certification validation. ---
**Author:** ![Sabhareeswaran\_Ravi](https://avatars.discourse-cdn.com/v4/letter/s/f6c823/32.png) [@Sabhareeswaran\_Ravi](https://forum.inductiveautomation.com/u/Sabhareeswaran_Ravi)\ **Post date:** [March 22, 2023, 11:23am UTC](https://forum.inductiveautomation.com/t/ssl-verification-error-rest-calls-in-scripting-perspective/71355/3 "2023-03-22T11:23:17Z")
Hi Mpoulsen92, thank you so much for your reply. 🙂 Indeed it helped me a lot... By any chance can we customize the logs which are triggered by the default mechanism? because If I bypass SSL it triggers the log each time. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/3/03482569f02fd3080a7b5d120f5ed11b66c9b8e3.png) ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [March 22, 2023, 3:15pm UTC](https://forum.inductiveautomation.com/t/ssl-verification-error-rest-calls-in-scripting-perspective/71355/4 "2023-03-22T15:15:06Z")
No, because it's just a logger, and it's not wrong. If you have a custom certificate to trust, the _right_ way to go about things is to add it to your local environment trust store (the gateway/designer/vision client). Bypassing _all_ SSL verification is a completely different, _much_ wider security opening than simply accepting one specific certificate. [https://docs.inductiveautomation.com/display/DOC81/Security+Certificates#SecurityCertificates-AddingSecurityCertificatesintoKeyStores](https://docs.inductiveautomation.com/display/DOC81/Security+Certificates#SecurityCertificates-AddingSecurityCertificatesintoKeyStores) Also note: system.net.httpGet is 'soft' deprecated and likely to be fully deprecated in 8.3. `system.net.httpClient()` is superior in basically every way, and has a corresponding bypass\_cert\_validation flag that will do the same disabling of all SSL verification (with the same warning in the logs). ---
**Author:** ![Sabhareeswaran\_Ravi](https://avatars.discourse-cdn.com/v4/letter/s/f6c823/32.png) [@Sabhareeswaran\_Ravi](https://forum.inductiveautomation.com/u/Sabhareeswaran_Ravi)\ **Post date:** [March 23, 2023, 11:09am UTC](https://forum.inductiveautomation.com/t/ssl-verification-error-rest-calls-in-scripting-perspective/71355/5 "2023-03-23T11:09:43Z")
Thank you so much for the docs links. @paul-griffith I am new to Ignition development, are there any official pages we can track/be aware of any changes like deprecation of APIs? ---
**Author:** ![Jonathan\_Hall](https://avatars.discourse-cdn.com/v4/letter/j/7bcc69/32.png) [@Jonathan\_Hall](https://forum.inductiveautomation.com/u/Jonathan_Hall)\ **Post date:** [February 27, 2025, 1:22pm UTC](https://forum.inductiveautomation.com/t/ssl-verification-error-rest-calls-in-scripting-perspective/71355/6 "2025-02-27T13:22:18Z")
why deprecated the httpget ? its lightweight compared to httpclient. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/8/3894f0e5f0270b325b5021f30ae08cbe0e715ade.png) we use it a lot in tag script and im a bit concerned about the performance hit that this change would have on our server ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 27, 2025, 1:28pm UTC](https://forum.inductiveautomation.com/t/ssl-verification-error-rest-calls-in-scripting-perspective/71355/7 "2025-02-27T13:28:27Z")
The hit is mitigated by following the advice in that caution. Do not call `system.net.httpClient()` for every request. Create a long-lived instance, and only use the `.get()` or `.post()` (or whatever) method per request. Then the performance should be **better** than `httpGet`. (If you are doing any of this in tag event scripts, you are seriously screwing up, and risk locking up all of your tag event scripting. Use gateway tag change events in a project for anything that reaches out across a network.)