search

cockpit-project / cockpit

Cockpit is a web-based graphical interface for servers.
http://www.cockpit-project.org/
GNU Lesser General Public License v2.1
11.23k stars 1.11k forks source link

cockpit-tls gnutls_handshake failed: A TLS fatal alert has been received (with Chromium) #14896

Open OlegBoul opened 3 years ago

OlegBoul commented 3 years ago

cockpit-tls [107658]: cockpit-tls gnutls_handshake failed: A TLS fatal alert has when connecting

allisonkarlitskaya commented 3 years ago

Can you please be more specific about what the problem is here? Is that something in the journal? Are you able to connect anyway?

OlegBoul commented 3 years ago

yes, this message from journalctl -u cockpit

OlegBoul commented 3 years ago

CentOS 8

OlegBoul commented 3 years ago

and now the same text, but another number : cockpit-tls [6846]

OlegBoul commented 3 years ago

I think that is because of web server timeouts when I use cockpit locally in my internal offce this message is rare enough, but when I'm trying use cockpit remotely over VPN this alert almost continuous

allisonkarlitskaya commented 3 years ago

Okay, but what's the problem? Are you unable to connect? Are you able to connect? Is this just noise in the journal that's bothering you?

OlegBoul commented 3 years ago

Yes, today I 'm not able to connect remotely to my office over cockpit at all and ought to get remoute session at office computer to use cockpit

how to increse timeoutes for TLS handshakes?

OlegBoul commented 3 years ago

it seems to be like https://confluence.atlassian.com/bitbucketserverkb/error-gnutls_handshake-failed-a-tls-warning-alert-has-been-received-779171747.html

OlegBoul commented 3 years ago

To increse timeoutes for cockpit TLS handshakes: 1) find cockpit.service (for me - /usr/lib/systemd/system/cockpit.service) 2) make drop-in for its [Service] ExecStart, for example: cat > /etc/systemd/system/cockpit.service.d/CustomExecStart.conf [Service] ExecStart= ExecStart=/usr/libexec/cockpit-tls --idle-timeout 180 3) systemctl reboot

(90 is default for --idle-timeout, first 'ExecStart=' is because of RHEL bug to clear old value - https://bugzilla.redhat.com/show_bug.cgi?id=756787#c9)

But this doesn't solve a problem in daytime with huge Internet traffic:: Nov 14 19:43:40 localhost.localdomain cockpit-tls[4409]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.

There are also in inet recomendations to update policycoreutils-python-utils and python3-policycoreutils with rebuild cockpit afterall. But this ones doesn't work too...

The Question is: HOW to make Cockpit to do TLS handshake over internet in daytime with huge loads? When Internete traffic is stable Cockpit connects pretty well. After making connections Cockpit works well in all cases. The problem is in TLS handshaking only.

martinpitt commented 3 years ago

I'm afraid this is not actionable right now. I really can't see how increasing the default timeout from 60 to180 seconds would change anything in the TLS handshaking -- that should normally work in the order of milliseconds. If a connection attempt takes more than a few seconds or so, then something in your networking/firewall/etc. is broken, or possibly it's some GnuTLS issue.

Perhaps there is something else in the logs that is enlightening. Please try this on the machine that runs cockpit:

sudo systemctl stop cockpit
sudo systemctl start cockpit.socket
sudo journalctl -f

then please try to open http://

:9090 . Describe exactly what happens, what you see, how long it takes, etc. Then please copy&paste everything that the journalctl command printed out.

ghost commented 3 years ago

Hello, I have the same issue. I have tried to connect with Google Chrome. Best regards, Afsin

sudo systemctl stop cockpit
sudo systemctl start cockpit
sudo journalctl -f
-- Logs begin at Wed 2020-12-02 05:39:09 CET. --
Feb 28 12:58:47 systemd[1]: Listening on Socket for Cockpit Web Service https instance factory.
Feb 28 12:58:47 systemd[1]: Listening on Cockpit Web Service Socket.
Feb 28 12:58:47 systemd[1]: Starting Cockpit motd updater service...
Feb 28 12:58:47 systemd[1]: Starting Cockpit Web Service...
Feb 28 12:58:47 systemd[1]: Started Cockpit Web Service.
Feb 28 12:58:47 systemd[1]: cockpit-motd.service: Succeeded.
Feb 28 12:58:47 systemd[1]: Finished Cockpit motd updater service.
Feb 28 12:59:30 cockpit-tls[2106233]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Feb 28 12:59:30 cockpit-tls[2106233]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Feb 28 12:59:30 systemd[1]: Started Cockpit Web Service https instance factory (PID 2106233/UID 119).
Feb 28 12:59:30 systemd[1]: Starting Socket for Cockpit Web Service https instance e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
Feb 28 12:59:30 systemd[1]: Listening on Socket for Cockpit Web Service https instance e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
Feb 28 12:59:30 systemd[1]: Started Cockpit Web Service https instance e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
Feb 28 12:59:30 systemd[1]: cockpit-wsinstance-https-factory@1-2106233-119.service: Succeeded.
Feb 28 12:59:30 cockpit-tls[2106233]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Feb 28 12:59:30 cockpit-tls[2106233]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Feb 28 12:59:30 cockpit-tls[2106233]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Feb 28 12:59:30 cockpit-ws[2106253]: cockpit-ws: Failed to open certificate file /run/cockpit/tls/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855: No such file or directory
ghost commented 3 years ago

May be a Google Chrome related issue. It seems to be faster with Firefox AND with no TLS messages...

martinpitt commented 3 years ago

@iat00: Indeed, I get these messages with Chromium as well. The "handshake failed" is when chromium rejects the self-signed certificate, and the user needs to do the clickery to proceed. Not sure about the "Failed to open certificate" yet (chromium shouldn't send a client-side cert, it doesn't have one), but let's hide this message, it's irrelevant.

baubukas commented 3 years ago

I have same issue. Fresh RHEL 8.3 (224.2), however my setup is a little bit specific - running behind Cloudflare Argo Tunnel (cocpit.conf same as for nginx). I get a little better results when add real FQDN pointing to loopback IPs and configure cloudflared to use FQDN instead of localhost. In this case do not get "gnutls_handshake failed: A TLS fatal alert has been received", but on browser side get "journal -u".

[Edit] Seems that Cloudflare does not proxy wss, so disregard my comment

skitoxe commented 3 years ago

I get the same problem on Fedora 33 server, Linux 5.10.19-200.fc33.x86_64 #1 SMP Fri Feb 26 16:21:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

And i get this in Chrome, Firefox and MS Edge when trying to log in to cockpit using port 9090 on local adress on lan. And i get this all the time now, some update on the system must've made it broken somehow.

From journalctl -u cockpit:

Mar 03 10:49:44 hostname01 systemd[1]: Starting Cockpit Web Service...
Mar 03 10:49:44 hostname01 systemd[1]: Started Cockpit Web Service.
Mar 03 10:49:44 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:49:46 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:49:46 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:49:46 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:49:46 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:49:46 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:49:46 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:49:46 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:49:54 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:49:54 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:49:54 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:50:31 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:50:31 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:50:31 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:50:31 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:50:31 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:50:36 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:50:36 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:50:36 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:50:36 hostname01 cockpit-tls[4293]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar 03 10:52:38 hostname01 systemd[1]: cockpit.service: Succeeded.
Mar 03 10:54:00 hostname01 systemd[1]: Starting Cockpit Web Service...
Mar 03 10:54:00 hostname01 systemd[1]: Started Cockpit Web Service.
Mar 03 10:55:30 hostname01 systemd[1]: cockpit.service: Succeeded.
Mar 03 10:55:40 hostname01 systemd[1]: Starting Cockpit Web Service...
Mar 03 10:55:40 hostname01 systemd[1]: Started Cockpit Web Service.
Mar 03 10:55:40 hostname01 cockpit-tls[4630]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.

A look in messages log gave some more information:

Mar  3 11:02:59 hostname01 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=cockpit-wsinstance-https-factory@4-4729-993 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar  3 11:02:59 hostname01 systemd[1]: Started Cockpit Web Service https instance factory (PID 4729/UID 993).
Mar  3 11:02:59 hostname01 systemd[1]: Starting Socket for Cockpit Web Service https instance e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
Mar  3 11:02:59 hostname01 systemd[1]: Listening on Socket for Cockpit Web Service https instance e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
Mar  3 11:02:59 hostname01 systemd[1]: Started Cockpit Web Service https instance e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
Mar  3 11:02:59 hostname01 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=cockpit-wsinstance-https@e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar  3 11:02:59 hostname01 systemd[1]: cockpit-wsinstance-https-factory@4-4729-993.service: Succeeded.
Mar  3 11:02:59 hostname01 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=cockpit-wsinstance-https-factory@4-4729-993 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar  3 11:02:59 hostname01 cockpit-tls[4729]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar  3 11:02:59 hostname01 cockpit-tls[4729]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar  3 11:02:59 hostname01 cockpit-ws[4854]: cockpit-ws: Failed to open certificate file /run/cockpit/tls/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855: No such file or directory
Mar  3 11:02:59 hostname01 cockpit-tls[4729]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar  3 11:03:19 hostname01 cockpit-ws[4854]: cockpit-ws: Failed to open certificate file /run/cockpit/tls/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855: No such file or directory
Mar  3 11:03:19 hostname01 audit[4865]: USER_AUTH pid=4865 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:cockpit_session_t:s0 msg='op=PAM:authentication grantors=pam_usertype,pam_localuser,pam_unix acct="username01" exe="/usr/libexec/cockpit-session" hostname=::ffff:192.168.1.242 addr=::ffff:192.168.1.242 terminal=? res=success'
Mar  3 11:03:19 hostname01 audit[4865]: USER_ACCT pid=4865 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:cockpit_session_t:s0 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="username01" exe="/usr/libexec/cockpit-session" hostname=::ffff:192.168.1.242 addr=::ffff:192.168.1.242 terminal=? res=success'
Mar  3 11:03:19 hostname01 audit[4865]: CRED_ACQ pid=4865 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:cockpit_session_t:s0 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="username01" exe="/usr/libexec/cockpit-session" hostname=::ffff:192.168.1.242 addr=::ffff:192.168.1.242 terminal=? res=success'
Mar  3 11:03:19 hostname01 audit[4865]: USER_ROLE_CHANGE pid=4865 uid=0 auid=1000 ses=8 subj=system_u:system_r:cockpit_session_t:s0 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe="/usr/libexec/cockpit-session" hostname=::ffff:192.168.1.242 addr=::ffff:192.168.1.242 terminal=? res=success'
Mar  3 11:03:19 hostname01 cockpit-session[4865]: pam_ssh_add: Failed adding some keys
Mar  3 11:03:19 hostname01 systemd-logind[1399]: New session 8 of user username01.
Mar  3 11:03:19 hostname01 systemd[1]: Started Session 8 of user username01.
Mar  3 11:03:19 hostname01 audit[4865]: USER_START pid=4865 uid=0 auid=1000 ses=8 subj=system_u:system_r:cockpit_session_t:s0 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_keyinit,pam_ssh_add,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_lastlog acct="username01" exe="/usr/libexec/cockpit-session" hostname=::ffff:192.168.1.242 addr=::ffff:192.168.1.242 terminal=? res=success'
Mar  3 11:03:19 hostname01 audit[4865]: CRED_REFR pid=4865 uid=0 auid=1000 ses=8 subj=system_u:system_r:cockpit_session_t:s0 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="username01" exe="/usr/libexec/cockpit-session" hostname=::ffff:192.168.1.242 addr=::ffff:192.168.1.242 terminal=? res=success'
Mar  3 11:03:19 hostname01 audit[4890]: USER_AUTH pid=4890 uid=1000 auid=1000 ses=8 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_usertype,pam_localuser,pam_unix acct="username01" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Mar  3 11:03:19 hostname01 audit[4890]: USER_ACCT pid=4890 uid=1000 auid=1000 ses=8 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="username01" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Mar  3 11:03:19 hostname01 audit[4890]: USER_CMD pid=4890 uid=1000 auid=1000 ses=8 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/run/user/1000" cmd=636F636B7069742D627269646765202D2D70726976696C65676564 exe="/usr/bin/sudo" terminal=? res=success'
Mar  3 11:03:19 hostname01 audit[4890]: CRED_REFR pid=4890 uid=1000 auid=1000 ses=8 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Mar  3 11:03:19 hostname01 audit[4890]: USER_START pid=4890 uid=1000 auid=1000 ses=8 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Mar  3 11:03:19 hostname01 cockpit-tls[4729]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar  3 11:03:19 hostname01 cockpit-tls[4729]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar  3 11:03:19 hostname01 cockpit-tls[4729]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar  3 11:03:19 hostname01 cockpit-tls[4729]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
Mar  3 11:03:19 hostname01 journal[4854]: received request from bad Origin: https://192.168.1.188:9090
Mar  3 11:03:19 hostname01 journal[4854]: Received invalid handshake request from the clientMar  3 11:03:33 hostname01 NetworkManager[1353]: <info>  [1614765813.3293] dhcp4 (enp0s20u1u5): option dhcp_lease_time      => '600'

Seems to be perhaps an issue with some missing cert file, perhaps its on my end and its not related to this fault but i havent changed anything so that is wierd in that case.

And this is after a fresh reboot of ther server. All packages up to date on the system.

EDIT: Managed to get it to work again by proxying it over nginx with an ssl cert attatched from lets encrypt. Dont know why the cert got wonky but nevermind now i guess.

martinpitt commented 3 years ago

I'll devote this issue to the gnutls_handshake failed: A TLS fatal alert has been received part. Issue #14704 about the "Failed to open certificate file /run/cockpit/tls" issue.

SomePersonSomeWhereInTheWorld commented 3 years ago

I'm seeing this in Fedora 33

cockpit-bridge-240-1.fc33.x86_64
cockpit-system-240-1.fc33.noarch
cockpit-networkmanager-240-1.fc33.noarch
cockpit-selinux-240-1.fc33.noarch
cockpit-storaged-240-1.fc33.noarch
cockpit-packagekit-240-1.fc33.noarch
cockpit-ws-240-1.fc33.x86_64

5.10.10-200.fc33.x86_64

Mar 29 21:55:47 dsm cockpit-tls[3496641]: cockpit-tls: gnutls_handshake failed: The TLS connection was non-properly terminated.
Mar 29 21:55:47 dsm cockpit-tls[3496641]: cockpit-tls: gnutls_handshake failed: No supported cipher suites have been found.
Mar 29 21:55:47 dsm cockpit-tls[3496641]: cockpit-tls: gnutls_handshake failed: The TLS connection was non-properly terminated.
Mar 29 21:55:47 dsm cockpit-tls[3496641]: cockpit-tls: gnutls_handshake failed: Error in the pull function.
Mar 29 21:55:57 dsm cockpit-tls[3496641]: cockpit-tls: gnutls_handshake failed: Decryption has failed.
Mar 29 21:56:46 dsm cockpit-tls[3496641]: cockpit-tls: gnutls_handshake failed: Error in the pull function.
Mar 29 21:56:46 dsm journal[3496648]: received unsupported HTTP method
Mar 29 21:56:46 dsm journal[3496648]: received HTTP request without Host header
Mar 29 21:56:53 dsm cockpit-tls[3496641]: cockpit-tls: gnutls_handshake failed: Decryption has failed.
Mar 29 21:56:53 dsm cockpit-tls[3496641]: cockpit-tls: gnutls_handshake failed: An error was encountered at the TLS Finished packet calculation.
tgwaste commented 3 years ago

Happens on Ubuntu 20.04 via mobile chrome and safari. Does not happen with desktop chrome or safari.

tgwaste commented 3 years ago

So far I have not been able to login to my cockpit instance on ANY mobile device or browser (ive tried many at this point). It only works on desktop.

Is that to be expected?

RadioactiveSharPei commented 3 years ago

@tgwaste I’m having exactly the same problem on Linux Mint. Getting exactly the same errors using Chrome or Safari on my iPad. journalctl -u cockpit shows the same errors. Is this something to do with the self-signed certificate that cockpit uses?

tgwaste commented 3 years ago

I just ended up putting a real cert on it and it fixed the issue.

Mike-Morrell commented 3 years ago

I have the same issue using fresh install of Fedora Server 33. I can login to Cockpit on LAN, but Cisco Anyconnect VPN login is not working. Same error messages as above. cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. cockpit-tls: gnutls_handshake failed: The TLS connection was non-properly terminated.

Nevermind: Cisco Anyconnect VPN setting was set to block untrusted web sites. Once I unchecked that box, it started working.

SomePersonSomeWhereInTheWorld commented 3 years ago

Our issue is a little but of a "chicken and egg" situation. When Qualys is doing some pen testing the following logs happen:

May 10 21:57:43 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 33554944
May 10 21:57:43 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 16777216
May 10 21:57:43 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1414744096
May 10 21:57:43 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1010792557
May 10 21:57:43 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 83888896
May 10 21:57:51 ourserver kernel: net_ratelimit: 6 callbacks suppressed
May 10 21:57:51 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1509949440
May 10 21:57:51 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1245992784
May 10 21:57:51 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1229866575
May 10 21:57:53 ourserver journal[2290527]: received invalid HTTP request line
May 10 21:57:59 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 305397761
May 10 21:57:59 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1229866575
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: The TLS connection was non-properly terminated.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver systemd[1]: Started Cockpit Web Service https instance factory (PID 399501/UID 297).
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver systemd[1]: Starting Socket for Cockpit Web Service https instance e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver systemd[1]: Listening on Socket for Cockpit Web Service https instance e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver systemd[1]: Started Cockpit Web Service https instance e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver systemd[1]: cockpit-wsinstance-https-factory@259-399501-297.service: Succeeded.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver cockpit-tls[399501]: cockpit-tls: gnutls_handshake failed: A packet with illegal or unsupported version was received.
May 10 21:58:02 ourserver journal[2290527]: Received unexpected TLS connection and no certificate was configured
May 10 21:58:07 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1090519040
May 10 21:58:23 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 469762048
May 10 21:58:31 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1247096314
May 10 21:58:31 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 369295616
May 10 21:58:32 ourserver journal[2290632]: received invalid HTTP request line
May 10 21:58:39 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1224736768
May 10 21:58:39 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1404416
May 10 21:58:39 ourserver kernel: svc: svc_tcp_read_marker nfsd RPC fragment too large: 1986359923
May 10 21:58:54 ourserver systemd[1]: cockpit-wsinstance-http-redirect.service: Succeeded.

Eventually Apache appears to get overwhelmed and we start seeing:

ourserver rtkit-daemon[2034]: Warning: PolicyKit call failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
May 10 23:26:57 ourserver rtkit-daemon[2034]: Warning: PolicyKit call failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
May 10 23:27:12 ourserver systemd[1]: session-70834.scope: Succeeded.
May 10 23:27:22 ourserver rtkit-daemon[2034]: Warning: PolicyKit call failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Not sure if there's a fix for this or perhaps have these logs only in verbose mode?

Protonull commented 3 years ago

Have been having the same problem, and it's related to #13310, but I can also confirm that this is only a problem when using Brave, a Chrome-based browser. I'd imagine you'd get similar problems with Chromium and Opera. When using Brave, the login screen shows up fine, but after logging in, the page turns white, with the following error in the console:

Uncaught ReferenceError: cockpit is not defined
    at Object.<anonymous> (index.js:1)
    at n (index.js:1)
    at Object.<anonymous> (index.js:25)
    at n (index.js:1)
    at Module.<anonymous> (index.js:64)
    at n (index.js:1)
    at Object.<anonymous> (index.js:34)
    at n (index.js:1)
    at index.js:1
    at index.js:1

And the following shows when using journalctl -u cockpit --since -60m:

May 15 20:53:26 protonull-server systemd[1]: Starting Cockpit Web Service...
May 15 20:53:26 protonull-server systemd[1]: Started Cockpit Web Service.
May 15 20:53:26 protonull-server cockpit-tls[177322]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
May 15 20:53:28 protonull-server cockpit-tls[177322]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
May 15 20:53:29 protonull-server cockpit-tls[177322]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
May 15 20:53:29 protonull-server cockpit-tls[177322]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
May 15 20:53:29 protonull-server cockpit-tls[177322]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
May 15 20:53:29 protonull-server cockpit-tls[177322]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
May 15 20:53:33 protonull-server cockpit-tls[177322]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
May 15 20:53:33 protonull-server cockpit-tls[177322]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
May 15 20:53:33 protonull-server cockpit-tls[177322]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.

Additionally, the logins never stick. Refreshing the page causes the login screen to appear again.

cockwell commented 3 years ago

I've been having the same issue as Protonull which began to occur only after a recent cockpit update. Safari and Chrome work fine, only Brave seems to be exhibiting this behaviour.

To resolve this issue, click on the !Not Secure button on the left side of the address field in the browser. This brings up a requester telling you that the certificate is invalid. Click on "Certificate" which gives you the MacOS pop-up allowing you to expand the trust section and "always trust" the cert.

I have no idea how this would work on Linux or Windows with Brave, but I suspect the procedure would be similar.

Edit: So, apparently this only worked once. I'm leaving it here in case it provides someone with a clue or is in some way helpful.

NoahKamara commented 3 years ago

I'm experiencing the same issue on Fedora 33 (Server Edition) and Safari, Firefox, Chrome on macOS 11.X and 12db1 as well as Safari on iPad (iOS 14.X and 15db1)

obsidiangroup commented 3 years ago

We are having the same issue with Rocky Linux, and cockpit. The login page appears, but when you login, the page is blank (Using Chrome).

Logs show: Jun 27 21:00:29 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:00:29 pilauth01 cockpit-ws[3587]: cockpit-ws: Failed to open certificate file /run/cockpit/tls/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855: No such file or directory Jun 27 21:00:29 pilauth01 cockpit-session[10358]: pam_ssh_add: Failed adding some keys Jun 27 21:00:29 pilauth01 systemd[1]: Started /run/user/0 mount wrapper. Jun 27 21:00:29 pilauth01 systemd[1]: Created slice User Slice of UID 0. Jun 27 21:00:29 pilauth01 systemd[1]: Starting User Manager for UID 0... Jun 27 21:00:29 pilauth01 systemd[1]: Started Session 9 of user root. Jun 27 21:00:29 pilauth01 systemd-logind[1197]: New session 9 of user root. Jun 27 21:00:29 pilauth01 systemd[10366]: Reached target Paths. Jun 27 21:00:29 pilauth01 systemd[10366]: Starting D-Bus User Message Bus Socket. Jun 27 21:00:29 pilauth01 systemd[10366]: Reached target Timers. Jun 27 21:00:29 pilauth01 systemd[10366]: Listening on D-Bus User Message Bus Socket. Jun 27 21:00:29 pilauth01 systemd[10366]: Reached target Sockets. Jun 27 21:00:29 pilauth01 systemd[10366]: Reached target Basic System. Jun 27 21:00:29 pilauth01 systemd[10366]: Reached target Default. Jun 27 21:00:29 pilauth01 systemd[10366]: Startup finished in 43ms. Jun 27 21:00:29 pilauth01 systemd[1]: Started User Manager for UID 0. Jun 27 21:00:30 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:00:30 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:00:30 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:00:30 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:00:30 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:00:45 pilauth01 systemd[1]: session-9.scope: Succeeded. Jun 27 21:00:45 pilauth01 systemd-logind[1197]: Session 9 logged out. Waiting for processes to exit. Jun 27 21:00:45 pilauth01 systemd-logind[1197]: Removed session 9. Jun 27 21:00:45 pilauth01 systemd[1]: Stopping User Manager for UID 0...

This is the same for any user on the system. Logs show after a few seconds, the session is logged out and removed. However, attempting to login via Edge, while we still receive errors, you are able to actually use cockpit:

Jun 27 21:04:26 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:04:26 pilauth01 cockpit-ws[3587]: cockpit-ws: Failed to open certificate file /run/cockpit/tls/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855: No such file or directory Jun 27 21:04:26 pilauth01 cockpit-session[10492]: pam_ssh_add: Failed adding some keys Jun 27 21:04:26 pilauth01 systemd[1]: Started /run/user/0 mount wrapper. Jun 27 21:04:26 pilauth01 systemd[1]: Created slice User Slice of UID 0. Jun 27 21:04:26 pilauth01 systemd[1]: Starting User Manager for UID 0... Jun 27 21:04:26 pilauth01 systemd[1]: Started Session 11 of user root. Jun 27 21:04:26 pilauth01 systemd-logind[1197]: New session 11 of user root. Jun 27 21:04:26 pilauth01 systemd[10500]: Reached target Timers. Jun 27 21:04:26 pilauth01 systemd[10500]: Reached target Paths. Jun 27 21:04:26 pilauth01 systemd[10500]: Starting D-Bus User Message Bus Socket. Jun 27 21:04:26 pilauth01 systemd[10500]: Listening on D-Bus User Message Bus Socket. Jun 27 21:04:26 pilauth01 systemd[10500]: Reached target Sockets. Jun 27 21:04:26 pilauth01 systemd[10500]: Reached target Basic System. Jun 27 21:04:26 pilauth01 systemd[10500]: Reached target Default. Jun 27 21:04:26 pilauth01 systemd[10500]: Startup finished in 42ms. Jun 27 21:04:26 pilauth01 systemd[1]: Started User Manager for UID 0. Jun 27 21:04:27 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:04:27 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:04:27 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:04:27 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:04:27 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:04:27 pilauth01 cockpit-tls[3576]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Jun 27 21:04:28 pilauth01 dbus-daemon[1141]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.389' (uid=0 pid=10533 comm="cockpit-bridge " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") Jun 27 21:04:28 pilauth01 systemd[1]: Starting Hostname Service... Jun 27 21:04:28 pilauth01 dbus-daemon[1141]: [system] Successfully activated service 'org.freedesktop.hostname1' Jun 27 21:04:28 pilauth01 systemd[1]: Started Hostname Service.

DevinCharles commented 3 years ago

Came here from my RockyLinux machine with the same issue. I believe it is not cockpit related, but rather Brave (or Chrome) blocking insecure certs, even if you tell it it's okay. I tried first right clicking on the red "Not Secure" marker next to the address bar and allowing "Insecure Content" through "Site Settings," but this did nothing.

However, going to: chrome://flags/#allow-insecure-localhost

shows this was disabled. After enabling, cockpit works fine. This is certainly not a secure workaround, but I believe it points the problem to Brave and not cockpit... though, offering an easier way to have real certs (maybe via letsencrypt?) would be nice...

martinpitt commented 3 years ago

You can install your own certificates: https://cockpit-project.org/guide/latest/https.html#https-certificates

But if the browser asks you to confirm a self-signed certificate for https, and then still refuses it for websocket, that's indeed a browser bug. Possibly in an extension.

MordechaiHadad commented 3 years ago

hello I also have this issue with Debian buster I followed this tutorial to use certbot certificates with cockpit

numpad0 commented 3 years ago

I was just hit by this. Reproduces on Firefox or Edge on normal or private browsing. Tried network.websocket.allowInsecureFromHTTPS = true on about:config and got 403 for wss://172.29.44.80:9090/cockpit/socket instead.

I suppose it's the reality that browsers cannot be expected to accept self signed certificate for WebSockets at this moment, even for RFC1918 addresses, than it being an unintended bug.

kinekt4 commented 3 years ago

Just like to report this also happens when you're behind a proxy (squid in my case). Disabling the proxy on client side, logging into cockpit, then re-enabling the proxy allows you to get on with it. Would also like to note this also happens on other web guis using self signed certs, eg. ClearOS (CentOS clone). So I don't believe this is cockpit specific. But there is a common thread between them. Browser: Opera (Chromium-based)

kolosek commented 2 years ago

I had the same problem. What worked for me:

If you have reverse proxy, then make sure to enable websockets support.

gaetan1903 commented 2 years ago

work for me on reverse proxy nginx and https,

i follow this tutorial https://github-wiki-see.page/m/cockpit-project/cockpit/wiki/Proxying-Cockpit-over-nginx and https://ryan.lovelett.me/posts/letsencrypt-cockpit/

takov751 commented 2 years ago

Greetings,

I just run this and I am curious

curl -k -v https://localhost:9090
*   Trying 127.0.0.1:9090...
* Connected to localhost (127.0.0.1) port 9090 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=US; O=8f2d51c1b8e74f42855be631b1751c5a; CN=podman
*  start date: Jan 12 05:12:47 2022 GMT
*  expire date: Feb 16 16:52:47 2023 GMT
*  issuer: C=US; O=8f2d51c1b8e74f42855be631b1751c5a; OU=ca-583098835464716384; CN=podman
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: localhost:9090
> User-Agent: curl/7.79.1
> Accept: */*
> 
* OpenSSL SSL_read: Connection reset by peer, errno 104
* Closing connection 0
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104

That this line seems to be the most significant ALPN, server did not agree to a protocol

takov751 commented 2 years ago

One more thing i have to mention. In my case I am running cockpit in a unprivileged lxc container on proxmox where I had to make cockpit slightly insecure as the only purpose is to manage podman containers in my case. So I disabled tls with AllowUnencrypted = yes in cockpit.conf and set firewall to only allow podman subnet and local host to connect to port 9090 and added a nginx in podman to add tls. It's a painful workaround, but works.

Kugeleis commented 2 years ago

I migrated my ubuntu server to 22.04 LTS and get this error now. Is there any solution or progress?

garrett commented 2 years ago

@Kugeleis: What browser are you using? Are you using a proxy?

The solutions are listed in this thread; here are two (and there are more above too):

You can install your own certificates: https://cockpit-project.org/guide/latest/https.html#https-certificates

Just like to report this also happens when you're behind a proxy (squid in my case). Disabling the proxy on client side, logging into cockpit, then re-enabling the proxy allows you to get on with it.

Kugeleis commented 2 years ago

I use chromium and Firefox on Linux and windows machines. Cockpit worked flawlessly on Ubuntu server 20.04. Since I access the server from within our LAN only I use AllowUnencrypted in my config. This seems not to work. Certificates are a bit overkill.

tgwaste commented 2 years ago

I just made a simple script to copy the keys in my Dropbox that certbot makes

#!/bin/bash

cp ~/Dropbox/certs/fullchain.pem /etc/cockpit/ws-certs.d/cockpit.cert
cp ~/Dropbox/certs/privkey.pem /etc/cockpit/ws-certs.d/cockpit.key

systemctl restart cockpit

sleep 2

systemctl status cockpit
martinpitt commented 2 years ago

AllowUnencrypted does work in general, we cover this in tests. How does your cockpit.conf look like?

Kugeleis commented 2 years ago

I have only my allowed networks in it and the allow unencrypted directive.

[WebService]  
Origins = http://10.0.0.18 http://192.168.1.0 
AllowUnencrypted = yes
martinpitt commented 2 years ago

@Kugeleis : What doesn't work then? Can you try in a private browser mode? These days, browsers remember a redirection from http to https for a site, so they will still try to contact https even if cockpit doesn't send a redirect any more.

Kugeleis commented 2 years ago

What doesn't work then? I can access the cockpit login page https://myserver.local:9090/. After entering my credentials I get the error page where I should check journalctl -u cockpit. There I find this: cockpit-tls[1228930]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. A private window doesn't help. It's all within a LAN.

martinpitt commented 2 years ago

That means that the websocket connection was refused. Ordinarily this is because of a wrong "Origins", you are missing ws://?

martinpitt commented 2 years ago

Err, wait, you are using https:// -- You need to set "Origins" to "https://.." URLs then. Please see https://github.com/cockpit-project/cockpit/wiki/Proxying-Cockpit-over-NGINX and https://github.com/cockpit-project/cockpit/wiki/Proxying-Cockpit-over-Apache-with-LetsEncrypt

wesmat commented 2 years ago

I get the handshake error with Firefox and Safari but it works with Chrome...

Jul 13 12:44:15 vgi.*****.org cockpit-tls[232665]: cockpit-tls: gnutls_handshake failed: The TLS connection was non-properly terminated.
Jul 13 12:45:39 vgi.*****.org cockpit-tls[232665]: cockpit-tls: gnutls_handshake failed: The TLS connection was non-properly terminated.
Jul 13 12:45:43 vgi.*****.org cockpit-tls[232665]: cockpit-tls: gnutls_handshake failed: The TLS connection was non-properly terminated.
Jul 13 12:45:49 vgi.*****.org cockpit-tls[232665]: cockpit-tls: gnutls_handshake failed: The TLS connection was non-properly terminated.
danstiner commented 2 years ago

Running sudo apt install libgnutls-openssl27 fixed this for me on Ubuntu 20.04.4 LTS. I can now access cockpit via https:// if I accept the self-signed certificate.

Edit: Never mind, it just magically started working at that time, not related to the package. It still fails sometimes, seemingly when the system is under high load.

I see the following in journalctl -u cockpit:

Aug 12 05:06:43 ubuntu-server systemd[1]: Starting Cockpit Web Service...
Aug 12 05:06:43 ubuntu-server cockpit-certificate-ensure[22572]: /usr/lib/cockpit/cockpit-certificate-helper: line 32: sscg: command not found
Aug 12 05:06:43 ubuntu-server cockpit-certificate-ensure[22573]: Generating a RSA private key
Aug 12 05:06:43 ubuntu-server cockpit-certificate-ensure[22573]: .........................+++++
Aug 12 05:06:43 ubuntu-server cockpit-certificate-ensure[22573]: ...............................................+++++
Aug 12 05:06:43 ubuntu-server cockpit-certificate-ensure[22573]: writing new private key to '0-self-signed.key'
Aug 12 05:06:43 ubuntu-server cockpit-certificate-ensure[22573]: -----
Aug 12 05:06:43 ubuntu-server systemd[1]: Started Cockpit Web Service.
Aug 12 05:07:27 ubuntu-server cockpit-tls[22580]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
maravento commented 1 year ago

ubuntu 22.04

nov 28 17:57:18 mst cockpit-certificate-ensure[1425230]: /usr/lib/cockpit/cockpit-certificate-helper: line 32: sscg: command not found
nov 28 17:57:18 mst cockpit-certificate-ensure[1425231]: ..+.........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*............+.+..+.......+......+..............+...+....+++++++++++++++++++>
nov 28 17:57:18 mst cockpit-certificate-ensure[1425231]: ....+...+......+...+..+...+......+.......+...+.........+..+.........+....+......+.........+..++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
nov 28 17:57:18 mst cockpit-certificate-ensure[1425231]: -----
nov 28 17:57:18 mst systemd[1]: Started Cockpit Web Service.
nov 28 17:57:18 mst cockpit-tls[1425238]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
nov 28 17:57:22 mst cockpit-tls[1425238]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.
etc

and this solution doesn't work https://github.com/cockpit-project/cockpit/issues/13668#issuecomment-901719508

I find it strange that this bug has been reported in 2020 and to date has not been fixed.

workaround access: http://localhost:9090 instead of https://localhost:9090

megusta-01 commented 1 year ago

hey guys I found out! The problem is the firewall, someone had already written that they managed it with ngnix. That would be one solution. The other solution I made i deleted all rules on iptables

sudo iptables-save > /root/firewall_rules.backup sudo iptables -F sudo iptables -X sudo iptables -P INPUT ACCEPT sudo iptables -P OUTPUT ACCEPT sudo iptables -P FORWARD ACCEPT

now you just have to get the rules right and hopefully it works