On our ePO server, we have started the Certificate Manager to regenerate the root certificate from 1024 bit. It states that you don't activate until you get close to 100% off the agents communicate with the ePO server. Well, in our environment, due to remote work, we don't have all the client communicate back unless they use the VPN.
In my testing , I applied the latest McAfee ePO CU11 and then noticed that the clients would then not communicate back. Is this due to the 1024 root certificate and if so what is the workaround so we can apply CU11 and not loose agent connectivity? It may take months for us to have most clients communicate as some are still remote working and some are laptops that don't get turned on for months.
Solved! Go to Solution.
You could try reinstalling the ah.
If you do complete the cert migration, then any remaining systems that did not get the new cert can be fixed by 2 ways. One, reinstall the new agent package that has new certs in it. Or you can run maconfig and point it to the new certs. This is documented in the MA install/product guide for changing a system from unmanaged to managed. It doesn't matter that the system is already managed, you are just pointing it to the new certs/keys and sitelist with new cert.
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Hi,
What is the Agent Version you have on your ePO Server. If you have one of our legacy agent version, then please review:
Enabling legacy McAfee Agent versions to communicate with ePO 5.10 Update 11 or later
https://kc.mcafee.com/agent/index?page=content&id=KB86318
If you use the latest agent version, can you please go to %programdata%/McAafee/Agent/Logs, there you will find masvc_hostname.log. Can you please check with what error message the communication fails?
You can search with "Response Code". Anything other than 200/202 is failed communication. Please provide the HTTP Response code error message and "Curl Error code", like : 56/28/7/6/35, you get.
I have tested CU11 on my machine with the 1024 certificate and the communication seems to be working fine. Agent-communication issue after applying CU11 is not reproducible.
You do not have to wait until its 100%, the closer you can get to 100% the better, on the rest of the machines you can then re-deploy/provide agent package for agent install. This will restore communication. (Not sure about the difficulty of this task since you mentioned the users are connecting remotely).
My first question, is your ePO is still with 1024 key, since your query says 1024 root cert, moreover ePo upgrade to 5.10 would have failed, if it is using 1024 key , until it is 2048 key as by default recommended... either it is TLS 1.0, 1.1, or 1.2, if the issue with TLS protocol not supporting then you can use the KB86318 to get enabled, when the tomcat became the server component and client is any source...... this time you can do changes on SERVER>xml for this to get work.
But, again if the communication key itself 1024, then it will not work.
Got to ePO folder and click on apache2\conf\SSL.crt\
Double click the file: AHcert
Click on Details you will see the key length... it will be always 2048.
Yes, the AHAcert file is saying that it is 1024bit. The problem that we have is that we would like to install CU11 to get tomcat, lava, apache etc updated. However, the CU11 will install but then the clients will then not communicate. In our environment we are using the latest ePO agent 5.7.4.
I understand that to get the root certificate updated you have to run the certificate manager. However, it states that you need close to 100% of clients to communicate after you regenerate the certificate and before activating. It is difficult in our environment since we have a lot of systems, like encrypted laptops that stay off line for months at a time and we still have people remote working. We also don't have an easy capability of fixing broken agents especially the remote ones.
So it look likes we won't be able to install CU11 until we get all clients communicating with the ePO server so we can then activate the root cert from 1024 to 2048.
Our ePO server is currently running version 5.10 with CU10.
Is there any workarounds for this?
I still surprise to see after ePO 5.10 CU10 it showing 1024, so it looks this ePO is upgraded from long way as 5.1 or 5.3 - > 5.9 and then 5.10 or so.
But, I can suggest to try one step... by regenerating the cert... option by stopping apache and event parser service and follow KB90760 article
https://kc.mcafee.com/corporate/index?page=content&id=KB90760
Then, check the AHcert is shows as 2048 key.
Also check the server settings - Security keys and share image, is that has the 2048 key and is the clients NOT reporting to this key, being master ?
Additionally, I think even console cert will be in 1024key, if this is the case..
For the console, you can easily get those to 2048 key, by just go to server settings - server certificate - click on EDIT and just click SAVE ( Without doing anything) and restart ePO services.
The console cert should be with 2048.
If you want to compare before and after key size for console cert, open the epo console via browser and click on the connection error... and view certificate to check the key size.
Overall cert is valid but the key size should bring to 2048.
Yes, the server was upgraded from older versions of ePO over the years.
Just followed your instructions and it recreated the certs. The ahCert.crt file still reports that it is 1024bits.
Under the certificate manager the only cert that we have that shows 1024bit is the agent handler, we only have one which is the ePO server, and the server root certificate.
The Server certificate and Client Certificate Authorization both show 2048bits. We are using a third party certificate for the web console.
You could try reinstalling the ah.
If you do complete the cert migration, then any remaining systems that did not get the new cert can be fixed by 2 ways. One, reinstall the new agent package that has new certs in it. Or you can run maconfig and point it to the new certs. This is documented in the MA install/product guide for changing a system from unmanaged to managed. It doesn't matter that the system is already managed, you are just pointing it to the new certs/keys and sitelist with new cert.
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA