epo 5.10 Update 11 can't connect to Database

[dcaffrey]

Currently running ePO 5.10 Update 10 - No Issues

After applying Update 11 I get an error connecting to the database - Test Connection shows this 

Test failed: Network error IOException: insufficient_security(71)

I've run IISCrypto on both ePO and SQL servers and they seem ok 

Any help much appreciated

[cdinet]

What did you do specifically with iiscrypto?  If everything is grayed out and it looks like a lot of things are checked, that means it is using OS defaults and may not be sufficient.  Make sure you used choosing best practices in iiscrypto and reboot on both epo and sql.  If you did that, then we would need a wireshark capture, mer from epo and nmap outputs from epo and sql servers (kb91115) and open an SR so we can review the data.

Wireshark capture would need to be when you start epo services - start capture first, then start only application server service, all interfaces.  That captures the ssl handshake.

If sql is on the same server, follow kb91433 to get loopback traffic for the handshake.

[cdinet]

Update 11 removed some weak ciphers, so it is possible that one of the servers doesn't have the right ciphers.

[dcaffrey]

NMap shows these ciphers on the SQL server

TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - F
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - F
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - F
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - F
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp521r1) - F
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp521r1) - F
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp521r1) - F
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp521r1) - F
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - F
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - F
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - F
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - F
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - F
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Insecure certificate signature (SHA1), score capped at F
|_ least strength: F

[cdinet]

Match them with what epo has.  Wireshark is best to know what cipher sql is responding with.  In a wireshark capture, you will see server hello - it would show the exact cipher that sql responded with.  In the client hello packet, you see the list of ciphers epo is offering up to negotiate with.  If sql doesn't have one of the ones epo offers, it can't negotiate the handshake.  

[cdinet · Accepted solution]

Check also KB91519 - there is a section in there for specific requirements for update 11.  If you did open a ticket, please send me the case number in private chat.

For ePO 5.10 CU 11 and later:
For outbound connections to the SQL Server, Tomcat supports the following cipher suites:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA

So, on the SQL Server hosting the ePO database, at least one of these suites must be enabled in the SChannel Settings, which includes installations where SQL is on the same computer as ePO.

For inbound connections from the ePO Server service and ePO Agent Handler service, Tomcat supports the four cipher suites listed below: 

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA​

So, on the computer where ePO is installed, and on any remote agent handlers, at least one of these cipher suites must be enabled in the SChannel Settings.

[dcaffrey]

I ran IISCrypto on the SQL server again applied best practices and rebooted.

I tried Update 11 again and it connected ok

This is the TLS Cipher Suite being used now

TLSCipherSuite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

This is the one used with Update 10

TLSCipherSuite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

[cdinet]

Glad it is working and glad to help!

[Fernando_Munoz]

Hi, I have a problem after doing this procedure.

the apache service consumes all the server resources and I can't do anything, any idea how to solve this problem

[cdinet]

Please open a ticket, as we will need to review logs.  Get screenshots also of what resources specifically are being consumed (memory or cpu) and showing exactly what process.

Some typical causes of this with apache (server service) is the use of a syslog server that is failing to connect, siem connected to database locking tables causing long session times, database mirroring not enabled in server settings, user policies if using any user based policies (kb84683), too frequent asci, too frequent repository requests.  For the last 2, examine what your agent-server communication interval is compared to how many clients you are managing, and how many tasks are scheduled and their frequency.  Additionally, if you have distributed repositories, how much are they being utilized instead of clients hitting epo or agent handlers all the time?