search

warmcat / libwebsockets

canonical libwebsockets.org networking library
https://libwebsockets.org
Other
4.75k stars 1.48k forks source link

the client work properly in ubuntu system,but do not work properly in linux embedded system #2984

Closed maskdom closed 11 months ago

maskdom commented 1 year ago

the libwebsocket version is v4.0stable the openssl version is v1.1stable the server accepts selfsigned certificate the context options of ssl_connection is LCCSCF_USE_SSL| LCCSCF_ALLOW_SELFSIGNED|LCCSCF_ALLOW_INSECURE info.options = LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT; info.port = CONTEXT_PORT_NO_LISTEN; / we do not run any server / info.protocols = protocols; info.fd_limit_per_thread = 1 + 1 + 1; lws_set_log_level(LLL_ERR | LLL_WARN | LLL_DEBUG | LLL_PARSER, NULL); in the ubuntu system ,i do not config the ca root certificate and the client connect the server properly. however,in the embedded system it does not work properly. in the beginning,the client showed certificate signature failure the picture showed the err

then i found the catificate for the server by ssllabs.com and i downloaded the catificate ISRG_ROOT_X1.pem and copyed it to the embedded system and configed the client_ssl_ca_filepath after configed the client_ssl_ca_filepath ,a new error showed up in the embedded system, the error is http bed request ,the response not 101 can not upgrade to websocket. i was confused ,and i don't konw how to config the client. could you please help me to find what the problem is ? thanks a lot. this picture shows the error in the embedded system ,after the HANDSHAKE2 the error occurs f43a95d5fc48f4784c47d80ee421424 this picture shows in the ubutu system the client work properly 1ec0786c76cd9c1b19d940881aa0abf

lws-team commented 1 year ago

I'm not sure what you think the pictures are showing, but the embedded log does not show any error, it ends too early.

There's a good trick for debugging inside TLS, build lws with cmake options -DLWS_TLS_LOG_PLAINTEXT_RX=1 and -DLWS_TLS_LOG_PLAINTEXT_TX=1. This will show the contents of all packets received, after tls decryption, and sent, just before tls encryption.

maskdom commented 1 year ago

I'm not sure what you think the pictures are showing, but the embedded log does not show any error, it ends too early.

There's a good trick for debugging inside TLS, build lws with cmake options -DLWS_TLS_LOG_PLAINTEXT_RX=1 and -DLWS_TLS_LOG_PLAINTEXT_TX=1. This will show the contents of all packets received, after tls decryption, and sent, just before tls encryption.

thanks for your reply. in the ubuntu system, even though i did not config the catificate why the client worked properly in the ubuntu system even though i did not config the catificate? and i am not sure if the catificate is correct or not . and i will upload other pictures later

lws-team commented 1 year ago

Basic Ubuntu is a whole OS. It already includes ca-certificates or similar package containing trusted CA certs, usually managed by mozilla, and installs them where the ubuntu-built openssl knows to look for them. So it will 'just work'.

Embedded OS only has whatever you put in it.

maskdom commented 1 year ago

maybe i have got a mismached catificate. I compiled the example project minimal-ws-client and configed the same catificate and the same serverip port path . In the embedded system the catificate error happend again.the logs are: ./lws-minimal-ws-client -k -j [2023/10/19 10:39:08:9993] U: LWS minimal ws client [2023/10/19 10:39:09:0060] I: Initial logging level 47 [2023/10/19 10:39:09:0064] I: Libwebsockets version: 4.0.22 unknown-build-hash [2023/10/19 10:39:09:0087] I: IPV6 not compiled in [2023/10/19 10:39:09:0089] I: LWS_DEF_HEADER_LEN : 4096 [2023/10/19 10:39:09:0090] I: LWS_MAX_SMP : 1 [2023/10/19 10:39:09:0091] I: sizeof (*info) : 392 [2023/10/19 10:39:09:0092] I: SYSTEM_RANDOM_FILEPATH: '/dev/urandom' [2023/10/19 10:39:09:0093] I: HTTP2 support : available [2023/10/19 10:39:09:0096] I: context created [2023/10/19 10:39:09:0098] I: Using event loop: poll [2023/10/19 10:39:09:0100] I: Default ALPN advertisment: h2,http/1.1 [2023/10/19 10:39:09:0101] I: default timeout (secs): 20 [2023/10/19 10:39:09:0103] I: Threads: 1 each 5 fds [2023/10/19 10:39:09:0105] I: mem: context: 4928 B (832 ctx + (1 thr x 4096)) [2023/10/19 10:39:09:0121] I: mem: http hdr size: (4096 + 952), max count 5 [2023/10/19 10:39:09:0124] I: mem: pollfd map: 40 B [2023/10/19 10:39:09:0126] I: mem: platform fd map: 20 B [2023/10/19 10:39:09:0130] I: Compiled with OpenSSL support [2023/10/19 10:39:09:0132] I: Doing SSL library init [2023/10/19 10:39:09:0439] I: canonical_hostname = DCA210 [2023/10/19 10:39:09:0494] I: Creating Vhost 'default' (serving disabled), 1 protocols, IPv6 off [2023/10/19 10:39:09:0517] I: lws_tls_client_create_vhost_context: vh default: created new client ctx 0 [2023/10/19 10:39:09:0591] I: loaded ssl_ca_filepath [2023/10/19 10:39:09:0607] I: created client ssl context for default [2023/10/19 10:39:09:0615] I: mem: per-conn: 496 bytes + protocol rx buf [2023/10/19 10:39:09:0617] I: lws_plat_drop_app_privileges: not changing group [2023/10/19 10:39:09:0619] I: lws_plat_drop_app_privileges: not changing user [2023/10/19 10:39:09:0620] I: lws_cancel_service [2023/10/19 10:39:09:0622] I: lws_state_notify_protocol_init: doing protocol init on POLICY_VALID [2023/10/19 10:39:09:0665] I: lws_protocol_init [2023/10/19 10:39:09:0668] I: lws_state_transition_steps: CONTEXT_CREATED -> OPERATIONAL [2023/10/19 10:39:09:0671] I: lws_client_connect_via_info: role binding to h1 [2023/10/19 10:39:09:0672] I: lws_client_connect_via_info: protocol binding to ocpp1.6 [2023/10/19 10:39:09:0674] I: lws_client_connect_via_info: wsi 0x27038: h1 ocpp1.6 entry [2023/10/19 10:39:09:0676] I: lws_header_table_attach: wsi 0x27038: ah (nil) (tsi 0, count = 0) in [2023/10/19 10:39:09:0679] I: _lws_create_ah: created ah 0x28340 (size 4096): pool length 1 [2023/10/19 10:39:09:0683] I: lws_header_table_attach: did attach wsi 0x27038: ah 0x28340: count 1 (on exit) [2023/10/19 10:39:09:0686] I: lws_client_connect_2_dnsreq: 0x27038: lookup gonansenhomolog.com.br:443 [2023/10/19 10:39:09:1616] I: lws_getaddrinfo46: getaddrinfo 'gonansenhomolog.com.br' says 0 [2023/10/19 10:39:09:1623] I: lws_client_connect_3_connect: gonansenhomolog.com.br ipv4 52.86.226.218 [2023/10/19 10:39:09:3816] I: lws_client_connect_3_connect: getsockopt check: conn OK [2023/10/19 10:39:09:3817] I: lws_client_connect_3_connect: Connection started 0x2a128 [2023/10/19 10:39:09:3818] I: lws_client_connect_4_established: wsi 0x27038: h1 ocpp1.6 client created own conn (raw 0) vh defaultm st 0x202 [2023/10/19 10:39:09:3826] I: h1 client conn using alpn list 'http/1.1' [2023/10/19 10:39:09:6307] E: SSL error: certificate signature failure (preverify_ok=0;err=7;depth=1) [2023/10/19 10:39:09:6348] I: closing conn at LWS_CONNMODE...SERVER_REPLY [2023/10/19 10:39:09:6351] I: reason: client connect failed [2023/10/19 10:39:09:6352] E: CLIENT_CONNECTION_ERROR: client connect failed Does the catificate match？or anything else i should config in the sample project ?

I download the catificates by chrome when i visited the website,but they catificates sames do not matched ,the error happened again, unable to get issuer certificate or certificate signature failure

lws-team commented 1 year ago

Why don't you carefully review what I already wrote?

maskdom commented 1 year ago

Why don't you carefully review what I already wrote?

DLWS_TLS_LOG_PLAINTEXT_RX=1 I set this option but nothing changed

lws-team commented 1 year ago

v4.0stable -DLWS_TLS_LOG_PLAINTEXT_RX=1

v4.3-stable (current stable) has it.

maskdom commented 1 year ago

v4.0stable -DLWS_TLS_LOG_PLAINTEXT_RX=1

v4.3-stable (current stable) has it.

Thank you so much , i will do it and come back later .

maskdom commented 1 year ago

v4.0stable -DLWS_TLS_LOG_PLAINTEXT_RX=1

v4.3-stable (current stable) has it.

Thank you so much , i will do it and come back later .

[2023/10/19 14:02:05:7599] I: lws_tls_restrict_borrow: 0 -> 1 [2023/10/19 14:02:05:7599] N: lws_gate_accepts: on = 0 [2023/10/19 14:02:05:7603] I: lws_tls_reuse_session: no existing session for default_gonansenhomolog.com.br_443 [2023/10/19 14:02:05:7606] I: h1 client conn using alpn list 'http/1.1' [2023/10/19 14:02:06:0742] E: SSL error: certificate signature failure (preverify_ok=0;err=7;depth=1) [2023/10/19 14:02:06:0756] I: openssl error: error:04091077:rsa routines:int_rsa_verify:wrong signature length [2023/10/19 14:02:06:0769] I: openssl error: error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib [2023/10/19 14:02:06:0773] I: openssl error: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed [2023/10/19 14:02:06:0804] I: [2023/10/19 14:02:06:0808] I: lws_tls_restrict_return_handshake: 1 -> 0 [2023/10/19 14:02:06:0810] N: lws_gate_accepts: on = 0 [2023/10/19 14:02:06:0834] I: lws_tls_client_confirm_peer_cert: cert problem: [2023/10/19 14:02:06:0836] I: server's cert didn't look good, X509_V_ERR = 7: error:00000007:lib(0):func(0):passed invalid argument

[2023/10/19 14:02:06:0838] I: [2023/10/19 14:02:06:0839] I: lws_http_client_socket_service: closing conn at LWS_CONNMODE...SERVER_REPLY, [wsicli|0|WS/h1/default/gonansenhomolog.com.br], state 0x204 [2023/10/19 14:02:06:0840] I: reason: server's cert didn't look good, X509_V_ERR = 7: error:00000007:lib(0):func(0):passed invalid argument

[2023/10/19 14:02:06:0841] E: CLIENT_CONNECTION_ERROR: server's cert didn't look good, X509_V_ERR = 7: error:00000007:lib(0):func(0):passed invalid argument

[2023/10/19 14:02:06:0843] I: [wsicli|0|WS/h1/default/gonansenhomolog.com.br]: lws_close_free_wsi: caller: cbail3 [2023/10/19 14:02:06:0848] I: [wsicli|0|WS/h1/default/gonansenhomolog.com.br]: __lws_close_free_wsi: real just_kill_connection: sockfd 6 [2023/10/19 14:02:06:0849] I: [wsicli|0|WS/h1/default/gonansenhomolog.com.br]: lws_close_free_wsi: cce=0 [2023/10/19 14:02:06:0861] I: lws_tls_restrict_return: 1 -> 0 [2023/10/19 14:02:06:0866] N: lws_gate_accepts: on = 0

Thanks again,errors show Server's cert??where should i get it?

lws-team commented 1 year ago

... are you sure that when you built the new lws, iit was a clean build with new cmake from scratch? And, eg, not building against build host openssl or lws includes instead of the cross-openssl includes?

maskdom commented 1 year ago

... are you sure that when you built the new lws, iit was a clean build with new cmake from scratch? And, eg, not building against build host openssl or lws includes instead of the cross-openssl includes?

Thanks for your replay ,I compiled lws with cross-openssl includes and host openssl twice and get two so ,replaced the so to check but the logs are the same. Now the logs show cert error wrong signature length ,how to fix it？

lws-team commented 1 year ago

Dunno. I can establish a tunnel to that server fine here, on Fedora 39, using main branch lws but 4.3-stable should be the same.

green@laptop:~/projects/libwebsockets/build$ ./bin/lws-minimal-http-client --server gonansenhomolog.com.br 
[2023/10/19 08:20:55:8428] U: LWS minimal http client [-d<verbosity>] [-l] [--h1]
[2023/10/19 08:20:55:8429] N: lws_create_context: LWS: 4.3.99-v4.3.0-282-gd6ca39cb41, NET CLI SRV H1 H2 WS SS-JSON-POL ConMon IPV6-on
[2023/10/19 08:20:55:8430] N: __lws_lc_tag:  ++ [wsi|0|pipe] (1)
[2023/10/19 08:20:55:8430] N: __lws_lc_tag:  ++ [vh|0|netlink] (1)
[2023/10/19 08:20:55:8441] N: __lws_lc_tag:  ++ [vh|1|default||-1] (2)
[2023/10/19 08:20:55:8629] N: lws_cache_nscookiejar_create: create NSC
[2023/10/19 08:20:55:9631] N: __lws_lc_tag:  ++ [wsicli|0|GET/h1/default/gonansenhomolog.com.br] (1)
[2023/10/19 08:20:55:9944] N: [wsicli|0|GET/h1/default/gonansenhomolog.com.br]: lws_client_connect_3_connect: trying 52.86.226.218
[2023/10/19 08:20:56:2805] N: __lws_lc_tag:  ++ [mux|0|default|h2_sid1_(wsicli|0|GET/h1/default/gonansenhomolo] (1)
[2023/10/19 08:20:56:3791] U: Connected to 52.86.226.218, http response: 200
[2023/10/19 08:20:56:3792] U: RECEIVE_CLIENT_HTTP_READ: read 3734
[2023/10/19 08:20:56:3792] U: RECEIVE_CLIENT_HTTP_READ: read 175
[2023/10/19 08:20:56:3792] U: LWS_CALLBACK_COMPLETED_CLIENT_HTTP
[2023/10/19 08:20:56:3793] N: __lws_lc_untag:  -- [wsi|0|pipe] (0) 536.290ms
[2023/10/19 08:20:56:3793] N: __lws_lc_untag:  -- [mux|0|default|h2_sid1_(wsicli|0|GET/h1/default/gonansenhomolo] (0) 98.773ms
[2023/10/19 08:20:56:3807] N: __lws_lc_untag:  -- [vh|1|default||-1] (1) 536.579ms
[2023/10/19 08:20:56:3807] N: __lws_lc_untag:  -- [wsicli|0|GET/h1/default/gonansenhomolog.com.br] (0) 417.640ms
[2023/10/19 08:20:56:3807] N: __lws_lc_untag:  -- [vh|0|netlink] (0) 537.742ms
[2023/10/19 08:20:56:3808] U: Completed: OK (seen expected 0)
maskdom commented 1 year ago

... are you sure that when you built the new lws, iit was a clean build with new cmake from scratch? And, eg, not building against build host openssl or lws includes instead of the cross-openssl includes?

Thanks for your replay ,I compiled lws with cross-openssl includes and host openssl twice and get two so ,replaced the so to check but the logs are the same. Now the logs show cert error wrong signature length ,how to fix it？ Here is the new logs [2023/10/19 14:43:13:9023] I: rops_handle_POLLIN_netlink: unknown attr type 20 [2023/10/19 14:43:13:9025] I: rops_handle_POLLIN_netlink: NEWROUTE rtm_type 7 [2023/10/19 14:43:13:9026] I: _lws_routing_table_dump: [2023/10/19 14:43:13:9027] I: _lws_routing_entry_dump: gw: 192.168.1.1, ifidx: 4, pri: -1, proto: 3 [2023/10/19 14:43:13:9028] I: _lws_routing_entry_dump: dst: 192.168.1.230/32, src: 192.168.1.230/0, ifidx: 4, pri: -1, proto: 2 [2023/10/19 14:43:13:9030] I: _lws_routing_entry_dump: dst: (ipv6 unsupp)/128, src: (ipv6 unsupp)/0, ifidx: 1, pri: 0, proto: 0 [2023/10/19 14:43:13:9054] I: _lws_routing_entry_dump: dst: (ipv6 unsupp)/8, ifidx: 4, pri: 256, proto: 3 [2023/10/19 14:43:13:9074] I: _lws_smd_msg_deliver_peer: deliver cl 0x4, len 13, refc 1, to peer 0x61028 [2023/10/19 14:43:13:9076] I: _lws_smd_msg_destroy: destroy msg 0x7bb88 [2023/10/19 14:43:13:9077] I: _lws_smd_msg_deliver_peer: deliver cl 0x4, len 13, refc 1, to peer 0x61028 [2023/10/19 14:43:13:9081] I: _lws_smd_msg_destroy: destroy msg 0x7bbc0 [2023/10/19 14:43:13:9083] I: _lws_smd_msg_deliver_peer: deliver cl 0x4, len 13, refc 1, to peer 0x61028 [2023/10/19 14:43:13:9089] I: _lws_smd_msg_destroy: destroy msg 0x76f60 [2023/10/19 14:43:13:9093] I: rops_handle_POLLIN_netlink: RTM 3 [2023/10/19 14:43:13:9106] I: rops_handle_POLLIN_netlink: *** Unknown RTM_3 [2023/10/19 14:43:14:0107] I: lws_state_transition_steps: INITIALIZED -> OPERATIONAL [2023/10/19 14:43:14:1197] I: [wsicli|0|WS/h1/default/gonansenhomolog.com.br]: lws_client_connect_3_connect: source ads 192.168.1.230 [2023/10/19 14:43:14:1199] I: [wsicli|0|WS/h1/default/gonansenhomolog.com.br]: lws_client_connect_4_established: h1 ocpp1.6 client created own conn (raw 0) vh default st 0x202 [2023/10/19 14:43:14:1200] I: lws_tls_restrict_borrow: 0 -> 1 [2023/10/19 14:43:14:1200] N: lws_gate_accepts: on = 0 [2023/10/19 14:43:14:1205] I: lws_tls_reuse_session: no existing session for default_gonansenhomolog.com.br_443 [2023/10/19 14:43:14:1208] I: h1 client conn using alpn list 'http/1.1' [2023/10/19 14:43:14:4012] E: SSL error: certificate signature failure (preverify_ok=0;err=7;depth=1) [2023/10/19 14:43:14:4051] I: openssl error: error:04091077:rsa routines:int_rsa_verify:wrong signature length [2023/10/19 14:43:14:4082] I: openssl error: error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib [2023/10/19 14:43:14:4086] I: openssl error: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed [2023/10/19 14:43:14:4088] I:

maskdom commented 1 year ago

Dunno. I can establish a tunnel to that server fine here, on Fedora 39, using main branch lws but 4.3-stable should be the same.

green@laptop:~/projects/libwebsockets/build$ ./bin/lws-minimal-http-client --server gonansenhomolog.com.br 
[2023/10/19 08:20:55:8428] U: LWS minimal http client [-d<verbosity>] [-l] [--h1]
[2023/10/19 08:20:55:8429] N: lws_create_context: LWS: 4.3.99-v4.3.0-282-gd6ca39cb41, NET CLI SRV H1 H2 WS SS-JSON-POL ConMon IPV6-on
[2023/10/19 08:20:55:8430] N: __lws_lc_tag:  ++ [wsi|0|pipe] (1)
[2023/10/19 08:20:55:8430] N: __lws_lc_tag:  ++ [vh|0|netlink] (1)
[2023/10/19 08:20:55:8441] N: __lws_lc_tag:  ++ [vh|1|default||-1] (2)
[2023/10/19 08:20:55:8629] N: lws_cache_nscookiejar_create: create NSC
[2023/10/19 08:20:55:9631] N: __lws_lc_tag:  ++ [wsicli|0|GET/h1/default/gonansenhomolog.com.br] (1)
[2023/10/19 08:20:55:9944] N: [wsicli|0|GET/h1/default/gonansenhomolog.com.br]: lws_client_connect_3_connect: trying 52.86.226.218
[2023/10/19 08:20:56:2805] N: __lws_lc_tag:  ++ [mux|0|default|h2_sid1_(wsicli|0|GET/h1/default/gonansenhomolo] (1)
[2023/10/19 08:20:56:3791] U: Connected to 52.86.226.218, http response: 200
[2023/10/19 08:20:56:3792] U: RECEIVE_CLIENT_HTTP_READ: read 3734
[2023/10/19 08:20:56:3792] U: RECEIVE_CLIENT_HTTP_READ: read 175
[2023/10/19 08:20:56:3792] U: LWS_CALLBACK_COMPLETED_CLIENT_HTTP
[2023/10/19 08:20:56:3793] N: __lws_lc_untag:  -- [wsi|0|pipe] (0) 536.290ms
[2023/10/19 08:20:56:3793] N: __lws_lc_untag:  -- [mux|0|default|h2_sid1_(wsicli|0|GET/h1/default/gonansenhomolo] (0) 98.773ms
[2023/10/19 08:20:56:3807] N: __lws_lc_untag:  -- [vh|1|default||-1] (1) 536.579ms
[2023/10/19 08:20:56:3807] N: __lws_lc_untag:  -- [wsicli|0|GET/h1/default/gonansenhomolog.com.br] (0) 417.640ms
[2023/10/19 08:20:56:3807] N: __lws_lc_untag:  -- [vh|0|netlink] (0) 537.742ms
[2023/10/19 08:20:56:3808] U: Completed: OK (seen expected 0)

Yes i can connect it on ubuntu system too but in the embedded system i can not I can't find out the cert ,i have tryed ssllabs.com and visit website by chrome to download certs but none of the certs i got wroks good

lws-team commented 1 year ago

... that problem only exists in front of yourself and you'll have to debug it I'm afraid. I'd start by checking the CA file on the embedded filesystem still contains what you originally downloaded for X1, use tcpdump -s0 -X to watch the certificates coming back from the server etc.

maskdom commented 1 year ago

... that problem only exists in front of yourself and you'll have to debug it I'm afraid. I'd start by checking the CA file on the embedded filesystem still contains what you originally downloaded for X1, use tcpdump -s0 -X to watch the certificates coming back from the server etc.

Thank you so much. I'd like to confirm this issue to you When i config the ssl cat file info.client_ssl_ca_mem=ca_cert; info.client_ssl_cert_mem_len=sizeof(ca_cert) Or info.client_ssl_ca_filepath = "/etc/ssl/certs/ISRG_Root_X1.pem"; Is either of these ways ok?

lws-team commented 1 year ago

AFAIK... at one point the mem cert had to end with an extra 0x00 byte (the length had to include it) but on main it's no longer needed.

maskdom commented 1 year ago

I tryed to copy every catificate of ubuntu to the embedded system and tryed to connect the server in embedded system using the catificates but almost all of the certificates showed the error: wrong signature length. When this error happens？the client checks the signature its self？or the server checks it and returns the error message？ I found this log message in the ubuntu system lws_openssl_describe_cipher: [wsicli|0|WS/h1/default/gonansenhomolog.com.br]: TLS_AES_256_GCM_SHA384, TLS_AES_256_GCM_SHA384, 256 bits, TLSv1.3 The logs might show some messages for selfsigned catificate so i made a self signed catificate using ssl tools but using the certificate i made ,the error happend again. Could you please give me some advice for that?

lws-team commented 1 year ago

I tryed to copy every catificate of ubuntu to the embedded system

There's no point doing that... if you study the ssllabs results you just need to trust the end CA cert on a valid chain, which is ISRG Root X1. The server will send the intermediate and server cert to complete the chain.

At the moment, your server is sending ISRG Root X1 but this is meaningless to be sent by the server: the client must have it itself for it to be 'trusted'. You shouldn't send it from the server.

https://www.ssllabs.com/ssltest/analyze.html?d=gonansenhomolog.com.br&s=44.205.97.5&hideResults=on&latest

If you look at the various ways it can form a chain, ssllabs does indicate itself some of these are invalid.

Path #1:  Trusted
--
1 | Sent by server | gonansenhomolog.com.br                                                                                                     Fingerprint SHA256:  32ac2f11a72f9c2a3017667d82528d00e4b76f752a6f7f2c642444db800670e3                             Pin SHA256: 3pFTz+Ku5C0VkYMRFLmHJHMNxwaaMh933PGWoqUdpXY=                                                              RSA 2048 bits                  (e 65537)                        /                                   SHA256withRSA
2 | Sent by server | R3                                                                                                     Fingerprint SHA256:  67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd                             Pin SHA256: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=                                                              RSA 2048 bits                  (e 65537)                        /                                   SHA256withRSA
3 | In trust store | ISRG Root X1                                                                  Self-signed                                  Fingerprint SHA256:  96bcec06264976f37460779acf28c5a7cfe8a3c0aae11a8ffcee05c0bddf08c6                             Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=                                                              RSA 4096 bits                  (e 65537)                        /                       SHA256withRSA

Path #2:  Not trusted (path does not chain to a trusted anchor)
1 | Sent by server | gonansenhomolog.com.br                                                                                                     Fingerprint SHA256:  32ac2f11a72f9c2a3017667d82528d00e4b76f752a6f7f2c642444db800670e3                             Pin SHA256: 3pFTz+Ku5C0VkYMRFLmHJHMNxwaaMh933PGWoqUdpXY=                                                              RSA 2048 bits                  (e 65537)                        /                                   SHA256withRSA
2 | Sent by server | R3                                                                                                     Fingerprint SHA256:  67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd                             Pin SHA256: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=                                                              RSA 2048 bits                  (e 65537)                        /                                   SHA256withRSA
3 | Sent by server | ISRG Root X1                                                                                                   Fingerprint SHA256:  6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f                             Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=                                                              RSA 4096 bits                  (e 65537)                        /                                   SHA256withRSA
4 | Extra download                                 Not in trust store | DST Root CA X3                                                                 Self-signed                                  Fingerprint SHA256:  0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739                             Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=                                                              RSA 2048 bits                  (e 65537)                        /                       SHA1withRSA                                     Valid until: Thu, 30 Sep 2021 14:01:15 UTC                                                          EXPIRED                                                                         Weak or insecure signature, but no impact on root certificate

When this error happens？the client checks the signature its self？or the server checks it and returns the error message？

This is your client openssl asking for and then trying to interpret "a certificate" from the server, I think from "depth=1" in the error it's the server's intermediate cert it chokes on.

Assuming you control the server I would remove the certs from it except gonansenhomolog.com.br and R3 and see if that helps.

lws-team commented 12 months ago

There's a patch on v4.3-stable you might want to pull thismorning about improving openssl errors on client connect.

maskdom commented 12 months ago

There's a patch on v4.3-stable you might want to pull thismorning about improving openssl errors on client connect.

Thank you so much and i will have a try ,by the way i just find in the ubuntu system the same error happens when i config ssl_connection without LCCSCF_ALLOW_INSECURE

maskdom commented 12 months ago

There's a patch on v4.3-stable you might want to pull thismorning about improving openssl errors on client connect.

I have tryed,the error still happens .

lws-team commented 12 months ago

Hm... if you look at what I wrote above

https://github.com/warmcat/libwebsockets/issues/2984#issuecomment-1770213060

I show using the unchanged main branch lws-minimal-http-client example on Fedora 39 to connect to that server just fine - all the example code checks the cert validity properly by default. And I can still do that today just fine. I would imagine v4.3-stable is no different.

Let's Encrypt had various problems a couple of years ago when their main CA cert "DST Root CA X3" expired, they "fixed it" by adding a second intermediary signed by another non-expired CA. I can see by ssllabs the cert on the server has this problem, although I don't know if the server cert came from LE. The two validation paths use different intermediates then

                  / Intermediate A (signed by ISRG Root X1) -- ISRG Root X1 (trusted on client)
server cert  ---<
                  \ Intermediate B (signed by old DST Root CA X3) -- DST Root CA X3 (expired but trusted on some clients)

https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

In this case, you have to take care to provide both intermediates along with the server cert. Go back to the bundle you got from the issuer and make sure you send everything (except the final CAs which the client has to already have and trust).

Even so, some openssl failed the validation because they liked the X3 path, which is valid except for the X3 CA has expired and failed out (ie, you might need recent OpenSSL). I had to remove trust on the client for DST Root CA X3 to make some systems work. Some systems (eg, old android) only trusted DST Root CA X3 and did not know about ISRG Root X1, and were willing to overlook the expiry of the CA cert itself, which is why they did this.

You might want to explicitly remove trust on the client for DST Root CA X3 and see if that helps. You can google around about LE CA expiry and find various cries of pain and solutions shared.