Where is this certificate located? Is it possible to recreate? Using on Linux.
I think it’s in $IGNITION/webserver/metro-keystore.
Is there a way to delete the certificate from the gateway interface so that a new one is generated?
No, there is not currently a way to re-generate this from the web UI.
If I delete the file metro-keystore, will that cause all of the rest of my GAN connections to be reset as well (and need to be reconfigured)? We have one connection that's been Faulted and giving us Certificate errors in the log and I would like to fix it without having to map the rest of the connections, if possible.
TL;DR: Possibly, yes.
The metro-keystore contains the certificate and associated private key that is used for outgoing connections to other gateways. So if you regenerate, you'll need to re-approve the new certificate on any remote gateways to which you've made an outgoing connection. Incoming connections might not be affected (though see below for caveats to this).
If you're using Require Two Way Auth, which is recommended, you will also need to re-trust the new gateway certificate on any remote gateways (where they're making outgoing connections to the gateway you regenerated the metro-keystore on). Otherwise, you'll likely end up with either of these two errors below:
# This will occur if you had previously trusted the remote cert that is no longer valid
Error message=sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
# You might get this if you've not got any remote certs trusted for your outgoing connection (and two way auth enabled)
Error message=java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
I deleted the files on both gateways and restarted the gateway service, and then tried to create an outgoing connection from gateway A to gateway B. I got the same error I was getting before I restarted the gateway:
# You might get this if you've not got any remote certs trusted for your outgoing connection (and two way auth enabled)
Error message=java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
I tried going the other way, creating an outgoing connection from gateway B to gateway A, and I got the approval immediately, so now it appears to be working properly. Is there a reason why the gateway network connection dropped? Inactivity? Gateway name change? The certificate should be valid for 10 years, from what I read in the docs.
Yep, that was enabled! I disabled that and I'll keep an eye on this for a while. This is for a customer's setup so I'd like this to just work (as most things do in Ignition).
Thanks @kcollins!
Glad you got it sorted. If it is on a Linux machine, you can add trust for the opposite side of an outgoing connection (to facilitate use of Require Two-Way Auth setting) with the following use of openssl s_client (substituting remote-hostname accordingly):
echo -n | \
openssl s_client -connect remote-gateway:8060 | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > \
/usr/local/bin/ignition/data/gateway-network/client/security/pki/trusted/certs/remote-gateway.crt
Once in-place, the gateway will recognize it immediately, no restart required.
1 Like
For Ignition v8.3.4 the location is
$IGNITION/data/config/local/ignition/gateway-network/keystore/metro-keystore.pfx
/usr/local/bin/ignition/data/config/local/ignition/gateway-network/keystore/metro-keystore.pfx on Linux
Deleting the file does cause a new one to be created on gateway restart.
In my case I had cloned a preconfigured VM several times to setup a gateway network for testing purposes and since ignition was pre-installed on the original VM all the clones had the exact same local cert and that prevented me from setting up redundancy etc.
FYI, if you renamed your host server after installing Ignition, deleting the local cert and generating a new one will allow the common name of the cert to match the new name of your server.
1 Like