Re: [openssl-users] Is there a "Golden" CA makefile?

[Jakob Bohm]

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 mentioning Open*VPN*, let me mention that
EasyRSA is a spin-off of that project. Not makefiles based, and working
with sub-CAs certainly isn't easy (though *possible* with version 3),
but if you want to see how the OpenVPN people think "their" CAs *should*
be run, that's what I'ld suggest to look at.

In a more general sense, the policies and technical limitations of CAs
vary too much for their operators to even agree on what color gold has,
I guess ...

(Not-quite-random example: Out of the box, OpenSSL dislikes CAs issuing
same-DN certs with overlapping validity periods. OpenVPN, again out of
the box, bases the mechanism of peer-specific configs on the CN. So if
you want to renew the cert of some device you're managing remotely
*through* the very VPN, you may(*) have an interest to *defeat* the
OpenSSL behavior, so as to issue the new cert before the old one expires
and saws off the branch you're adminning from.
(*) Of course, there *are* other techniques to work around the problem,
but.)




Not as much "defeat", as setting the relevant option by adding the
following command during CA (and SubCA) setup:

  echo "unique_subject = no" > ${CADIR}/db/index.attr



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problem building Linux shared library with static FIPS capable OpenSSL

[Nathan Glasser]

>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 signature which can then be embedded
>for the second link step.

Thanks, Steve. With your help I was able to get this to work.

It's sort of hokey process - 

1) Run an extra undocumented make step (make fips_premain_dso).
2) Change my target shared library (.so) file to start with "lib".
3) Put the fips_premain_dso program into the directory from which fipsld
   is being run.
4) Rename the target shared library back to its intended name.

But it does work. Problem solved.

Thanks,
Nathan
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Segmentation fault ssl23_connect()

[Viktor Dukhovni]

> 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 recent OpenLDAP release before trying 
> anything else.

It should "just work".  The OpenSSL 1.0.2 branch is expected to provide ABI
compatibility with older software built against OpenSSL 1.0.0, 1.0.1 and
older patch levels of 1.0.2.

There could of course be unfixed bugs in that OpenLDAP version that a newer
version of OpenSSL happens to expose, but generally speaking what worked
with 1.0.0 or 1.0.1 should continue to work with 1.0.2.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Segmentation fault ssl23_connect()

[Michael Ströder]

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 OpenLDAP project several years 
ago.

I'd strongly recommend to use a recent OpenLDAP release before trying anything 
else.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Michael Wojcik]

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 to terminate poorly-written programs that 
could otherwise block a pipeline. See Bach, The Design of the UNIX Operating 
System; if memory serves, Bach quotes Dennis Ritchie on this point. SIGPIPE was 
introduced because some poorly-written programs did not check the return code 
from write.[1]

Catching SIGPIPE in a custom handler is nearly always the Wrong Thing. The 
correct approach, 99.9% of the time, is to set the disposition to SIG_IGN and 
check the results of each system call.

Personally, I think it's completely acceptable for a library to note in its 
documentation that the calling program MUST ignore SIGPIPE, or the library may 
not function properly. It's arguably OK for a library to check the disposition 
of SIGPIPE and if it's SIG_DFL, change it to SIG_IGN, on the grounds that the 
calling program is not well-written so it doesn't deserve to govern its own 
signal handling; but it's probably better to just fail in that case, either 
immediately (with a diagnostic that tells the user that the developer forgot to 
set the disposition of SIGPIPE) or when a SIGPIPE occurs.

Libraries can't accommodate all forms of invalid behavior. You can do a certain 
amount of defensive coding, but at some point you're diminishing functionality 
for well-behaved applications in order to coddle bad ones. Don't do that.

[1] There were no send, sendto, or sendmsg calls at the time. Now the argument 
applies equally to them.

Michael Wojcik
Distinguished Engineer, Micro Focus



From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
mahesh gs
Sent: Monday, May 01, 2017 23:59
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write


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.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Viktor Dukhovni]

> 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 pthread_sigmask() to only block SIGPIPE for the current
> thread (perhaps unblocking it again before returning control back to the
> caller of your library)?

Presumably, the signal will be delivered as soon as it unblocked, and likely
before "returning control to the caller".  So I think this just delays the
problem, but does not fix it.  Blocking a signal is not the same as ignoring
it.  Multi-threaded programs should avoid having signals delivered to some
random thread that happens to be "on CPU", by blocking signals permanently
in all but a single signal-handling thread, but such design decisions are
made in main() and not in libraries.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[mahesh gs]

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 library (application) might want to
> > handle the SIGPIPE for there own socket handling.
>
> Could you use pthread_sigmask() to only block SIGPIPE for the current
> thread (perhaps unblocking it again before returning control back to the
> caller of your library)?
>



> Thanks for your suggestion. We will try to adapt this work around.
>
>
> >
> > Thanks,
> > Mahesh G S
> >
> > On Thu, Apr 27, 2017 at 4:36 PM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 27/04/17 11:56, mahesh gs wrote:
> > > Hi,
> > >
> > > We are using Openssl for establish a secure communications for both
> > > TCP/SCTP connections.
> > >
> > > In our application it is possible that remote end forcefully
> disconnect
> > > the connection due to which
> > >
> > > SSL_Write raises a SIGPIPE which we want to suppress. Does openssl
> > >
> > > provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP
> socket
> > > layer) ?
> >
> > No, there is no option to do that at the moment.
> >
> > >
> > > Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as
> it is
> > > not supported by LINUX
> > >
> > > and also we are unable to stop the SIGPIPE with function call
> > > signal(SIGPIPE, SIG_IGN).
> >
> > Unable because you want SIGPIPE for other areas of your application?
> Or
> > for some other reason?
> >
> > Matt
> > --
> > openssl-users mailing list
> > To unsubscribe:
> > https://mta.openssl.org/mailman/listinfo/openssl-users
> > 
> >
> >
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] SSL_VERIFY_PEER

[john gloster]

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. At
each level signatures and issuer attributes are checked. "

When we say "issuer attributes", could someone let me know what different
stuffs in the CA certificate are validated?


Thanks in advance.

John.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Matt Caswell]

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.

Could you use pthread_sigmask() to only block SIGPIPE for the current
thread (perhaps unblocking it again before returning control back to the
caller of your library)?

Matt

> 
> Thanks,
> Mahesh G S
> 
> On Thu, Apr 27, 2017 at 4:36 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 27/04/17 11:56, mahesh gs wrote:
> > Hi,
> >
> > We are using Openssl for establish a secure communications for both
> > TCP/SCTP connections.
> >
> > In our application it is possible that remote end forcefully disconnect
> > the connection due to which
> >
> > SSL_Write raises a SIGPIPE which we want to suppress. Does openssl
> >
> > provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket
> > layer) ?
> 
> No, there is no option to do that at the moment.
> 
> >
> > Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as it is
> > not supported by LINUX
> >
> > and also we are unable to stop the SIGPIPE with function call
> > signal(SIGPIPE, SIG_IGN).
> 
> Unable because you want SIGPIPE for other areas of your application? Or
> for some other reason?
> 
> Matt
> --
> openssl-users mailing list
> To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Doubt regarding ExtendedMasterSecret

[Matt Caswell]

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?
>I need to manually set this for my tool, i assume it holds both
> client and server handshakes, am i right?
> 
> 
>if i am right , in openssl , i just need to populate
> s3->handshake_buffer and set  flags to  s->session->flags &
> SSL_SESS_FLAG_EXTMS.
>only unknown thing i have is  s3->handshake_buffer , what value to
> copy there.

handshake_buffer is a mem BIO that contains a copy of all the handshake
messages sent and received so far - but only sometimes. Dependant on how
the handshake proceeds sometimes this buffer stays active for a while.
Other times it gets released early and instead we keep a rolling hash of
the handshake messages.

The problem is your code is reaching right into the internals of libssl
and playing around with the internal state. In OpenSSL 1.1.0 you will be
unable to do that (the SSL struct is opaque).

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Win 10 failure on install

[Richard Levitte]

Are you running on an Itanium?  If not, VC-WIN64I is not for you,
please configure with VC-WIN64A instead.

Cheers,
Richard

In message 

Re: [openssl-users] Query regarding DTLS handshake

[Michael Tuexen]

> 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 the time (sequence of events) at which SSL 
> > read_state_machine enter the post processing of certificate verify which is 
> > received from client.
> >
> > Handshake works fine if the certificate verify post processing is done 
> > before the next message arrives at SCTP socket layer (In your case may be 
> > there is a delay in receiving the next message at SCTP layer). Handshake 
> > works fine even in my environment some times.
> Can you try the attached patch and report if it fixes the issue for you?
> 
> I have tried with the patch provided by Matt. Our test results are 
> successful. Issue is fixed with the patch.
OK, I see. It isn't fixed in our case. That is why I sent the patch.
Thanks for the feedback.

Best regards
Michael
> 
> Best regards
> Michael
> 
> 
> 
> >
> >
> > I added some debug statements, below is the debug statements.
> >
> >
> > Debug statements when the handshake does not work
> >
> > 
> >
> > Length of the next packet (Cipher spec change) is exactly 14 as i mentioned 
> >  in - https://github.com/openssl/openssl/issues/3251
> >
> > Debug logs when the handshake is successful
> >
> > 
> >
> > If no message is waiting to be received at socket layer then handshake is 
> > successful. If message is waiting to be received at socket layer then the 
> > handshake will never be completed.
> >
> >
> > Thanks,
> > Mahesh G S
> >
> > On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha 
> >  wrote:
> >
> >
> > Matt Caswell wrote on 04/20/2017 03:23 PM:
> > >
> > >
> > > On 20/04/17 14:19, Martin Brejcha wrote:
> > >>
> > >>
> > >> Matt Caswell wrote on 04/20/2017 01:29 PM:
> > >>>
> > >>>
> > >>> On 20/04/17 12:26, mahesh gs wrote:
> >  Hi Matt,
> > 
> >  Yes I raised github case for the same issue. I also tried running this
> >  call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and
> >  handshake is successful with the latest SNAPSHOT code which is not an
> >  official release.
> > 
> >  I checked the github repo history and observer that during commits on
> >  (11 th Jan) as a part of "Move state machine knowledge out of the 
> >  record
> >  layer".  "renegotiate" bit that is set to "2" in function
> >  "tls_post_process_client_hello" has been removed. May be that is 
> >  causing
> >  the call flow to be successful in the latest SNAPSHOT release.
> > 
> >  I am assuming commits that are done on 11th Jan or later are not part 
> >  of
> >  release openssl 01.01.00e
> > >>>
> > >>> Ah. No. That commit is in the dev branch only (scheduled for version
> > >>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why that
> > >>> commit might help things, but probably a different solution is more
> > >>> appropriate for 1.1.0.
> > >>>
> > >>> I'm looking at this issue at the moment.
> > >>>
> > >>> Matt
> > >>>
> > >>
> > >> hi,
> > >>
> > >> btw: I've tested similar scenario and handshake works fine.
> > >> test env: client and server on different VMs (rhel7.2, openssl 1.1.0e, 
> > >> non-blocking sockets and segmented certificate)
> > >> So, it should work also with 1.1.0e version.
> > >
> > > Thanks. Did your handshake include client auth? I think this issue only
> > > arises in that case.
> > >
> > > Matt
> > >
> > >
> >
> > yes, client auth with segmented certificate has been included.
> >
> > Martin
> >
> >
> >
> > >
> > >
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding DTLS handshake

[mahesh gs]

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 processing of certificate verify
> which is received from client.
> >
> > Handshake works fine if the certificate verify post processing is done
> before the next message arrives at SCTP socket layer (In your case may be
> there is a delay in receiving the next message at SCTP layer). Handshake
> works fine even in my environment some times.
> Can you try the attached patch and report if it fixes the issue for you?
>

I have tried with the patch provided by Matt. Our test results are
successful. Issue is fixed with the patch.

>
> Best regards
> Michael
>
>
>
> >
> >
> > I added some debug statements, below is the debug statements.
> >
> >
> > Debug statements when the handshake does not work
> >
> > 
> >
> > Length of the next packet (Cipher spec change) is exactly 14 as i
> mentioned  in - https://github.com/openssl/openssl/issues/3251
> >
> > Debug logs when the handshake is successful
> >
> > 
> >
> > If no message is waiting to be received at socket layer then handshake
> is successful. If message is waiting to be received at socket layer then
> the handshake will never be completed.
> >
> >
> > Thanks,
> > Mahesh G S
> >
> > On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha <
> martin.brej...@mavenir.com> wrote:
> >
> >
> > Matt Caswell wrote on 04/20/2017 03:23 PM:
> > >
> > >
> > > On 20/04/17 14:19, Martin Brejcha wrote:
> > >>
> > >>
> > >> Matt Caswell wrote on 04/20/2017 01:29 PM:
> > >>>
> > >>>
> > >>> On 20/04/17 12:26, mahesh gs wrote:
> >  Hi Matt,
> > 
> >  Yes I raised github case for the same issue. I also tried running
> this
> >  call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and
> >  handshake is successful with the latest SNAPSHOT code which is not
> an
> >  official release.
> > 
> >  I checked the github repo history and observer that during commits
> on
> >  (11 th Jan) as a part of "Move state machine knowledge out of the
> record
> >  layer".  "renegotiate" bit that is set to "2" in function
> >  "tls_post_process_client_hello" has been removed. May be that is
> causing
> >  the call flow to be successful in the latest SNAPSHOT release.
> > 
> >  I am assuming commits that are done on 11th Jan or later are not
> part of
> >  release openssl 01.01.00e
> > >>>
> > >>> Ah. No. That commit is in the dev branch only (scheduled for version
> > >>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why
> that
> > >>> commit might help things, but probably a different solution is more
> > >>> appropriate for 1.1.0.
> > >>>
> > >>> I'm looking at this issue at the moment.
> > >>>
> > >>> Matt
> > >>>
> > >>
> > >> hi,
> > >>
> > >> btw: I've tested similar scenario and handshake works fine.
> > >> test env: client and server on different VMs (rhel7.2, openssl
> 1.1.0e, non-blocking sockets and segmented certificate)
> > >> So, it should work also with 1.1.0e version.
> > >
> > > Thanks. Did your handshake include client auth? I think this issue only
> > > arises in that case.
> > >
> > > Matt
> > >
> > >
> >
> > yes, client auth with segmented certificate has been included.
> >
> > Martin
> >
> >
> >
> > >
> > >
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[mahesh gs]

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, Matt Caswell  wrote:

>
>
> On 27/04/17 11:56, mahesh gs wrote:
> > Hi,
> >
> > We are using Openssl for establish a secure communications for both
> > TCP/SCTP connections.
> >
> > In our application it is possible that remote end forcefully disconnect
> > the connection due to which
> >
> > SSL_Write raises a SIGPIPE which we want to suppress. Does openssl
> >
> > provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket
> > layer) ?
>
> No, there is no option to do that at the moment.
>
> >
> > Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as it is
> > not supported by LINUX
> >
> > and also we are unable to stop the SIGPIPE with function call
> > signal(SIGPIPE, SIG_IGN).
>
> Unable because you want SIGPIPE for other areas of your application? Or
> for some other reason?
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users