# Automated SSL Certificate Renewal and Installation

**URL:** <https://forum.inductiveautomation.com/t/automated-ssl-certificate-renewal-and-installation/49039>\
**Category:** Ignition\
**Created:** [July 21, 2021, 1:52pm UTC](https://forum.inductiveautomation.com/t/automated-ssl-certificate-renewal-and-installation/49039 "2021-07-21T13:52:53Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![jspecht](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jspecht/32/6465_2.png) [@jspecht](https://forum.inductiveautomation.com/u/jspecht)\
**Post date:** [January 24, 2023, 11:45pm UTC](https://forum.inductiveautomation.com/t/automated-ssl-certificate-renewal-and-installation/49039/7 "2023-01-24T23:45:16Z")

</div>

> [@nicholas.robinson](#):
>
> So essentially, if we can get back an SSL cert that has the full root chain and the private key, we can package those up as a PKCS12 and replace the ssl.pfx file in webserver.

Correct.

> [@nicholas.robinson](#):
>
> A question: if I wanted to automate a check afterwards to see if the new SSL cert is functioning, if I do this call to the SSL port and can get a response would that prove it or would there be a better way?

If your curl instance is configured to trust the root CA cert used in the cert chain you installed in the Gateway, and the `{address}` exists on the Gateway server cert's subject common name or subject alternative names, then that should work. You should get an HTTP 200 OK response which means the TLS handshake through which the HTTP connection is tunneled was successfully established.

---

_[View the full topic](https://forum.inductiveautomation.com/t/automated-ssl-certificate-renewal-and-installation/49039)._
