On 30/04/2017 13:52, Jochen Bern wrote:
On 04/29/2017 09:55 PM, John Lewis got digested:
I am looking for a CA makefile to use with a openvpn tutorial I am
writing https://github.com/Oflameo/openvpn_ws. Is there one officially
endorsed by the openssl project?
Since you're specifically
>Try a shared build of the FIPS capable OpenSSL. You should then get
>fips_premain_dso built as part of that process. Alternatively just do:
> make fips_premain_dso
>The fips_premain_dso executable isn't anything special: all it does is load
>the library. It should then print out the
> On May 2, 2017, at 2:02 PM, Michael Ströder wrote:
>
> I'm not sure whether OpenSSL 1.0.2k is even usable with this ancient OpenLDAP
> version.
> Especially it was set to historic status by the OpenLDAP project several
> years ago.
>
> I'd strongly recommend to use a
Sanjaya Joshi wrote:
> I use openldap_2.3.39 to initiate secure LDAP connection (starttls) to
> external LDAP
> server. The used openssl version is 1.0.2k.
I'm not sure whether OpenSSL 1.0.2k is even usable with this ancient OpenLDAP
version.
Especially it was set to historic status by the
It may be worth noting that nearly all well-written UNIX applications should
set the disposition of SIGPIPE to SIG_IGN. (Preferably using sigaction, simply
because that's now the preferred API, but doing it with signal is essentially
equivalent in this case.)
SIGPIPE is a hack. It exists only
> On May 2, 2017, at 5:06 AM, Matt Caswell wrote:
>
>> Yes, ours is a library and we do not wish to ignore the signal process
>> wide because the consumer of our library (application) might want to
>> handle the SIGPIPE for there own socket handling.
>
> Could you use
On Tue, May 2, 2017 at 2:36 PM, Matt Caswell wrote:
>
>
> On 02/05/17 06:59, mahesh gs wrote:
> > Hi Matt,
> >
> > Sorry for delayed response. I was on leave.
> >
> > Yes, ours is a library and we do not wish to ignore the signal process
> > wide because the consumer of our
Hi,
I needed to validate different extensions of each of the Issuer certificate
in the chain.
Snippet rom https://linux.die.net/man/3/ssl_set_verify:
"The certificate chain is checked starting with the deepest nesting level
(the root CA certificate) and worked upward to the peer's certificate.
On 02/05/17 06:59, mahesh gs wrote:
> Hi Matt,
>
> Sorry for delayed response. I was on leave.
>
> Yes, ours is a library and we do not wish to ignore the signal process
> wide because the consumer of our library (application) might want to
> handle the SIGPIPE for there own socket handling.
On 30/04/17 19:51, Stiju Easo wrote:
> Hi ,
>
>I got the answer to this, and now the question looks bit stupid.
>Generation of master key is different in case of "Extended Master
> Secret" ,
>
>I still have a doubt, what would be the contents in SSL*
> s->s3->handshake_buffer?
Are you running on an Itanium? If not, VC-WIN64I is not for you,
please configure with VC-WIN64A instead.
Cheers,
Richard
In message
> On 2. May 2017, at 08:03, mahesh gs wrote:
>
>
>
> On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen
> wrote:
> > On 20. Apr 2017, at 20:01, mahesh gs wrote:
> >
> > Hi,
> >
> > This issue occur purely based on
On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen <
michael.tue...@lurchi.franken.de> wrote:
> > On 20. Apr 2017, at 20:01, mahesh gs wrote:
> >
> > Hi,
> >
> > This issue occur purely based on the time (sequence of events) at which
> SSL read_state_machine enter the post
Hi Matt,
Sorry for delayed response. I was on leave.
Yes, ours is a library and we do not wish to ignore the signal process wide
because the consumer of our library (application) might want to handle the
SIGPIPE for there own socket handling.
Thanks,
Mahesh G S
On Thu, Apr 27, 2017 at 4:36 PM,
14 matches
Mail list logo