Troubleshoot SSL

SSL/TLS is not a part of IFS Application its a just protocol, hence problems that are related to SSL/TLS are not primarily IFS Application formal responsibility

If IEE client don't download and gives a SSL/TLS error.

If the landing page is downloaded after manually accepting an untrusted certificate in the browser - then an error will occur when .Net click-once tries to download the client repository. The .Net Click-once requires a trusted certificated to be avaliable in the Windows truststore (certmgr).
To be able to download a IEE repository over click-once using self-signed ceritifcates it is madatory to download and install the client certificate on all machines that needs to download the client. The client certificate to install is located in <ifs_home>/instance/<instance>/security/certs/import/<instance>.cer.
This is the reason self-signed certificates should NOT be used other than when only a very small group of users temporarily will use a system.

Manually validate a certificate

First verify that the pfx or p12 (PKCS#12) certificate store is correctly created by listing it's contents

keytool -list -keystore MyKeyStore.pfx

 The output should state that it contains one entry "Your keystore contains 1 entry"
If there is an error here the keystore is probably created in the wrong format i.e. not PKCS#12

Adding - v (verbose) will show Owner and Issuer of the whole certificate chain and the validity dates.

keytool -list -v -keystore MyKeyStore.pfx

You should find the following rows in the output for a certificate with one intermediate certificate (you can follow the Chain of Trust:  owner/issuer -> owner/issuer -> owner/issuer):

Your keystore contains 1 entry
Certificate chain length: 3
SubjectAlternativeName DNSName: <server FQDN>

Certificate[1]:
Owner: CN=<server FQDN>
Issuer: CN=<The intermediate certificate>
Valid from: 02-02-2017 until: 02-02-2018

Certificate[2]:
Owner: CN=<The intermediate certificate>
Issuer: CN=<The root certificate>
Valid from: 02-02-2016 until: 02-02-2026

Certificate[3]:
Owner: CN=<The root certificate>
Issuer: CN=<The root certificate>
Valid from: 02-02-2010 until: 02-02-2035

Important that the whole certificate chain is included in the certificate PKCS#12 keystore.
The validity dates of ALL certificates must be fulfilled.

SSL Negotiation fail on client side

If there is a "Could not establish trust relationship for the SSL/TLS secure channel." the root cause can vary a lot but most probably the Certifcate is not valid (e.g. dates) or a broken "Chain of trust".
On the client side use certmgr to see all trusted CA's:

From PowerShell the following statement can be run  to list all trusted root certificates (here it's the CN's):

PS C:\> dir Cert:\CurrentUser\AuthRoot


PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\AuthRoot

Thumbprint Subject
---------- -------
F9B5B632455F9CBEEC575F80DCE96E2CC7B278B7 CN=AffirmTrust Commercial, O=AffirmTrust, C=US
F18B538D1BE903B6A6F056435B171589CAF36BF2 CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawt...
E12DFB4B41D7D9C32B30514BAC1D81D8385E2D46 CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
DE3F40BD5093D39B6C60F6DABC076201008976C9 CN=QuoVadis Root Certification Authority, OU=Root Certification Authority, O=QuoVadis Limited, C=BM
DE28F4A4FFE5B92FA3C503D1A349A7F9962A8212 CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
DAC9024F54D8F6DF94935FB1732638CA6AD77C13 CN=DST Root CA X3, O=Digital Signature Trust Co.
D69B561148F01C77C54578C10926DF5B856976AD CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3
D4DE20D05E66FC53FE1A50882C78DB2852CAE474 CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
D23209AD23D314232174E40D7F9D62139786633A OU=Equifax Secure Certificate Authority, O=Equifax, C=US
CA3AFBCF1240364B44B216208880483919937CF7 CN=QuoVadis Root CA 2, O=QuoVadis Limited, C=BM
B51C067CEE2B0C3DF855AB2D92F4FE39D4E70F0E CN=Starfield Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, S=Arizona, C=US
B31EB1B740E36C8402DADC37D44DF5D4674952F9 CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entr...
B1BC968BD4F49D622AA89A81F2150152A41D829C CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE
AFE5D244A8D1194230FF479FE2F897BBCD7A8CB4 CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
AD7E1C28B064EF8F6003402014C3D0E3370EB58A OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
A8985D3A65E5E5C4B2D7D66D40C6DD2FB19C5436 CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
97817950D81C9670CC34D809CF794431367EF474 CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
91C6D6EE3E8AC86384E548C299295C756C817B81 CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, In...
8CF427FD790C3AD166068DE81E57EFBB932272D4 CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-...
8782C6C304353BCFD29692D2593E7D44D934FF11 CN=SecureTrust CA, O=SecureTrust Corporation, C=US
75E0ABB6138512271C04F85FDDDE38E4B7242EFE CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
742C3192E607E424EB4549542BE1BBC53E6174E2 OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
627F8D7827656399D27D7F9044C9FEB3F33EFA9A E=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town,...
6252DC40F71143A22FDE9EF7348E064251B18118 CN=Certum CA, O=Unizeto Sp. z o.o., C=PL
5FB7EE0633E259DBAD0C4C9AE6D38F1A61C7DC25 CN=DigiCert High Assurance EV Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
51501FBFCE69189D609CFAF140C576755DCC1FDF CN=Hotspot 2.0 Trust Root CA - 03, O=WFA Hotspot 2.0, C=US
503006091D97D4F5AE39F7CBE7927D7D652D3431 CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limit...
4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5 CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSi...
47BEABC922EAE80E78783462A79F45C254FDE68B CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
3E2BF7F2031B96F38CE6C4D8A85D3E2D58476A0F CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
36B12B49F9819ED74C9EBC380FC6568F5DACB2F7 OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
3679CA35668772304D30A5FB873B0FA77BB70D54 CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Netw...
323C118E1BF7B8B65254E2E2100DD6029037F096 CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US
2B8F1B57330DBBA2D07A6C51F70EE90DDAB9AD8E CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, S=New Jersey, C=US
2796BAE63F1801E277261BA0D77770028F20EEE4 OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
132D0D45534B6997CDB2D5C339E25576609B5CC6 CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSi...
07E032E020B72C3F192F0628A2593A19A70F069E CN=Certum Trusted Network CA, OU=Certum Certification Authority, O=Unizeto Technologies S.A., C=PL
0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 CN=DigiCert Assured ID Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
039EEDB80BE7A03C6953893B20D2D9323A4C2AFD CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US
02FAF3E291435468607857694DF5E45B68851868 CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE

In integrations in connect you can see errors like "javax.net.ssl.SSLHandShakeException: Unsupported curveId: 29"

There are situations where the secure communication negotionation will not work. In some cases it is almost "expected to fail" if e.g. IFS Connect is negotiating with much older or much newer 3pp applications. The negotiation will fail if the range of valid encryption algorithms on each side don't match. One of the sides need to change which versions can be used so the negotiation succeeds. IFS tries to be active in updating and discontinue old insecure protocols/algorithms.

In the installer (Web Server Configuration) it is possible to specify which Ciphers suites and protocols the IFS WebServer supports in secure communication negotiations.

Tools like Wireshark might be required to in detail see how the SSL negotioation progresses and eventually fails, then the reason can be established.