# Designer startup : Verifying Signature of Designer

**URL:** <https://forum.inductiveautomation.com/t/designer-startup-verifying-signature-of-designer/82670>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [December 4, 2023, 4:27pm UTC](https://forum.inductiveautomation.com/t/designer-startup-verifying-signature-of-designer/82670 "2023-12-04T16:27:35Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![jcoffman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jcoffman/32/6429_2.png) [@jcoffman](https://forum.inductiveautomation.com/u/jcoffman)\
**Post date:** [December 4, 2023, 6:53pm UTC](https://forum.inductiveautomation.com/t/designer-startup-verifying-signature-of-designer/82670/9 "2023-12-04T18:53:12Z")

</div>

I understand the slight delay can be frustrating, but this provides a robust industry-standard way to verify the authenticity of jars downloaded over the internet. the soft-fail mechanism is the default we use specifically because most launch cases are on networks without internet access. The "strict" mode would actually require a connection to one of the revocation endpoints ([ocsp.digicert.com](http://ocsp.digicert.com) or [cacerts.digicert.com](http://cacerts.digicert.com)) which is why its not the default (but can be turned on in the launchers' config JSON)

You could get with IT to allow comms to the OCSP server if its a blocker, but typically this type of thing wouldn't be a "blocker" but an annoyance and the trade-off for security here is a much higher need than the delay in launching, especially considering its a fixable problem with modern IT solutions.

---

_[View the full topic](https://forum.inductiveautomation.com/t/designer-startup-verifying-signature-of-designer/82670)._