glpi-project / glpi-agent

GLPI Agent
GNU General Public License v2.0
212 stars 51 forks source link

Error connecting to server via HTTPS after 1.6.1 update #536

Closed yecalo closed 7 months ago

yecalo commented 7 months ago

Bug reporting acknowledgment

Yes, I read it

Professional support

I still have but want a public following to keep the community aware

Describe the bug

Hello,

I receive the following error when trying to run an inventory with agent 1.6.1 installed:

[Tue Nov 21 16:44:56 2023][info] target server0: server https://xxxx.xxxxxxx.xxx.xx/glpi/
[Tue Nov 21 16:44:56 2023][info] sending prolog request to server0
[Tue Nov 21 16:44:58 2023][error] cannot parse C:\Program Files\GLPI-Agent\perl\vendor\lib\Mozilla\CA\cacert.pem as PEM X509 cert: error:25070067:DSO support routines:DSO_load:could not load the shared library at C:/Program Files/GLPI-Agent/perl/agent/GLPI/Agent/HTTP/Client.pm line 486 thread 1.
[Tue Nov 21 16:44:58 2023][info] target server0: next run: Tue Nov 21 17:36:37 2023 - https://xxxx.xxxxxxx.xxx.xx/glpi/
[Tue Nov 21 16:44:58 2023][info] GLPI Agent memory usage: WSS=3420160 PFU=125837312

What could be done about this?

Thanks a lot!

To reproduce

Running the inventory from http://localhost:62354/

Expected behavior

The inventory should be executed.

Operating system

Windows

GLPI Agent version

1.6.1

GLPI version

10.0.10

GLPIInventory plugin or FusionInventory for GLPI plugin version

GLPI Inventory v1.3.3

Additional context

No response

g-bougard commented 7 months ago

Hi @yecalo

okay, this is about your specific problem you reported on #530. So I asked you also to attempt a clean reinstall. To me something should have gone wrong if you had C:\Program Files\GLPI-Agent\perl\vendor\lib\Mozilla\CA\cacert.pem file opened at the same time you try to update the agent. Maybe this was not you but an agent. Did you try to reinstall ?

So to make a clean uninstall, you should uninstall the agent, reboot the computer, check if the installation folder still exists and remove it manually in that case. Then install again the last 1.6.1 GLPI agent.

The file the agent says it can't open is part of the installation. Now many people installed this agent and don't have this problem, so, to me, you made something wrong and this is why I asked you to reinstall the agent.

Also, if you still have the issue on that computer, do you have the same issue on another computer ?

Finally, as you checked the box telling you still have a professional support, if the problem persists after clean installation, I'll ask you to open a professional support ticket.

yecalo commented 7 months ago

Hi, @g-bougard.

Thank you for your reply.

Initially, I attempted to resolve the issue by performing a fresh reinstall of the agent, but unfortunately, this didn’t rectify the problem.

Upon further investigation, I suspect the error may be due to a compatibility issue with the version of Open SSL installed on my system. Previously, I had version 3.1.2 installed. After uninstalling this version, I noticed that the agent began to operate correctly.

I hope this helps!

g-bougard commented 7 months ago

Oh !

Indeed, GLPI-Agent is intended to use the OpenSSL libraries installed under C:\Program Files\GLPI-Agent\perl\bin. So maybe the 3.1.2 installed version you had added its path in the PATH environment variable. We should be able to fix such kind of issue in the future. But first I need to reproduce the case to find the right way to avoid such issue. Can you tell me how you installed OpenSSL 3.1.2 on your system ? For the little history, can you also tell us for what purpose ?

By now, we can assume the issue is fixed by the other library uninstallation, but this is not a good solution if you required it for another purpose.

yecalo commented 7 months ago

I had Open SSL installed on my computer for the conversion of some digital certificates. However, this task isn’t a critical part of my daily routine, so I had no problem uninstalling it.

g-bougard commented 7 months ago

Okay, I understand, but so can you tell me how you installed OpenSSL 3.1.2 on your system ? Where did you take the installer ?

yecalo commented 7 months ago

I installed Open SSL from an executable file downloaded from https://slproweb.com/products/Win32OpenSSL.html

g-bougard commented 7 months ago

Thank you.

Anyway, the actual version is no more the same. I tried with the latest package: Win64OpenSSL_Light-3_1_4.msi This one installed libssl-3-x64.dll Dll in system folder. But this DLL won't definitively be loaded by GLPI-Agent or better the libraries it depends on. The one provided is libssl-1_1-x64__.dll and GLPI-Agent execution environment will look for a dll with that name, not the libssl-3-x64.dll one so.

Is it possible you had the DLL preloaded by an automated script ? I'm not sure if the DLL symbols are exported glpi-agent will try first to use the known one.

g-bougard commented 7 months ago

Can you eventually try to reproduce the issue now ? And then give me more details so I can reproduce too. If you don't manage to, this may mean Win32OpenSSL package has itself evolved and fixed such kind of issue.

yecalo commented 7 months ago

Hi, @g-bougard. I have installed the Win64OpenSSL_Light-3_1_4.msi, and unfortunately, the same issue that was reported earlier with running the agent has recurred. It's interesting to note that this problem did not arise when I was using version 1.6 or 1.5 in conjunction with Win64OpenSSL_Light-3_1_2.msi

g-bougard commented 7 months ago

Okay, what options did you select during Win64OpenSSL_Light-3_1_4.msi installation ?

Indeed, this is not really interesting as you're saying. This is indeed normal as the 1.6.1 fix forces the load of C:\Program Files\GLPI-Agent\perl\vendor\lib\Mozilla\CA\cacert.pem. Maybe the way it is done is wrong, but understanding what is really wrong here is essential to find the right way of doing.

So help me to reproduce and I'll check if the problem is in the fix or in the installed environment.

g-bougard commented 7 months ago

Are you able to reproduce the same error on a computer where you didn't installed Win64OpenSSL before ? Maybe you have an automatic process which load the DLL and the related symbol before the agent is started.

g-bougard commented 7 months ago

Have you another software installed that can depend on Win64OpenSSL ? Have you another perl installed ? Actually, I still don't see how the installation can make trouble with GLPI-Agent as DLLs to load are named differently.

g-bougard commented 7 months ago

Just in case, can you share your console environment ? Or output of the following command in an administrative cmd console:

set
borodulino commented 7 months ago

glpi-agent-ssl-error.txt Hello. I have a similar problem, but only on linux. The agent version 1.5-1 is installed on a windows PC and everything works well. A certificate signed by a subsidiary enterprise certification authority is installed on the glpi server. In the browser, this certificate is displayed as valid. The option ca-cert-file = /etc/ssl/certs is specified in the glpi-agent configuration file (00-install.cfg). PC in the domain. All the services that exist work with enterprise certificates and trust them. But when trying to send an inventory, the glpi agent gives this certificate verification error:

[error] [http client] internal response: 500 Can't connect to glpi.***.net:443 (certificate verify failed), SSL connect attempt failed error: 1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
[error]  No supported answer from server at https://glpi.****.net/plugins/glpiinventory/

If you remove the path to the ca-cert-file certificates and add the ssl-fingerprint option, then everything works fine. glpi-agent version 1.6.1 server version 10.0.10 glpi-inventory plugin version 1.3.1 glpi-agent is installed on debian 10

g-bougard commented 7 months ago

Hi @borodulino

this has nothing to do with this issue. you seem to have set ca-cert-file = /etc/ssl/certs and this is totally wrong. This option must be used when you exported the server certificate to a PEM-file and then it should be the full path to a file, not a path to a folder. You may prefer to use ssl-fingerprint option which doesn't require you to have a file on the agent-side, but just knowing the server certificate fingerprint. You can temporarily enable no-ssl-check to discover the fingerprint value you should use in that case.

borodulino commented 7 months ago

I mistyped, I used the ca-cert-path option not the ca-cert-file option. I wrote above, I already used the ssl-fingerprint option and with it the agent really works, but when my server certificate expires I will have to update the key fingerprint on all machines which is not correct, instead I installed the server pki root certificate in each machine and I want glpi-agent to check the connection using my two root certificates, but it doesn’t do this, instead I get this error

g-bougard commented 7 months ago

@borodulino Don't hijack a not related issue. Please open a Q&A discussion.

g-bougard commented 7 months ago

Hi @yecalo

I'm closing this issue as you know how to work around the problem.

Anyway I didn't understood how that OpenSSL package can make a problem. Maybe we missed something else. If you find what feel free to comment in the case it can suggest me how to avoid such problem in the installer.

Frflamingo commented 5 months ago

FYI . i just add the same issue with 1.7.1 . Uninstall and reinstall doesn't have any impact ... Installed 1.5.0 . it went fine

g-bougard commented 5 months ago

Hi @Frflamingo do you mean you also have installed Win64OpenSSL ? If not, please read the issue before hijacking a not related issue.

Frflamingo commented 4 months ago

This was on a standard windows PC , not knowing what else was installed ... Just wanted to inform you ...

g-bougard commented 4 months ago

To diagnose SSL problems, you now have a dedicated article in our official FAQ here: https://faq.teclib.com/02_FAQ/Agent/ Check the last one, there's also a dedicated article to SSL configuration.

g-bougard commented 1 month ago

Hi @yecalo & @Frflamingo

I think work done for #636 & #670 is probably fixing also your cases. Can you test with the latest nightly build ?