I've read lots of replies for people being told by 3CX support that you need to be running SQL 2019 for this to work, that 2014 etc does not support TLS 1.2. This is absolutely wrong. Microsoft has added TLS1.2 support in as far back as SQL Server 2008R2 and there is zero reason you need to upgrade your SQL server to get this to work.
The underlying problem is you need to load a certificate into SQL server's network configuration for your SQL instance or it will not reply to 3CX's TLS 1.2 Client Hello messages.
5 seconds of googling or 5 minutes of testing would have established that MS has full TLS1.2 support back to SQL2008R2, but in typical 3CX support fashion their response is "TLS 1.2 doesn't exist pre 2019" and "Just upgrade your production SQL server to 2019 what's your problem". Oh, I don't know.... Perhaps change management? Perhaps hundreds of thousands of dollars in licensing? Perhaps we just don't upgrade mission-critical production database servers running in-support database engines based on wildly incorrect assumptions?
Anyway, for those who had the issue, here is the actual fix:
Step zero is to make sure you're running a TLS1.2 updated SQL server. Microsoft has a good guide on what you need to enable TLS 1.2 (possibly from 2008R2 and up):
https://support.microsoft.com/en-us...l-server-e4472ef8-90a9-13c1-e4d8-44aad198cdbe
Assume you're running a patched/updated SQL server with support for TLS 1.2:
1. Get a proper cert for your box if you have one, or if not (and you're not super concerned with external TLS connectivity or using self-signed certs) generate a self-signed certificate using powershell and dump it in the computer store:
New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname your.server.name.goes.here
2. Copy the "Thumbprint" output from the above as you may need it (configuration manager will not play nice if you've upgraded before)
3. Run SQL Configuration Manager
- Navigate to SQL Server Network Configuration
- Right-click "Protocols for YOURINSTANCENAME" and click Properties
- Click Certificate tab
- Pick the cert you just generated and press apply (or import one if you have a proper cert, or import it in certmgr and select it from the list)
- Restart SQL services
4. If you couldn't pick a cert, you have to install the Thumbprint into registry:
- Regedit your way to:
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.*YOURINSTANECNAME*\MSSQLServer\SuperSocketNetLib
- Set "certificate" to be the Thumbprint you copied from step 2.
- Restart SQL services
And with that, your 3CX should now be CRM'ing fine.
Note: If you run into issues with cipher suites, download/run iiscrypto, select "Best Practice", then manually tick all the TLS_ cipher suites excluding those crappy RC4/Null ones, apply and reboot. You can wireshark it and do best practice + an algorithm that 3CX supports but you'll have to DIY that as I can't remember one off the top of my head.
Good luck!
The underlying problem is you need to load a certificate into SQL server's network configuration for your SQL instance or it will not reply to 3CX's TLS 1.2 Client Hello messages.
5 seconds of googling or 5 minutes of testing would have established that MS has full TLS1.2 support back to SQL2008R2, but in typical 3CX support fashion their response is "TLS 1.2 doesn't exist pre 2019" and "Just upgrade your production SQL server to 2019 what's your problem". Oh, I don't know.... Perhaps change management? Perhaps hundreds of thousands of dollars in licensing? Perhaps we just don't upgrade mission-critical production database servers running in-support database engines based on wildly incorrect assumptions?
Anyway, for those who had the issue, here is the actual fix:
Step zero is to make sure you're running a TLS1.2 updated SQL server. Microsoft has a good guide on what you need to enable TLS 1.2 (possibly from 2008R2 and up):
https://support.microsoft.com/en-us...l-server-e4472ef8-90a9-13c1-e4d8-44aad198cdbe
Assume you're running a patched/updated SQL server with support for TLS 1.2:
1. Get a proper cert for your box if you have one, or if not (and you're not super concerned with external TLS connectivity or using self-signed certs) generate a self-signed certificate using powershell and dump it in the computer store:
New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname your.server.name.goes.here
2. Copy the "Thumbprint" output from the above as you may need it (configuration manager will not play nice if you've upgraded before)
3. Run SQL Configuration Manager
- Navigate to SQL Server Network Configuration
- Right-click "Protocols for YOURINSTANCENAME" and click Properties
- Click Certificate tab
- Pick the cert you just generated and press apply (or import one if you have a proper cert, or import it in certmgr and select it from the list)
- Restart SQL services
4. If you couldn't pick a cert, you have to install the Thumbprint into registry:
- Regedit your way to:
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.*YOURINSTANECNAME*\MSSQLServer\SuperSocketNetLib
- Set "certificate" to be the Thumbprint you copied from step 2.
- Restart SQL services
And with that, your 3CX should now be CRM'ing fine.
Note: If you run into issues with cipher suites, download/run iiscrypto, select "Best Practice", then manually tick all the TLS_ cipher suites excluding those crappy RC4/Null ones, apply and reboot. You can wireshark it and do best practice + an algorithm that 3CX supports but you'll have to DIY that as I can't remember one off the top of my head.
Good luck!
