We are trying to put in place a high availability instance of openLDAP
using a 3-node n-way multi master setup. I can telnet to our instance and
each individual node through ports 389 and 636. I can use the showcerts
command on port 636 and see the certs but wheh I try to do this on port
389
I can use the showcerts command on port 636 and see the certs but wheh I try
to do this on port
389 to use TLS I get the following error.
389 is the plaintext LDAP port; 636 is for LDAP over SSL/TLS so your system
is doing the right thing. If you want to force SSL/TLS, then you'll have to
On Mon, Sep 23, 2013 at 10:54:04AM -0400, Salz, Rich wrote:
Another option is to use LDAP's STARTTLS support on port 389.
It seems the config to require it is a bit obscure;
http://www.openldap.org/lists/openldap-technical/201202/msg00414.html
might be useful.
Note, the above is for
Another option is to use LDAP's STARTTLS support on port 389.
It seems the config to require it is a bit obscure;
http://www.openldap.org/lists/openldap-technical/201202/msg00414.html might be
useful.
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
From: Viktor Dukhovni openssl-us...@dukhovni.org
To: openssl-users@openssl.org openssl-users@openssl.org
Date: 09/23/2013 10:10 AM
Subject:Re: TLS authentication for ldap
Sent by:owner-openssl-us...@openssl.org
On Mon, Sep 23, 2013 at 10:54:04AM -0400, Salz, Rich
Viktor Dukhovni wrote:
On Mon, Sep 23, 2013 at 10:54:04AM -0400, Salz, Rich wrote:
Another option is to use LDAP's STARTTLS support on port 389.
It seems the config to require it is a bit obscure;
http://www.openldap.org/lists/openldap-technical/201202/msg00414.html
might be useful.
Note, the above is for enforcing STARTTLS on the server. If the
decision is left to the client, the configuration is less opaque.
And less secure. :)
If policy is to use SSL/TLS, then the server must enforce it; trusting the
clients to do the right thing is bad.
/r$
--
Principal
From: Salz, Rich rs...@akamai.com
To: openssl-users@openssl.org openssl-users@openssl.org
Date: 09/23/2013 10:29 AM
Subject:RE: TLS authentication for ldap
Sent by:owner-openssl-us...@openssl.org
Note, the above is for enforcing STARTTLS on the server. If the
On Mon, Sep 23, 2013 at 11:27:06AM -0400, Salz, Rich wrote:
Note, the above is for enforcing STARTTLS on the server. If the
decision is left to the client, the configuration is less opaque.
And less secure. :)
If policy is to use SSL/TLS, then the server must enforce it;
trusting the
From: Viktor Dukhovni openssl-us...@dukhovni.org
To: openssl-users@openssl.org openssl-users@openssl.org
Date: 09/23/2013 10:40 AM
Subject:Re: TLS authentication for ldap
Sent by:owner-openssl-us...@openssl.org
On Mon, Sep 23, 2013 at 11:27:06AM -0400, Salz, Rich
Am 22.09.2013 19:27, schrieb starlight.201...@binnacle.cx:
No /dev/urandom is a PRNG. /dev/random
is a TRNG. Read the code
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=272b98c6455f00884f0350f775c5342358ebb73f
/dev/random is a PRNG which
Hi everyone,
I'm hitting a unable to get local issuer certificate error on a specific
SSL certificate, and I was wondering how I can best debug this? It's via
NXLog which uses OpenSSL so a bit disconnected from the underlying library
at the moment, and I'm not too familar with OpenSSL.
I've
First, your question is really about a *connection* not a session.
For many familiar protocols these are pretty much the same thing,
but for SSL they are not. In SSL the session can and often but not
always does continue to exist after a connection is closed, and
can be reused by subsequent
It depends on the type of key used.
(Asymmetric) digital signature “algorithms” (schemes) consist of 2 or 3 parts:
- the digest algorithm applied to the data
- for RSA only, the padding applied to the digest
- the public-key algorithm used (RSA, DSA, ECDSA)
Commandline dgst allows you to
At 20:27 9/23/2013 +0200, Richard Könning wrote:
/dev/random is a PRNG which blocks when the (crude)
entropy estimation of the entropy pool falls below a
limit. Besides this there are afaik no big
differences between /dev/random and /dev/urandom.
In the sense that all TRNG outputs are run
Sorry for top-posting but you apparently posted richtext and my new
improved Outlook
can no longer impoverish text correctly nor reply inline to richtext. Bah.
You don't need the full chain(s), only the root(s), since both servers send
chain as they should.
The difference is that the
Thank you so much, I would never have figured that out in a million years!
It works perfectly following those instructions. And always good to know
the how in case I trip over it again, much appreciated.
Apologies for the richtext, I blame Google for that one...
On 23 September 2013 22:25,
Dear all,
I wrote a function like this:
DLL_INT ECryptEncryptData(char* certFile, char* dataFile, char*
encryptedFile, char* errMsg, int errMsgLen)
{
static char* func = ECryptEncryptData;
int rc = 0;
char msg[MSG_LEN];
BIO *in = NULL, *out = NULL;//, *tbio = NULL;//, *dout =
On Mon, Sep 23, 2013 at 12:59 PM, starlight.201...@binnacle.cx wrote:
At 20:27 9/23/2013 +0200, Richard Könning wrote:
/dev/random is a PRNG which blocks when the (crude)
entropy estimation of the entropy pool falls below a
limit. Besides this there are afaik no big
differences between
At 12:59 9/23/2013 -0700, Michael Sierchio wrote:
I'll repeat myself - the fact that the
/dev/random implementation you're using
blocks is a serious design flaw.
Convince Linus, the GPG developers et al.--not me.
Till then I respect their view as embodied
by the latest implementation of
20 matches
Mail list logo
