-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error connecting to server via HTTPS after 1.6 update #530
Comments
thank you for your report, can you run the following command from an administrative console and from the installation folder and share the output ? It will provide more SSL debug information when run from the console:
|
Also does using |
Hi @g-bougard When running the command line you specified, inventory occurred normally, even without setting --no-ssl-check. It seems the error only happens on service mode. Do you still need its log output? When setting no-ssl-check for the service on the registry settings, everything went OK too. So, the problem only occurs in service mode, with no-ssl-check set to 0. |
This doesn't sound logic. Can you eventually restart the service or even the computer ? |
I've already restarted the service multiple times. Now I'm trying on another computer and the same is happening. Upgraded from 1.5 to 1.6, restarted the service and the computer but nothing changes. Also, this is happening on Windows 11. I'm gonna try on Windows 10 to see if anything different happens. EDIT: Just confirmed it happens on Windows 10 too. |
Also, I tried starting the service via command line instead of services.msc or the Agent Monitor, and the error did not happen. I also tried changing the service's logon account on services.msc to another common account and the error didn't happen too. It looks as though as the error is happening only when the service is started by the Local System account. |
Now I tried running the command line you mentioned above, but using the Local System account (through PsExec), and I got a detailed error log, as follows:
For reference, here is the log output when running with an user other than the Local System account (only the SSL part)
|
Hum, that's really weird. I really don't understand at that time why the SSL server certificate check fails on when when run under LocalSystem account. The only weird difference I see is the following message when it fails: It seems in that context the CA is not recognized. But I really don't understand why at that point we have this message. Not sure, but this may be related to keystore export. Can you try to set |
Can you make another test ? Take the |
Hi, I have the same issue and made the test with the certificate, it does not resolve the problem. It does not work either with --no-ssl-check option. |
There's another difference too. When it fails, the line that references the CA certificate is different.
When it succeeds, this line appears as
My domain certificate is signed by AlphaSSL CA - SHA256 - G4, which in turn is signed by GlobalSign Root CA. When it fails, there's no mention to AlphaSSL CA - SHA256 - G4. Setting Setting Also tried using |
I have the same issue
I used let encrypt certificat This command not work
with error :
This command work
|
Hello, I was able to reproduce the issue. I managed to find the issue seems to be in the LWP::Protocol::https library. To validate this is the same problem for all, can you try to download the Than make a test. So this seems to be a LWP::Protocol::https regression. |
Hi, I do confirm it works with the downgrade! |
Hi @g-bougard Yes, it does work with the downgraded module! |
Analyzing more deeply, it seems IO::Socket::SSL reports it supports a default CA and the new LWP::Protocol::https has been updated to handle this case. Actually, this seems normal and expected but for some reason, the default CA store is not finally used. This suggested me another possible work-around and this time this is only a configuration work-around. So people, can you keep the original 1.6 https.pm module and just configure: This tells the agent to directly use the provided default CA store included in Mozilla::CA perl library. This is also the one discovered by IO::SSL::Check and the one automatically set by LWP::Protocol::https module in previous version. Then can you test the result ? I'm still investigating. |
It does not work on my side unfortunately |
Now I fully understand the problem. As now LWP::Protocol::https is more confident to leave IO::SSL::Check to use its default CA store, I figure out the way we are registering certificates from windows keystore or macosx keychain will prevent IO::Socket::SSL to use its default CA. So I will change this comportment to always include the Mozilla::CA default store together with detected windows keystore or macosx keychain certificates. This will insure we won't miss the provided default Mozilla::CA store. I'll publish a v1.6.1 soon with that fix. P.S.: This also means only windows & MacOSX packages are affected by this problem, but linux and other ones are not. |
The release will take some time to be published. But you still can validate the fix by replacing the |
GLPI Agent 1.6.1 fixing this specific issue is now available: |
Hi @g-bougard The new release fixed the problem. No other problems detected at the moment. Thanks a lot! |
HI @g-bougard
Can you tell me what is the cause? |
Hi @yecalo |
1.6.1 fix the issue for me. |
Bug reporting acknowledgment
Yes, I read it
Professional support
Yes, I know
Describe the bug
Hi,
I'm getting errors when contacting the server from the Agent via HTTPS after updating to 1.6.
Before the update, everything was working normally. Computers with 1.5 installed can still contact the server normally.
Here is the error that I'm getting on computers with 1.6 installed:
I've already checked the server certificate and everything is fine. It has not expired and time/date on computers and server is OK.
I don't know if it helps, but the certificate is a wildcard one (single certificate applies for all subdomains, as in CN=*.google.com). It is trusted by a well-known certificate authority (AlphaSSL CA - GlobalSign), and CA certs come from the Windows repository itself (no certs specified in GLPI Agent settings)
What could be done about this?
Thanks a lot!
To reproduce
Expected behavior
Prolog should be sent fine and tasks should begin executing
Operating system
Windows
GLPI Agent version
1.6
GLPI version
10.0.10
GLPIInventory plugin or FusionInventory for GLPI plugin version
GLPI Inventory v1.3.3
Additional context
No response
The text was updated successfully, but these errors were encountered: