Skip to content
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

Closed
redddcyclone opened this issue Nov 16, 2023 · 24 comments
Closed

Error connecting to server via HTTPS after 1.6 update #530

redddcyclone opened this issue Nov 16, 2023 · 24 comments
Labels
bug Something isn't working

Comments

@redddcyclone
Copy link

redddcyclone commented Nov 16, 2023

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:

image

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

  1. Update GLPI-Agent from any version to 1.6
  2. Try to send an inventory to the server (via HTTPS)
  3. Inventory is not sent and Agent goes back to 'waiting' state
  4. Check the logs and see the error

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

@redddcyclone redddcyclone added the bug Something isn't working label Nov 16, 2023
@g-bougard
Copy link
Member

Hi @redddcyclone

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:

glpi-agent --logger=stderr --debug --debug --force

@g-bougard
Copy link
Member

Also does using --no-ssl-check permit the communication to work ?

@redddcyclone
Copy link
Author

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.

@g-bougard
Copy link
Member

This doesn't sound logic. Can you eventually restart the service or even the computer ?

@redddcyclone
Copy link
Author

redddcyclone commented Nov 16, 2023

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.

@redddcyclone
Copy link
Author

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.

@redddcyclone
Copy link
Author

redddcyclone commented Nov 16, 2023

@g-bougard

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:

[debug] Logger backend Stderr initialized
[debug] Logger backend File initialized
[debug] GLPI Agent (1.6)
[debug] Configuration directory: C:/Program Files/GLPI-Agent/etc
[debug] Data directory: C:/Program Files/GLPI-Agent/share
[debug] Storage directory: C:\Program Files\GLPI-Agent\var
[debug] Lib directory: C:/Program Files/GLPI-Agent/perl/agent
[debug] [target server0] Next server contact planned for Thu Nov 16 11:40:00 2023
[debug2] getAvailableTasks() : add of task Collect version 2.9
[debug2] getAvailableTasks() : add of task Deploy version 3.0
[debug2] getAvailableTasks() : add of task Inventory version 1.14
[debug2] getAvailableTasks() : add of task NetDiscovery version 6.0
[debug2] getAvailableTasks() : add of task NetInventory version 6.0
[debug2] getAvailableTasks() : add of task RemoteInventory version 1.3
[debug] Available tasks:
[debug] - Collect: 2.9
[debug] - Deploy: 3.0
[debug] - Inventory: 1.14
[debug] - NetDiscovery: 6.0
[debug] - NetInventory: 6.0
[debug] - RemoteInventory: 1.3
[debug] target server0: server https://glpi.obfuscated.domain/plugins/glpiinventory/
[debug] Planned tasks for server0: Deploy,Collect,RemoteInventory,Inventory,NetDiscovery,NetInventory
[debug] Provided by Teclib Edition
[debug] Installer built on Wed Nov 15 17:48:00 2023 UTC
[debug] Built with Strawberry Perl 5.36.0
[debug] Built on github actions windows image for glpi-project/glpi-agent repository
[debug] Running in foreground mode
[info] server0 is not ready yet, but run is forced
[info] target server0: server https://glpi.obfuscated.domain/plugins/glpiinventory/
[debug2] [http client] Using Compress::Zlib for compression
[info] sending prolog request to server0
[debug2] [http client] sending message:
<?xml version="1.0" encoding="UTF-8"?>
<REQUEST>
  <DEVICEID>MININT-SPS8LE3-2022-10-05-08-43-19</DEVICEID>
  <QUERY>PROLOG</QUERY>
  <TOKEN>12345678</TOKEN>
</REQUEST>
[debug] [http client] Updating keystore known certificates
[debug2] Changing to 'C:/Program Files/GLPI-Agent/var/keystore-export-P2L83W' temporary folder
[debug2] executing certutil -Silent -Split -Store CA
[debug2] executing certutil -Silent -Split -Store Root
[debug2] executing certutil -Silent -Split -Enterprise -Store CA
[debug2] executing certutil -Silent -Split -Enterprise -Store Root
[debug2] executing certutil -Silent -Split -GroupPolicy -Store CA
[debug2] executing certutil -Silent -Split -GroupPolicy -Store Root
[debug2] executing certutil -Silent -Split -User -Store CA
[debug2] executing certutil -Silent -Split -User -Store Root
[debug2] executing certutil -encode 0119e81be9a14cd8e22f40ac118c687ecba3f4d8.crt temp.cer
[debug2] executing certutil -encode 0563b8630d62d75abbc8ab1e4bdfb5a899b24d43.crt temp.cer
[debug2] executing certutil -encode 06f1aa330b927b753a40e68cdf22e34bcbef3352.crt temp.cer
[debug2] executing certutil -encode 109f1caed645bb78b3ea2b94c0697c740733031c.crt temp.cer
[debug2] executing certutil -encode 112db41ce4c28937dc318c163b36b154db644acd.crt temp.cer
[debug2] executing certutil -encode 18f7c1fcc3090203fd5baa2f861a754976c8dd25.crt temp.cer
[debug2] executing certutil -encode 245c97df7514e7cf2df8be72ae957b9e04741e85.crt temp.cer
[debug2] executing certutil -encode 29639b66ac979470610e6e013a9691c35c24f211.crt temp.cer
[debug2] executing certutil -encode 31f9fc8ba3805986b721ea7295c65b3a44534274.crt temp.cer
[debug2] executing certutil -encode 3b1efd3a66ea28b16697394703a72ca340a05bd5.crt temp.cer
[debug2] executing certutil -encode 4ad7a62337011e636f8becb440a1811c7f4b9390.crt temp.cer
[debug2] executing certutil -encode 5fb7ee0633e259dbad0c4c9ae6d38f1a61c7dc25.crt temp.cer
[debug2] executing certutil -encode 76339a85c1a4fb95952b5f94f09776d586a4ed69.crt temp.cer
[debug2] executing certutil -encode 7f88cd7223f3c813818c994614a89c99fa3b5247.crt temp.cer
[debug2] executing certutil -encode 8f43288ad272f3103b6fb1428485ea3014c0bcfe.crt temp.cer
[debug2] executing certutil -encode 92b46c76e13054e104f230517e6e504d43ab10b5.crt temp.cer
[debug2] executing certutil -encode 9887d6386741bc4758c49ad0b95c0b4205c70b17.crt temp.cer
[debug2] executing certutil -encode a43489159a520f0d93d032ccaf37e7fe20a8b419.crt temp.cer
[debug2] executing certutil -encode be36a4562fb2ee05dbb3d32323adf445084ed656.crt temp.cer
[debug2] executing certutil -encode c2d6c5f694ca778a5a11beef79799cf3ef692a36.crt temp.cer
[debug2] executing certutil -encode c7ed7bf076120309f682577fe7b29a7593e9889c.crt temp.cer
[debug2] executing certutil -encode cdd4eeae6000ac7f40c3802c171e30148030c072.crt temp.cer
[debug2] executing certutil -encode d4ffdb19ba590fffaa34db5f4b568706a2978436.crt temp.cer
[debug2] executing certutil -encode d559a586669b08f46a30a133f8a9ed3d038e2ea8.crt temp.cer
[debug2] executing certutil -encode ddb9d8308375d4ec8ca77648e9ef9c581ece37c4.crt temp.cer
[debug2] executing certutil -encode e1e9f4d6b09018d19c5ac86a734315dde8ceea68.crt temp.cer
[debug2] executing certutil -encode fcce41a26147edef592df176deb457f1c290aad9.crt temp.cer
[debug2] executing certutil -encode fee449ee0e3965a5246f000e87fde2a065fd89d4.crt temp.cer
[debug2] Changing back to 'C:/Program Files/GLPI-Agent' folder
DEBUG: .../IO/Socket/SSL.pm:3020: new ctx 87124192
DEBUG: .../IO/Socket/SSL.pm:705: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:707: socket connected
DEBUG: .../IO/Socket/SSL.pm:730: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:774: using SNI with hostname glpi.obfuscated.domain
DEBUG: .../IO/Socket/SSL.pm:815: request OCSP stapling
DEBUG: .../IO/Socket/SSL.pm:831: set socket to non-blocking to enforce timeout=180
DEBUG: .../IO/Socket/SSL.pm:845: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (OUT), TLS handshake, Client hello (1)
DEBUG: .../IO/Socket/SSL.pm:848: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:858: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:868: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:888: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:845: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Server hello (2)
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8)
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Certificate (11)
DEBUG: .../IO/Socket/SSL.pm:2864: ok=0 [2] /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (OUT), TLS alert, unknown CA (560)
DEBUG: .../IO/Socket/SSL.pm:848: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:851: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:851: local error: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:854: fatal SSL error: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
DEBUG: .../lib/Net/HTTPS.pm:67: ignoring less severe local error 'IO::Socket::IP configuration failed', keep 'SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed'
DEBUG: .../IO/Socket/SSL.pm:3069: free ctx 87124192 open=87124192
DEBUG: .../IO/Socket/SSL.pm:3073: free ctx 87124192 callback
DEBUG: .../IO/Socket/SSL.pm:3080: OK free ctx 87124192
[error] [http client] internal response: 500 Can't connect to glpi.obfuscated.domain:443 (Bad file descriptor), SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
[error] No supported answer from server at https://glpi.obfuscated.domain/plugins/glpiinventory/

For reference, here is the log output when running with an user other than the Local System account (only the SSL part)

DEBUG: .../IO/Socket/SSL.pm:3020: new ctx 87696304
DEBUG: .../IO/Socket/SSL.pm:705: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:707: socket connected
DEBUG: .../IO/Socket/SSL.pm:730: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:774: using SNI with hostname glpi.obfuscated.domain
DEBUG: .../IO/Socket/SSL.pm:815: request OCSP stapling
DEBUG: .../IO/Socket/SSL.pm:831: set socket to non-blocking to enforce timeout=180
DEBUG: .../IO/Socket/SSL.pm:845: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (OUT), TLS handshake, Client hello (1)
DEBUG: .../IO/Socket/SSL.pm:848: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:858: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:868: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:888: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:845: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Server hello (2)
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8)
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Certificate (11)
DEBUG: .../IO/Socket/SSL.pm:2864: ok=1 [1] /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G4
DEBUG: .../IO/Socket/SSL.pm:2864: ok=1 [0] /C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G4/CN=*.obfuscated.domain
DEBUG: .../IO/Socket/SSL.pm:1840: scheme=www cert=103038912
DEBUG: .../IO/Socket/SSL.pm:1850: identity=glpi.obfuscated.domain cn=*.obfuscated.domain alt=2 *.obfuscated.domain 2 obfuscated.domain
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, CERT verify (15)
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Finished (20)
DEBUG: .../IO/Socket/SSL.pm:2911: did not get stapled OCSP response
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1)
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (OUT), TLS handshake, Finished (20)
DEBUG: .../IO/Socket/SSL.pm:848: done Net::SSLeay::connect -> 1
DEBUG: .../IO/Socket/SSL.pm:903: ssl handshake done
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4)
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4)

@g-bougard
Copy link
Member

g-bougard commented Nov 16, 2023

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: DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (OUT), TLS alert, unknown CA (560)

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 ca_cert_dir to an empty folder path to disable keystore certificate extraction ?
And finally, can you try setting ssl-fingerprint to the value reported in log when you use --debug & --no-ssl-check at the same time ?

@g-bougard
Copy link
Member

Can you make another test ? Take the C:\Program Files\GLPI-Agent\perl\vendor\lib\Mozilla\CA\cacert.pem file from your GLPI-Agent v1.5 installation and copy it to the same place after install the GLPI-Agent 1.6 ? Then check if you still have the same problem ?
This file is the CA certificate store perl library is using. If there's no more error with that older file, this may mean something became wrong on your specific certificate.

@Orchal
Copy link

Orchal commented Nov 16, 2023

Hi,

I have the same issue and made the test with the certificate, it does not resolve the problem.
There's no issue so far with the certificate.

It does not work either with --no-ssl-check option.

@redddcyclone
Copy link
Author

@g-bougard

There's another difference too. When it fails, the line that references the CA certificate is different.

DEBUG: .../IO/Socket/SSL.pm:2864: ok=0 [2] /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA

When it succeeds, this line appears as

DEBUG: .../IO/Socket/SSL.pm:2864: ok=1 [1] /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G4

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 ca-cert-dir to an empty directory did nothing.

Setting ssl-fingerprint manually does work.

Also tried using cacert.pem from the directory you mentioned but it didn't work too.

@tomamplius
Copy link

tomamplius commented Nov 16, 2023

I have the same issue

[Thu Nov 16 23:20:03 2023][error] [http client] internal response: 500 Can't connect to xxxxxxxxxxxxxxx:443 (Bad file descriptor), SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

I used let encrypt certificat

This command not work

glpi-agent --logger=stderr --debug --debug --force

with error :

DEBUG: .../IO/Socket/SSL.pm:3020: new ctx 93342304
DEBUG: .../IO/Socket/SSL.pm:705: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:707: socket connected
DEBUG: .../IO/Socket/SSL.pm:730: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:774: using SNI with hostname MonDomaine.com
DEBUG: .../IO/Socket/SSL.pm:815: request OCSP stapling
DEBUG: .../IO/Socket/SSL.pm:831: set socket to non-blocking to enforce timeout=180
DEBUG: .../IO/Socket/SSL.pm:845: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (OUT), TLS handshake, Client hello (1)
DEBUG: .../IO/Socket/SSL.pm:848: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:858: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:868: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:888: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:845: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Server hello (2)
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8)
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (IN), TLS handshake, Certificate (11)
DEBUG: .../IO/Socket/SSL.pm:2864: ok=0 [2] /O=Digital Signature Trust Co./CN=DST Root CA X3/C=US/O=Internet Security Research Group/CN=ISRG Root X1
DEBUG: .../IO/Socket/SSL.pm:3700: * TLSv1.3 (OUT), TLS alert, unknown CA (560)
DEBUG: .../IO/Socket/SSL.pm:848: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:851: SSL connect attempt failed

DEBUG: .../IO/Socket/SSL.pm:851: local error: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:854: fatal SSL error: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
DEBUG: .../lib/Net/HTTPS.pm:67: ignoring less severe local error 'IO::Socket::IP configuration failed', keep 'SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed'
DEBUG: .../IO/Socket/SSL.pm:3069: free ctx 93342304 open=93342304
DEBUG: .../IO/Socket/SSL.pm:3073: free ctx 93342304 callback
DEBUG: .../IO/Socket/SSL.pm:3080: OK free ctx 93342304
[error] [http client] internal response: 500 Can't connect to mondomaine.com:443 (Bad file descriptor), SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
[debug2] [http client] received message:
Can't connect to Mondomaine.com:443 (Bad file descriptor)

Bad file descriptor at C:/Program Files/GLPI-Agent/perl/vendor/lib/LWP/Protocol/http.pm line 50.
[error] [http client] unexpected content, starting with: Can't connect to Mondomain.com:443 (Bad file descriptor)
[error] No supported answer from server at https://mondomaine.com/marketplace/glpiinventory/

This command work

glpi-agent --logger=stderr --debug --debug --force --no-ssl-check

@g-bougard
Copy link
Member

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 https.pm module from the previous LWP::Protocol::https version from there ?
https://fastapi.metacpan.org/source/OALDERS/LWP-Protocol-https-6.10/lib/LWP/Protocol/https.pm
And replace that file into the C:\Program Files\GLPI-Agent\perl\vendor\lib\LWP\Protocol folder ?

Than make a test.

So this seems to be a LWP::Protocol::https regression.

@Orchal
Copy link

Orchal commented Nov 17, 2023

Hi,

I do confirm it works with the downgrade!

@redddcyclone
Copy link
Author

Hi @g-bougard

Yes, it does work with the downgraded module!

@g-bougard
Copy link
Member

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: ca-cert-file = perl/vendor/lib/Mozilla/CA/cacert.pem ?

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.

@Orchal
Copy link

Orchal commented Nov 17, 2023

It does not work on my side unfortunately

@g-bougard
Copy link
Member

g-bougard commented Nov 17, 2023

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.

@g-bougard
Copy link
Member

The release will take some time to be published. But you still can validate the fix by replacing the perl\agent\GLPI\Agent\HTTP\Client.pm file by this one:
https://raw.githubusercontent.com/glpi-project/glpi-agent/232f269b8a5d47ea423d2a6347737f1de4c5d9c6/lib/GLPI/Agent/HTTP/Client.pm

@g-bougard
Copy link
Member

GLPI Agent 1.6.1 fixing this specific issue is now available:
https://github.com/glpi-project/glpi-agent/releases/tag/1.6.1

@redddcyclone
Copy link
Author

Hi @g-bougard

The new release fixed the problem. No other problems detected at the moment.

Thanks a lot!

@yecalo
Copy link

yecalo commented Nov 17, 2023

HI @g-bougard
I receive the following error after upgrading to version 1.6.1:

[Fri Nov 17 12:36:02 2023][info] target server0: next run: Fri Nov 17 13:25:27 2023 - https://xxxx.xxxxxxx.xxx.xx/glpi/
[Fri Nov 17 12:36:15 2023][info] target server0: server https://xxxx.xxxxxxx.xxx.xx/glpi/
[Fri Nov 17 12:36:15 2023][info] sending prolog request to server0
[Fri Nov 17 12:36:17 2023][error] cannot parse C:\Program Files\GLPI-Agent\perl\vendor\lib\Mozilla\CA\cacert.pem as PEM X509 cert: error:25078067:DSO support routines:win32_load:could not load the shared library at C:/Program Files/GLPI-Agent/perl/agent/GLPI/Agent/HTTP/Client.pm line 486 thread 1.
[Fri Nov 17 12:36:17 2023][info] target server0: next run: Fri Nov 17 13:29:07 2023 - https://xxxx.xxxxxxx.xxx.xx/glpi/

Can you tell me what is the cause?
Thanks.

@g-bougard
Copy link
Member

Hi @yecalo
please, try to uninstall and then reinstall cleanly. If you have the same error, open an new issue with more details.

@tomamplius
Copy link

1.6.1 fix the issue for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants