I would like to hear from the forum what are your best practices for switching from one SSL cert to another. A bit of background:
Fleet size: 100’s of gateways
Dependency: SAML ACS URL contains SSL specific address info (HTTPS/PORT 8043) - if SSL is removed, SSO login will not work
Switching 100’s of gateways to manual login and then back to SSO is not even something we want to consider 1) because of the work required and 2) how it would negatively affect the service users.
We are required to update the SSL certification once per year and must provide a CSR that is new (i.e. does not match what the current SSL cert uses). This presents a problem because Ignition will only allow us to generate a new CSR after the SSL cert has been removed, which is for us, unacceptable.
I’m keen to hear how everyone deals with this situation.
Does your CA support the ACME protocol? If so, you can automate SSL certificate renewal. This is how "Let's Encrypt" works. We have an integration guide here: Let's Encrypt Guide for Ignition | Inductive Automation. This is your best option.
If not, then you will have to find your own way of automating this process or do it manually, which will not be fun for 100+ gateways though if it's once per year, it might be an option. If you look at the above referenced Let's Encrypt guide, you will find that you can hot-reload the keystore which contains the SSL certificate and key used for the Gateway web server's SSL communications. This hot-reload functionality applies the new certs / keys with zero downtime to the Gateway. So if you can automate the process of generating your own CSR, calling an API from your CA to exchange the CSR for a cert bundle, and creating the keystore in the appropriate format in the correct file location using a script of some sort, maybe with a cron job for scheduling, that'd be a good option. You can apply the same process for each Gateway.
This presents a problem because Ignition will only allow us to generate a new CSR after the SSL cert has been removed, which is for us, unacceptable.
That's not true - you can generate a CSR which will be bootstrapped with the details from your currently installed SSL certificate any time by going to Gateway Web Interface > Config > Networking > Web Server (see below screen shot). You can also upload your new cert bundle to rotate to the new cert with zero downtime. This does not require deleting the current certificate and disabling SSL temporarily.
must provide a CSR that is new (i.e. does not match what the current SSL cert uses)
Could you be more specific about what your CA's requirement is for a CSR that does not match the previous one? Clicking that Generate CSR button always generates a brand new CSR file on the fly for each button click. Does it not like that you are using the same key pair every time?
@jspecht at first we tried to use the "Generate CSR" button and submitted a SSL cert renewal request.
However, the response to that initial request was as follows:
we can not renew the certificate with the same CSR. We require a new csr
If network security is telling us up front that they require a new CSR, there is nothing we can do but comply with the request. It is because of this that we are now wondering how to handle SSL cert renewal every year.
At the site related to that request, we are dealing with this by downgrading to non-SSL temporarily, making the project public so no login username/password is needed, and telling the site how to change their client launcher address in case they have it has https/8043. If they use http/8088 it will redirect to https/8043 but it wont redirect going the other direction.
Your security team is mandating new key pairs, effectively. As there is nothing else that is practical to change in the CSR. They are being unrealistic, and you should be pestering them, not IA.
Found this thread for similar issues, but I think I have something "practical"
I need to change the SANs in the CSR prior to renewing as our DNS addresses for the ignition gateway are changing. I do not want to fully disable SSL and then generate a new CSR and then wait for our security guys to issue new certs. Like @nicholas.robinson said due to IdP configs, Ignition would be down until we can re-install the new certs.
Is the only option manual management? Can I modify the CSR with keytool like in 7.9?
Why don’t you generate a new CSR that contains both the old and new SANs in it and then when the DNS switchover happens generate another that has only the new SANs?
Thats exactly what I want to do. But the gateway won’t let me edit the SANs, only download the current CSR. The only way I can edit is to remove the cert and start over, or am I missing something?
Oh, didn’t realize the generate CSR flow was different for a new vs existing certificate… my bad
In that case, yes, you’ll probably have do it manually with keytool or KeyStore Explorer or whatever your choice of tooling is. It’s still just a keystore file underneath it all.
@ryanjmclaughlin I’m not sure it helps or not, but what we have come up with is as follows:
Use open SSL to generate a new CSR, and importantly, a “.KEY” file
Apply for SSL cert renewal with the new CSR (required by our organization)
In the gateway SSL section, reset the the step on SSL CSR
import the “.KEY” file generated earlier
Download the new PKCS7 SSL cert and then your done
Our DNS names are always the same, but if you did need to change it you would do it when you generate the CSR in open SSL. You just have to make sure that when you get the cert and try to install it that the gateway URL name has already been updated so that cert name and install location do match.
We have a written procedure for how we do it that I can share with you, if you need that just send me a DM.
