I get the same error even though I also have RSA 2048 bit certificates. During the beta I had resolved this issue by manipulating the SCHANNEL crypto providers but then when the RTM PIA came out this error returned. I haven't been able to continue the upgrade though due to other blocking issues.
Same problem here, running SQL 2014 and Server 2012 R2. I ran the upgrade in a test environment and it worked anyway.
Same problem here, any Solutions ?
Running SQL 2012 and Server 2012 R2 with all Windows updates.
Same issue here.
Tried with two MS SQL servers, but can't pass it:
1. MS SQL 2012 x64 SP3 CU8 running on Windows 2012 x64 with all updates installed (including required KB3042058), and the following SSL certificate deployed:
Signature algorithm: sha256RSA
Signature hash algorithm: sha256
Key size: RSA 2048 bits
2. MS SQL 2014 x64 SP2 CU5 running on Windows 2012 R2 x64 with all updates installed (including required KB3042058), and the following SSL certificate deployed:
Signature algorithm: sha1RSA
Signature hash algorithm: sha1
Key size: RSA 2048 bits
Anyone here who successfully passed this check? What exactly is it checking for: particular SSL cipher suite order or is it related to the strength/algorithm of the SSL certificate/key?
Are you all using self signed certificates for the MS-SQL server? I've done a bunch of messing around with SHA & RSA levels and SSL cipher suites to match what's supposed to be set but I also get the same error. The only thing I can think of is I'm using domain signed certificates which are fully valid inside my domain but maybe the PIA doesn't trust them?
Honestly though just move on past this step and run the installer, see if it can talk to your DB and prepare to install. The PIA complains about it but the installer doesn't care and will actually install is what I found in my experience. If it couldn't actually correctly talk to the DB then all of the DB driven portions will fail which is not what I experienced. Just always make sure you have good backups.
Indeed, all my certificates are self-signed. As long as you place those into Trusted Root Certification Authorities on the server where you execute PIA, whether the certificate is self-signed or from a proper CA becomes irrelevant -- it should be trusted. Now, whether PIA takes this into account while performing the check is the million-dollar question.
I suspect that it has something to do with the particular (most probably strengthen) SSL cipher suite order, because this is what KB3042058 introduces (if you look at the KB you can achieve the same with the GPO), however I can't get anything meaningful from the support.
Unfortunately, I don't have ePO in the lab, hence I'm a bit reluctant to proceed with the installation in production, since you can end up with the successful installation but no SQL communication between ePO and SQL instances.
Are you saying that your upgrade worked (despite the RSA compatibility failure)?
we had same issue.. 2008 R2 servers running all compatible software yet the tool was saying we are missing RSA support because it was checking for 2012 Server KB patch..
McAfee couldn't figure out what was going on. i ended up installing blank 5.9 and trasferring assets to new EPO (see link below)
Well, according to the support:
You may ignore the RSA compatibility check failure when running the ePO Pre-Install Auditor tool. the upgrade will be successful without SSL connection to SQL server.
which doesn't make sense, because I DO use SSL connection.
Anyway, I was about to start the upgrade (with tons of backups, clones and snapshots), but got stuck with some not supported extensions (such as MOVE AV 3.6.x and etc).