Skip to main content

Hello 

Long time reader first time poster so bear with me. 

In my environment there is a legal need to scan every incoming and outgoing connection using our firewall (fortigate - deep ssl ) . The only functionality that is broken is no mail fetching due to ssl mismatch. 

 

So my real question is : does the platform use different keystone than windows server root authority for outgoing connections ? I need to place my certificate somewhere, but all my tries were failed to say the least. Any ideas fellow sysaiders ?

(Have searched the docs , forums, to N/A)

 

Thank you 

Avgerinos:

 

I’m going to assume you are on-prem…

This is what I have running on my install

Export the windows cert to PKCS12 (3DES) and make sure you have the password, save it wherever you want, I usually use c:\program files\sysaidserver

Cert path and password get put into the tomcat conf… and it strange as it may seem put the password in plain text. The system will hash it after you restart tomcat


C:\Program Files\SysAidServer\tomcat\conf\server.conf around line 70

 

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="C:\Program Files\SysAidServer\Cert-Name.pfx" keystoreType="PKCS12" KeystorePass="hashed-password" sslEnabledProtocols="TLSv1.2,TLSv1.3" ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"/>

 

this also assumes you get the port to 443 from the default 8443, so your mileage may vary

 

hope that helps

 

John


Hi @Avgerinos

Please go to Email integration, click on a test button to check the connection, and provide us with the exact error that you receive. 

 

Thanks


@jsidoti Thank you for your answer. 
I will try it on the next maintenance window, for the time being the deep ssl rule affecting the ticketing platform has been turned off. 

 

@NatCohenSheffer attached the two images  ; 

 

 

 


Hi @Avgerinos

It’s been a while (sorry about that!) but if you still need help please let us know. 

Based on the error it looks like an issue with the certificate side on the exchange. Either way, you may find this link helpful as it can point you in the right direction to address this error> https://stackoverflow.com/questions/4062307/pkix-path-building-failed-unable-to-find-valid-certification-path-to-requested 

 

Cheers :)


Reply