The problem with connecting the agent to the server over HTTPS

[borodulino]

Documentation & bug reporting acknowledgment

Yes, I read it

Describe your problem

Hello. I have a problem with connecting the agent to the server over HTTPS on linux.

glpi-agent version

• 1.6.1

server version

• 10.0.10

glpi-inventory plugin version

• 1.3.1

OS version

• debian 10

The agent version 1.5-1 is installed on a windows PC and everything works well. The agent version 1.6-1 is installed on Linux and the https connection is not established (on other Linix-PCs version 1.5, the result is similar).\
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-dir = /etc/ssl/certs is specified in the glpi-agent configuration file (/etc/glpi-agent/conf.d/00-install.cfg).
PC's in the freeipa-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/](https://glpi.*****.net/plugins/glpiinventory/)

I also tried using the ca-cert-file=/etc/ssl/certs/dae3fa1e.0 option, but it didn't work either.
If you remove the ca-cert-path option and add the ssl-fingerprint option, then everything works fine.

Please help me, what am I doing wrong?

txt-file with glpi-agent log was attached

with_ca-sert-dir.txt
with_ca-sert-file.txt

[g-bougard]

Hi @borodulino

have you tried to put RootCA.crt in /etc/ssl/certs naming it 0eeb4864.0 when using ca-cert-dir = /etc/ssl/certs option ?

Can you confirm /etc/ssl/certs/dae3fa1e.0 is in PEM format ? I guess the answer is yes, but a double-check is necessary there.

Maybe you need to concatenate RootCA.crt and /etc/ssl/certs/dae3fa1e.0 in one file when using ca-cert-file option.

[borodulino]

Hello. I tried to capture each action as clearly and step by step as possible

First of all, I tried to use the option ca-cert-path=/etc/glpi-agent/certs

1. Step 1. I create certificates with the right name based on the manual (https://glpi-agent.readthedocs.io/en/latest/configuration.html#parameter-syntax)
   
2. Step 2. Show that the certificates are in pem format

RootCA

SubCA

3) Step 3 I'm rewriting the configuration file /etc/glpi-agent/conf.d/00-install.cfg

4) Step 4. I restart the agent and get an error

Next, I decided to try the ca-cert-file option

1. Step 1. Creating and verifying a certificate chain
   
2. Step 2 I'm rewriting the configuration file /etc/glpi-agent/conf.d/00-install.cfg
   
3. Step 3. I restart the agent and get an error
   

[g-bougard]

Hi @borodulino

few not really important points but useful:

• when using ca-cert-file, you don't need to rename the certificate, so you can use /etc/glpi-agent/certs/ca-chain.pem for better configuration readability
• when running the agent on the console, you should add another --debug (to have 2). This will enable debug2 level which trigger openssl debugging too.

Then googling on error:1416F086:SSL, it seems this kind of problem can appear if the client and server time are not synchronized. Have you a difference of time between them ?
Another point, are you using a proxy between the client and GLPI server ?

[borodulino]

In this example, I am running an inventory from an agent that is installed directly on the glpi server, so the time is exactly the same. Also, if you go to the web interface, the correct time is displayed in the server log

Corrected the name to "ca-chain.pem"

LOGS

root@lnvsr-glpi-01:/etc/glpi-agent/conf.d# glpi-agent -f
[debug] Logger backend Stderr initialized
[debug] GLPI Agent (1.6.1-1)
[debug] Configuration directory: /etc/glpi-agent
[debug] Data directory: /usr/share/glpi-agent
[debug] Storage directory: /var/lib/glpi-agent
[debug] Lib directory: /usr/share/glpi-agent/lib
[debug] [target server0] Next server contact planned for Wed Dec  6 11:35:40 2023
[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
[debug2] getAvailableTasks() : add of task WakeOnLan version 2.2
[debug2] Preparing execution plan
[debug] Available tasks:
[debug] - Inventory: 1.14
[debug] - NetDiscovery: 6.0
[debug] - NetInventory: 6.0
[debug] - RemoteInventory: 1.3
[debug] - WakeOnLan: 2.2
[debug] target server0: server https://glpi.******.net/plugins/glpiinventory/
[debug] Planned tasks for server0: Inventory,Inventory
[debug] Built by Debian
[debug] Source time: 2023-11-17 15:14
[debug] Running in foreground mode
[info] target server0: server https://glpi.******.net/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>lnvsr-glpi-01-2023-11-21-09-38-30</DEVICEID>
  <QUERY>PROLOG</QUERY>
  <TOKEN>12345678</TOKEN>
</REQUEST>
DEBUG: .../IO/Socket/SSL.pm:2853: new ctx 41908880
DEBUG: .../IO/Socket/SSL.pm:692: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:694: socket connected
DEBUG: .../IO/Socket/SSL.pm:717: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:750: using SNI with hostname glpi.******.net
DEBUG: .../IO/Socket/SSL.pm:785: request OCSP stapling
DEBUG: .../IO/Socket/SSL.pm:806: set socket to non-blocking to enforce timeout=180
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:832: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:842: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:862: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:2707: ok=0 [1] /DC=net/DC=******/CN=******_Root_CA/DC=net/DC=******/CN=ServerGDC2
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:825: SSL connect attempt failed

DEBUG: .../IO/Socket/SSL.pm:825: local error: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:828: fatal SSL error: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
DEBUG: ...erl5/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:2875: free ctx 41908880 open=41908880
DEBUG: .../IO/Socket/SSL.pm:2879: free ctx 41908880 callback
DEBUG: .../IO/Socket/SSL.pm:2886: OK free ctx 41908880
[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/
root@lnvsr-glpi-01:/etc/glpi-agent/conf.d#

[g-bougard]

Well, I don't see anything telling what's really happening behind.

Maybe there's some compatibility problems somewhere.

To diagnostic further the problem, you may investigate using the openssl s_client feature. For example, you can run something like this to check the connection is rejected without CA chain:

echo | openssl s_client -connect <server_ip>:443 -servername glpi.****.net --trace

You should use as <server-ip> the resolved ip from the glpi hostname. You can use nslookup glpi.****.net to get it.

This should give you a Verification error text somewhere.

Then you can use -verifyCAfile option:

echo | openssl s_client -connect <server_ip>:443 -servername glpi.****.net --trace -verifyCAfile /etc/glpi-agent/certs/ca-chain.pem

And if this is not giving a successful connection, this can give you more details to understand what happens.

This will also expose the ssl cipher list the server supports. Maybe the perl client can't support it. So please share the output so we can check it. Can you then also tell what kind of linux you're using and in which version ?

[borodulino]

It's brilliant. Your advice helped me figure it out. It was all about the length of the certificate key of the issuing enterprise server. It turns out that it is only 1024 bits. I issued a certificate directly from the root server with a key length of 2048 and everything worked

[g-bougard]

Nice to hear this test helped you.

Maybe I should investigate to try getting the "verify error" from the agent and report it in the log. I'm not sure I can get it anyway.

[borodulino]

I modeled the situation anew. I added an old certificate to the glpi server. This is what openssl gives out when checking

root@lnvsr-glpi-01:/home/glpi-adm/project/GLPI# echo | openssl s_client --connect 11.11.1.111:443 -servername glpi.<domain>.net -verifyCAfile /etc/glpi-agent/certs/ca-chain.pem
CONNECTED(00000003)
depth=1 DC = net, DC = <domain>, CN = ServerGDC2
verify error:num=67:CA certificate key too weak
verify return:1
depth=2 DC = net, DC = <domain>, CN = <DOMAIN>_Root_CA
verify return:1
depth=1 DC = net, DC = <domain>, CN = ServerGDC2
verify return:1
depth=0 C = RU, ST = MO, O = <organization_name>, CN = glpi.<domain>.net, emailAddress = <name>@<domain>.net
verify return:1
---
Certificate chain
 0 s:C = RU, ST = MO, O = <organization_name>, CN = glpi.<domain>.net, emailAddress = <name>@<domain>.net
   i:DC = net, DC = <domain>, CN = ServerGDC2
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFIjCCBIugAwIBAgITdAACYjMDNxqMUET/RAAGAAJiMzANBgkqhkiG9w0BAQsF
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
H3CH5t+rTH3aCbDaYqs5MZzEiFEy7Y4drPkpXdwMMgEB+/VvzSZdEFjvsEB61CT4
s7vKsR0WOJg5afmryUernMSFXgNPBg==
-----END CERTIFICATE-----
subject=C = RU, ST = MO, O = <organization_name>, CN = glpi.<domain>.net, emailAddress = <name>@<domain>.net

issuer=DC = net, DC = <domain>, CN = ServerGDC2

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1979 bytes and written 399 bytes
Verification error: CA certificate key too weak
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: EB531B2E93E6D17E91B34886AA5A714BC01FA0EF75D2FB69C1582F991FC5D2CE
    Session-ID-ctx:
    Master-Key: DEA8A0EF5D066EC27SG8J63AS5D8H74JH4E98QW9S9S98E4GT4H8Y8E9W7D8F8G14E1W6SD6D9D5R474H98FFSDQ55GT5U
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - bc d7 c3 e0 17 77 7b ad-75 14 0c 4a 36 39 aa bc   .....w{.u..J69..
    0010 - f9 07 2b a0 f6 84 db 22-2d 3d 85 1f 5b de b0 b8   ..+...."-=..[...
    0020 - d9 89 16 69 31 9d c3 1f-07 9a ae c6 42 b2 b0 38   ...i1.......B..8
    0030 - bb 15 93 ec 6b 98 c4 00-da 6b f3 cb e1 98 c1 bc   ....k....k......
    0040 - 66 be 13 6d 93 6b 97 57-3c 01 6a 43 9d b3 bd df   f..m.k.W<.jC....
    0050 - 35 04 84 00 a9 76 e1 d2-87 87 fd 59 c3 3a f5 76   5....v.....Y.:.v
    0060 - 87 72 05 c3 d2 0c 1a 3e-1d 55 bc 5b b8 88 85 47   .r.....>.U.[...G
    0070 - eb 74 d9 53 46 b8 22 a7-01 ea 2a 25 b5 b9 49 81   .t.SF."...*%..I.
    0080 - 22 78 ad e9 21 31 26 2d-ac b3 14 07 ec 74 2d 83   "x..!1&-.....t-.
    0090 - f7 2a 84 de 8a 68 79 ac-ee 81 d6 2d 03 4c 69 1c   .*...hy....-.Li.
    00a0 - 98 84 d9 cc d1 a4 71 0b-6a 9f 19 df 93 bb aa 62   ......q.j......b
    00b0 - 00 a8 91 a5 a6 08 d6 e9-da 02 43 eb a1 f5 db 8a   ..........C.....

    Start Time: 1702017331
    Timeout   : 7200 (sec)
    Verify return code: 67 (CA certificate key too weak)
    Extended master secret: yes
---
DONE