ePO 5.9.1 to 5.10 Upgrade Failure - Insufficient private key length for root CA certificate.

[KingInTheNorth]

The EPO5100-Install-MSI log gives this error:

Property(C): IDS_1024BitKeyError = Setup is unable to connect to the SQL Server "%s" over a secure connection. To rectify this situation, upgrade your SSL/TLS certificate on the "%s" system and retry. See KB 87731 for further information.
Property(C): IDS_PrivateKeyLengthError = This server cannot be upgraded due to insufficient private key length for the root CA certificate. Please contact McAfee ePO Support.
Property(C): IDS_TLSError = An attempt to establish a test connection to the SQL Server "%s" failed. The SQL Server used by McAfee ePO must support a secure communication with TLS 1.1 or 1.2. Please see KB 90222 for more information.

I have been bashing my head trying to get this upgrade to work. I believe that the certificate is already 2048 and when I test the connection it works, but the upgrade installation continues to fail.

Any advice would be greatly appreciated.

Thank you in advance.

[cdinet]

Ignore any property entries in the logs, as they are only cataloging potential errors.  The install msi log will show the error, as will the install error.ini file.  It is typically a java related error, but when you look above the actual error for what the action was, it should show you what specific log to look at, such as the epost.err log, core-upgrade.log or other.  That is where you need to look for the error - typically a "build failed" error.

[KingInTheNorth]

So the installation seems to fail shortly after it drops the new ePO 5.10 browser icon on the desktop then attempts to start new McAfee services. the EPO5100-Error.ini files states:

[ErrorLog]
ErrorString=FAILURE: Unable to start service [MCAFEETOMCATSRV5100]
CustomAction: MerMod_StartCurrentServices
ActionName=MerMod_StartCurrentServices
CustomAction: MerMod_StartCurrentServices

All pre-checks for the installation come back good to go and there is over 30GB of space on each drive. 

Any idea's on where to go from here?

I have attached a zip of all the logs for 5.10 from the C:\Program Data\McAfee\ePolicy Orchestrator\InstallLogs location.

Thank you in advance.

[cdinet]

I don't see any entries in the stderr.log, which logs tomcat startup.  Here are some suggestions for troubleshooting this:

Basically the install is validating that Tomcat is loaded and functional so it can continue with the install.  It will attempt that command 45 times.    It also can fail if the ciphers aren't correct on the epo/sql servers.  5.10 is more restrictive in tls and cipher requirements than 5.9.  Also, if sql is on the same server, then it requires tls 1.0 to be enabled during the install.

1. Validate Tomcat is actually running  
2. Check KB89995 to ensure that is not your issue or to resolve (1024 bit certificate).  
3. If it is starting and then terminating, check the Orion log for any partially installed extensions or other errors, and the stderr.log for any issues there.  
4. Resolve any issues found, then let it try again.   

Before trying again, I would run iiscrypto, choose best practices and reboot - on both epo and sql servers (if sql is separate server).  The account you are using to authenticate to db also (if a Windows account) needs to be a local admin on epo server and not have deny local logon enabled.

You also need to ensure that the version of sql you are running supports tls 1.2, which I believe yours does.  

As a side note, please delete your attachment, as you should not post files with sensitive data on a public forum.

[KingInTheNorth]

I have followed all the steps you recommended and I am still getting the same result. Watching the installation, the issue occurs at the point that it needs to migrate the database to the new one, because that is where I see the installation state it is rolling back.

Any additional advise would be great.

Also, the log files I attached are from a generic VM with no program identifiers, so if you need more logs let me know.

Thank you in advance.

[cdinet]

Actually the logs contained more than you know - there were user names, server names, etc. that should not be published here.  I would suggest opening a ticket so we can review full logs, as there are multiple points in that process that can fail.  If for any reason you can't open an SR, let me know and I will send you private msg where you can email me log files.

What does the *error.ini file log show as the failure?  If it is still at the point of starting services, we might need nmap on the sql ports (kb91115).  If it is other error, then there is something else going on. 

I would also test possibly with the sa sql account and if you can't do that, then check permissions on the account you are using.  The default db has to be master and not any other db and it definitely needs dbcreator rights.  If you can, give that account full rights for the install.