How can i check that they have been imported into the key store ok?. LDAP works fine, LDAPS not. no user list or login working.
Can anyone tell me how to check they have imported ok?
As both @Kevin.Herron and @ryanjmclaughlin have mentioned, just by dropping the certificate into the data\certificates\supplemental folder, and restarting the Gateway did the trick for me.
If that didnāt work for you, maybe you can check the following settings:
- Primary Domain Controller Port: I have successfully used both 636 and 3269.
- Use SSL: Checked.
- Security Protocol: SSL (although Auto worked on a recent 8.0.14 installation).
And to check if the certificate was imported correctly, I ran the following command under the lib\runtime\jre-win\bin folder:
This will list all certificates:
keytool -list -v -keystore ..\lib\security\cacerts
But to filter the list, you can use the alias which in my case was the file name and extension
keytool -list -v -keystore ..\lib\security\cacerts -alias file_name.extension
Just substitue file_name.extension with the name of your certificate file.
But this begs the following question.
What happens when the certificate expires and it is replaced? Does dropping the new certificate into the suplemental folder and restarting the Gateway will handle it automatically or does one have to delete the certificate from cacerts manually?
1 Like
Just adding a little note to this threadāeverything mentioned above is accurate and works to enable LDAPS functionality. On a fresh install of 8.0.14, going through the SSL/TLS guided config for the Webserver properly placed the CA cert in data/certificates/supplemental and the gateway webserver began functioning properly in HTTPS mode; however, getting the LDAPS user source to function required a gateway restart (manual reloading of the gateway keystore via gwcmd -g was not enough either).
1 Like
Hi
Thank you for the help. I now have LDAP login working with SSL.
However I cannot get the user list working for the specific OU. It works with SSL off but not when enabled.
When I test my login itās getting all the correct info back and the roles that had previously been assigned in ignition. But the user list isnāt coming up so I canāt add roles to new users.
Any ideas?
Hi Herbie,
Thank you for your post - it helped me out a log in getting my AD LDAP authentication working.
It was not smooth sailing even with the tips in your post a summary of my journey:
I found using KeyStore Explorer much easier to use than keytool. I put the CA root certificate into the JRE cacerts file as you suggested.
I was still not able to get the connection to the AD domain controller working even after putting the CA certificate into the cacerts file and restarting Ignition. I could see Ignition trying to connect to the domain controller in WireShark (monitored port 636) and kept seeing that the returned certificate was being rejected. There was no apparent reason.
Eventually I came across a few posts that describe how to get debug information out of the JRE. By adding a line line to the ignition.config file I was able to see that the correct certificate was being returned and that it was being rejected - more on that below. The line added was wrapper.java.additional.2=-Djavax.net.debug=āssl,handshake,trustmanagerā. After restarting Ignition, log information on the connection shows up in the wrapper log in the logs directory. The error message, āNo subject allternate DNS name matching scada.domain.com found.ā The name subject name on the returned certificate was mic-dc-01.scada.comain.com. To me it looks like this is a bug in Ignition. I hypothesize that Ignition expects a 3 part domain name as was ignoring the first part of my 4 part domain name.
In the end, I ended up specifying the domain controller host IP address in the configuration and added a SAN (subject alternate name) in the certificate. Everything works great now.
2 Likes
I have used KeyStore Explorer too, but I hadnāt figured out a way to generate the request to get a certificate from the AD Domain Controller properly. If you have tips on that, Iād appreciate that.
The biggest reason for adding the RootCA and the one generated for your specific instance is Java knows how to trust the certificates that will be coming from your domain controller. When Java receives it, it has to know how to validate it, and the RootCA and the intermediate certificates is how it does this. Getting yours generated appropriately is also important, as that is how the domain controller validates you.
One thing that has changed in the certificate generation process is the use of Subject Alternative Names. Itās important in the certificate request process that you include all names and aliases your gateway will be functioning as, otherwise browsers will show you the ābad certificateā message and require your users to accept to bypass the warning. Not ideal. For us, this was adding all DNS names, as well as IP addresses we could be communicating on. This ensure that no matter which way to connect, you are presented with a properly secure website. Remember, however, this is just so users connecting to your gateway are presented properly and has nothing to do with the LDAP connection. But doing that on the RootCA is equally important for the same reasons.
Part of the reason you were having issues is because you want to use a wildcard DNS name. By adding scada.domain.com and not *.scada.domain.com, you are saying it must match exactly. This is not a bug, but a part of the secure communications protocol in use by many systems (by the way, Java is the one enforcing this, not Ignition). Generating wildcard certificates isnāt as easy, but is much easier to deploy to multiple machines if you want to go that route.
Glad you got everything working though!
Hello all,
I have managed to get LDAPS communication working fine by setting up the following:
- Using a GPO (or whatever automated process) I am getting our root and intermediate domain controller certificates (in .cer format ) from a central infrastructure share and copying them into the supplemental folder.
This ensures that they are loaded by 8.x gateways and the domain itself is trusted.
I use Keystore Explorer to check in the embedded java CACERTS store and I see the domain certificates correctly imported.
I am also adding a System environment variable : āJAVA_TOOL_OPTIONS=-Djavax.net.ssl.trustStoreType=WINDOWS-ROOTā and with all the above done it works seamlessly. Not sure if all the above is required but it works this way 
So the LDAPS part is good.
Now iām looking at the SSL part - i have got it working for one gateway but am looking for a more global approach to manage multiple servers. If anything comes from that topic iāll post a link to it here for future hunters to follow the breadcrumbs
Thanks all for your help.
If youāre having issues getting LDAPS working, reply here and someone will help !!
2 Likes
This shouldn't have been necessary, and if it does what it says and is actually working then the "supplemental certs" mechanism Ignition has won't work any more because you won't even be using the Java keystore any more. If you can remove this and still get connected to AD I'd recommend that. Seems like less chance for confusion in the future.
i agree iāll loop back to this and unconfuse myself when writing up my internal procedures
I am also having issues getting our AD/Internal Hybrid to connect to our Domain Controllers port 636
I have imported the .DER certificates into the supplemental folder and they are in the keystore. I am using 8.1.15 on Server 2019 and another Instance Windows 10 21H2. I have tried HostName and IP.
I have verified the cert with the nettools app also.
Hi all,
There are some recent changes in Java that can also simplify certificate usage without needing to copy & import individual certs (CA, intermediate or other endpoint) into the supplemental folder.
Since 8.1.26, and the usage of OpenJRE 11.0.18, the JVM can read WINDOWS keystores beyond the original WINDOWS-MY & WINDOWS-ROOT. There was a bug in Java - fixed 15 years after it was reported - [JDK-6782021] It is not possible to read local computer certificates with the SunMSCAPI provider - Java Bug System (openjdk.org)
This exposes 2 more keystore locations: see the links above for details
- Windows-ROOT-LOCALMACHINE
- Windows-MY-LOCALMACHINE
By setting a Windows System Environment variable like this :
the gateway does NOT trust a server on our internal network, even though this server has a valid TLS certificate.
By changing the above to =WINDOWS-ROOT-LOCALMACHINE (and making sure the gateway service is started with admin rights) Ignition trusts 'natively' and without further file manipulation all TLS-enabled servers in our company ! 
As I have around 120 gateways, anything that I can automate is a win for us.
I'll try some more test scenarios around this, to see if i can get it to use ONLY the native stores and not have to mess with any file-based keystores.
3 Likes
In case it may help others, after we managed to get LDAPS working by putting the CA certificate in the C:\Program Files\Inductive Automation\Ignition\data\certificates\supplemental folder, we also ran into the issue where Users and Roles were showing up empty within our Active Directory user source. It turned out, it was because i had our 'Gateway Username' field as domain\username and it didn't like this. I changed it to just username and it worked! I started seeing the Users and Roles thereafter. Hope this helps!
1 Like