I hypothesize that Ignition expects a 3 part domain name as was ignoring the first part of my 4 part domain name. To me it looks like this is a bug in Ignition. The error message, “No subject allternate DNS name matching found.” The name subject name on the returned certificate was. After restarting Ignition, log information on the connection shows up in the wrapper log in the logs directory. The line added was .2=“ssl,handshake,trustmanager”. By adding a line line to the nfig file I was able to see that the correct certificate was being returned and that it was being rejected - more on that below. There was no apparent reason.Įventually I came across a few posts that describe how to get debug information out of the JRE. 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. 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 put the CA root certificate into the JRE cacerts file as you suggested. I found using KeyStore Explorer much easier to use than keytool. It was not smooth sailing even with the tips in your post a summary of my journey: Thank you for your post - it helped me out a log in getting my AD LDAP authentication working. 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? Just substitue file_name.extension with the name of your certificate file. \lib\security\cacerts -alias file_name.extension \lib\security\cacertsīut to filter the list, you can use the alias which in my case was the file name and extension Security Protocol: SSL (although Auto worked on a recent 8.0.14 installation).Īnd to check if the certificate was imported correctly, I ran the following command under the lib\runtime\jre-win\bin folder:.Primary Domain Controller Port: I have successfully used both 6.If that didn’t work for you, maybe you can check the following settings: Keytool.exe -importcert -noprompt -trustcacerts -alias domain -file -keystore -storepass Īs both and have mentioned, just by dropping the certificate into the data\certificates\supplemental folder, and restarting the Gateway did the trick for me. In my batch script, I detect 32/64 bit as well as Java version, but the tool will be in the \bin\keytool.exe of the Java path on the system, something like C:\Program Files\Java\jre1.8.0_181 and the Java Keystore is stored in \lib\security\ as the cacerts file. For Ignition 7.9, you will require the use of the Java keytool to install it. You will need to get this certificate to the Gateway machine. ( NOTE: I’ve used Base 64 without a problem) Then select the most current CA certificate.Select the task, Download a CA Certicate, certificate chain, or CRL.If you are in this case, instruct their IT group to go to the AD Certificate Services website (servername.domain/certsrv/). This step may be difficult for many companies that have their own Root CA stood up. In our company, we utilize Microsoft Active Directory Certificate Services to generate certificates for our internal servers. You must get the domain’s Root CA added to the Java Keystore (not the Ignition keystore - this is for securing the gateway webpage and client connections), as when it connects to it, it attempts to validate the certificate and is likely not one that is added by default (and Java doesn’t trust the connection, so it disconnects without doing anything). This information is not logged in Ignition and not much of anywhere. Third, and the most difficult part, was understanding when Java was having an issue connecting securely to your AD server. You will get error messages in the gateway logs if it’s not correct. You might ask your IT department to give you an account that doesn’t expire like most other ones. Second, the AD server may not allow anonymous connections, so entering account credentials into Ignition is important - double check that these are correct. First, ensure you change the ports from 336 to 636 and turning on SSL. You are exposing their credentials in clear text (just Wireshark the traffic and you will see it).Īs others have pointed out, there is not a lot of feedback for not getting LDAPS to work. As of today, this only works for Ignition 7.9.įirst, if you are still using LDAP for authentication and users are currently logging in, you should stop ASAP. I actually wrote a batch script to help get this right for me in our company, as it was multiple steps with so many things that could go wrong.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |