Remove old peer certificates

[antoineL 0]

Hi:

Currently running version 9.0.1144.

I have issues with some old certificates issued in 2016, no longer in use, which are giving me headaches.

1. The CA certificate that was issued then was for 10 years, i.e. until 2026. The certificates themselves were emitted for 5 years (so they are expired.) But the status shows as "Certification Authority has already expired." Is it just an UI glitch without consequences?
2. Is there some way to remove such old certificates from the database? Or perhaps remove them from being considered?
3. I found a 2015 thread this about, where Peter Randziak sort-of promised some enhancements, but I am unable to find where such enhancement has been installed.
4. My main issue is that for reason I cannot understand, the Upgrade Agent task is selecting that expired certificate instead of the one which is valid and in use. What is really strange is that I used the same task month ago, and it selected the correct certificate then.

Any hint?

[Marcos 5,070]

Old certificates cannot be used for successful authorization. Valid certificates can be revoked if you need to invalidate them for whatever reason. However, certificates cannot be removed.

[MartinK 378]

On 1/7/2022 at 1:10 PM, antoineL said:

My main issue is that for reason I cannot understand, the Upgrade Agent task is selecting that expired certificate instead of the one which is valid and in use. What is really strange is that I used the same task month ago, and it selected the correct certificate then.

Could you please provide more detail of this issue? In case components upgrade task is used to upgrade AGENT, there should be no configuration change involved.

[antoineL 0]

1 hour ago, MartinK said:

Could you please provide more detail of this issue? In case components upgrade task is used to upgrade AGENT, there should be no configuration change involved.

Sure.

I have two sets of certificates: one is an old pair, linked to an old certificate authority built in 2016. The certificate authority is still valid, but the actual agent and server certificates are not any more. They are flagged in red on the board (which is annoying, but I can live with it.)

The other certificate authority was built in 2020, there are two valid certificates for server and agents, the server and all the agents are using it, particularly since there is a task in place for connected agents to switch to it. Everything OK here.

Now comes the upgrade to 9.0. the automated process upgraded the console, the local agent and the server, keeping the valid certificates. Until there, no problems.

Then I am upgrading the agents. In the past I settled as the easiest way is to push the installation of the agents, particularly since there is an option to select the latest available version. It has the nice property to be the way to go when installing a new computer, which occurs more often than upgrading ESET PROTECT.
However, when I visited this area of task planning, the previously working task is now shown in yellow, marked "the referenced peer certificate is not available." Editing it, at the Settings page, under Certificate settings, the not-valid peer certificate is shown and selected, but I cannot change it for the now valid one.
Worse, when I create a new task, the same problem occurs: the old certificate is selected, and there is no way to change the selection (the only other option is to use another, new, "custom certificate", importing a PFX.)
I sort-of solved the problem by setting to 1 the Removed field in the SQL database, but I do not feel this is the way it should work.
Perhaps I should have changed it before the certificate went invalid; however it does not seem clear to me I can use that kind of task and select a certificate which is not the earliest one. In other words, when one agent certificate is expired, that kind of task is basically unusable.

Now while answering you, particularly the "components upgrade task" part, I notice there is another path, namely a client "ESET PROTECT Components Upgrade" task, aptly described as "Upgrade client (after server upgrade)." I think I was advertised of it when upgrading (but the dialog dismisses when upgrade starts, there are no links to the actual task, and there was no obvious hint that I should use it after the restart.)
When I look at the previous such tasks (which means I used in the past, perhaps at the last upgrade?) I notice they are flagged in yellow because "the referenced repository package is not available", which is a correct description. Obviously, the newly created one is pointing at PROTECT 9.0.1144.0. Also, here I can edit the old tasks.
Using these tasks now work and the client agents are now upgrading; but since it was after I solved the above problem, I cannot be sure having "removed" the old certificate using SQL had any influence.

[antoineL 0]

On 1/8/2022 at 12:19 PM, Marcos said:

Old certificates cannot be used for successful authorization. Valid certificates can be revoked if you need to invalidate them for whatever reason. However, certificates cannot be removed.

Thanks for rephrase my post in a concise way.

I just notice that you can also revoke not anymore valid (expired) certificates as well. An action that was not at all obvious to me.

However, from what I am now seeing, it seems to be how they should be handled, since an effect of it is to update the Removed field to 1, thus preventing the Upgrade Agent task to select the expired certificates while created.

[MartinK 378]

21 hours ago, antoineL said:

Then I am upgrading the agents. In the past I settled as the easiest way is to push the installation of the agents,

Thanks for clarification - now it makes sens as you are actually not performing standard/recommended upgrade using components upgrade task (https://help.eset.com/protect_admin/90/en-US/client_tasks_upgrade_components.html) but you are actually using re-deployment, which is capable of changing configuration.

Regarding revocation of certificate as available in the console, it actually performs two actions:

• adds this certificate to list of revoked certificates, which will technically block it's usage in the environment from security perspective
• it remove this certificate in terms it will be no longer visible in the console - this should also prevent it's usage in various installers, especially those that try to detect proper certificate automatically.

[antoineL 0]

47 minutes ago, MartinK said:

Thanks for clarification - now it makes sens as you are actually not performing standard/recommended upgrade using components upgrade task (https://help.eset.com/protect_admin/90/en-US/client_tasks_upgrade_components.html) but you are actually using re-deployment, which is capable of changing configuration.

Regarding revocation of certificate as available in the console, it actually performs two actions:

• adds this certificate to list of revoked certificates, which will technically block it's usage in the environment from security perspective
• it remove this certificate in terms it will be no longer visible in the console - this should also prevent it's usage in various installers, especially those that try to detect proper certificate automatically.

Thanks to confirm what I was thinking while writing yesterday. It very much looks like I was side-tracked by the fact the "re-deployment" task is listed under Server tasks, while the "standard upgrade" is under Client tasks. I know client deployment is almost exactly at the midpoint between the two categories, but the fact the two tasks are classified differently does not help at all.

About revocation, I am going to take your answer as meaning that revocation is the way to go when one wants to get rid of an expired certificate, even if the purpose is not to technically invalidate it (since an expired certificate is already invalid.) Perhaps you could ask to improve the documentation this about?
(By the way, while the French version says the same as the English one, the Spanish one uses another word, "cancelled" instead of "invalidated", which I find a bit less misleading. Even if I'll prefer to read "Removed".)