search for: negoiating

I have a new pcap from beginning to the end with openldap "TLS negoiation failed" https://gwarband.de/openldap/tracefile.dump The sourceports are 45376 and 45377 Tobias Am 2017-03-20 19:59, schrieb Aki Tuomi: > Well, those actually *reduce* the possible algorithms that can be > used, so uncommenting those can make things worse. > > Anyways, your pcap seems incomplete,

The one that works fine was my openxchange server, that loads contacts from openldap. In my opinion I don't have installed a security framework list SELinux or AppArmor. The output of namei -l /etc/ssl/certs/LetsEncrypt.pem f: /etc/ssl/certs/LetsEncrypt.pem drwxr-xr-x root root / drwxr-xr-x root root etc drwxr-xr-x root root ssl drwxr-xr-x root root certs lrwxrwxrwx root

Hi, This is more like a Windows configuration question. I set up a samba server (version 2.2.8a) on my Linux system with "user" security. I got three Windows 2000 systems, one professional, the other two are servers. Two servers are in same private domain. Now the professional machines can access Linux samba share without any problem. But two Windows 2000 server machines can not. I got

Did you do some succesful lookup with something there? I can see few failed attempts and one that seems to have worked just fine. As pointed out earlier, are you using security frameworks like SELinux or AppArmor? Also, can you provide namei -l /etc/ssl/certs/LetsEncrypt.pem The failed attempts are really short, indicating a VERY early problem with SSL handshake. Aki > On March 20, 2017 at

Could you copy LetsEncrypt.pem to a world-readable location, with world-readable rights, and see if this helps with your problem. I saw you tried with cat using su(do), but unfortunately supplementary groups are not always used with processes. Aki On 20.03.2017 23:09, info at gwarband.de wrote: > The one that works fine was my openxchange server, that loads contacts > from openldap. >

[I know this is the 'port' list, but I can't find a better place to post this, and with the garbage going on @slashdot I figured I'd get this out. This belongs on sci.crypt or a general OpenSSH mailing list] First, a quick rehash of stuff everyone here already knows, OpenSSH can use two major forms of authentication: 1. Password 2. RSA keys The RSA method is good because it

I have also tested with 2.2.28 and this version has the same issue. The finding of compatible ciphers is not the problem because I have uncommented the ldap entrys: TLSCipherSuite SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM TLSProtocolMin 3.1 Maybe you have further ideas. Am 2017-03-20 17:42, schrieb Aki Tuomi: >> On March 20, 2017 at 5:28 PM

Hi all! I have searched through the archives and have not found an answer to this, but it is also possible I wasn't searching for the right thing, so here goes. I am running samba 2.2.7a on a RH 9 box. I am having issues with transfer speeds on my shares. I have the shares mapped to drives on my XP box. When coping files from the XP -> linux, The speed is great. But from linux->XP

The following series of 10 patches is a merge of the xenfb and xenconsoled functionality into the qemu-dm code. The general approach taken is to have qemu-dm provide two machine types - one for xen paravirt, the other for fullyvirt. For compatability the later is the default. The goals overall are to kill LibVNCServer, remove alot of code duplication and/or parallel impls of the same concepts, and