Yes I restarted NetworkManager, I also rebooted my computer but it didn't help.

I followed your advice and encrypted the connection with wpa2. I can connect with wpa_supplicant but now some websites can't be accessed... For example duckduckgo.com and tagesschau.de (biggest german news page) will not load while google and this forum are working fine. Maybe these pages block me for some reason?

Is your time correct, and synced with a NTP server? Secure connections can fail if the time is out of sync.

output of date is:

Di 10. Nov 22:38:17 CET 2020

which is correct, or is there another time set somewhere else?

Output of cat /etc/ntp.conf is:

# Sample /etc/ntp.conf: Configuration file for ntpd.

#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10

#
# NTP server (list one or more) to synchronize with:
#server 0.pool.ntp.org iburst
#server 1.pool.ntp.org iburst
#server 2.pool.ntp.org iburst
#server 3.pool.ntp.org iburst

#
# Full path of a directory where statistics files should be created
#
statsdir /var/lib/ntp/stats

#
# Location of an alternate log file to be used instead of the default system syslog(3) facility
#
logfile /var/log/ntp

#
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /var/lib/ntp/drift

#
# Location of PID file
#
pidfile /var/run/ntpd.pid

#
# Uncomment to use a multicast NTP server on the local subnet:
#multicastclient 224.0.1.1 # listen on default 224.0.1.1
# Set an optional compensation for broadcast packet delay:
#broadcastdelay 0.008

#
# Keys file. If you want to diddle your server at run time, make a
# keys file (mode 640 owned by root:ntp) and define the key number to
# be used for making requests.
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will.
#
#keysdir /etc
#keys /etc/ntp.keys
#trustedkey 65535
#requestkey 65535
#controlkey 65535

#
# Don't serve time or stats to anyone else by default (more secure)
restrict default limited kod nomodify notrap nopeer noquery
restrict -6 default limited kod nomodify notrap nopeer noquery

#
# Use these lines instead if you do want to serve time and stats to
# other machines on the network:
#restrict default limited kod nomodify notrap nopeer
#restrict -6 default limited kod nomodify notrap nopeer

#
# Trust ourselves. :-)
restrict 127.0.0.1
restrict ::1

What I meant was, is your time correct, to the second? If it's not then you can have errors with some https websites, which will refuse to accept your TLS handshake.

Follow the NTP configuration advice at Slackware Docs and set up your system accordingly. It's possible a dying CMOS battery in your laptop is causing the device to lose time.

That solved the problem, thanks

Another issue: when I connect to the network via wpa_supplicant and than run

dhclient wlan0

everthing works fine. If I connect to the network and than run

dhcpcd wlan0

this breaks the system, if I want to do anything I get a message than display 0 can't be accessed or no connection to the xserver is possible. Even my window manger stops working...

Maybe thats related with the problem that NetworkManager can't connect to the network? But as said I changed the file and restarted it so it should not use dhcpcd, or does it use it somewhere else?

I've never heard of anything like this before. dhcpcd shouldn't be able to affect X, your window manager, or the display. I wouldn't even know where to start in diagnosing this... Maybe someone else would have some ideas. However, the simple, cop out answer is to just not use dhcpcd

Look at resolv.conf, especially the permissions. I accidentally set mine to allow root to read it only and IIRC graphical desktops were fine for root but utterly broken for normal users.

I note I was loose with my wording. I resolv.conf so normal users could not read it. X / KDE / XFCE etc got very upset.