Re: [openssl-users] help with timestamping

[Jakob Bohm]

On 19/04/2016 05:55, Alex Samad wrote:

Hi

I have a SHA.sha file

/usr/bin/openssl ts -query -data SHA.sha -sha256 | /usr/bin/curl -s -H
Content-Type:application/timestamp-query --data-binary @-
http://sha256timestamp.ws.symantec.com/sha256/timestamp > SHA.sha.tsr

/usr/bin/openssl ts -reply -in SHA.sha.tsr -text  > SHA.sha.ts.txt


cat SHA.sha.ts.txt
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: 2.16.840.1.113733.1.7.23.3
Hash Algorithm: sha256
Message data:
  - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6   .m.[...WE.i.
 0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5   z.U%..W7>\..
Serial number: 0x570B9C3A11CA318E2478D3680C0FEFD9238E06AB
Time stamp: Apr 19 03:52:25 2016 GMT
Accuracy: 0x1E seconds, unspecified millis, unspecified micros
Ordering: no
Nonce: 0x580E59D87F396B25
TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
Network/CN=Symantec SHA256 TimeStamping Signer - G1
Extensions:


But when I go to verify it

  openssl ts -verify -data SHA.sha -in SHA.sha.tsr
Verification: FAILED
140569777235784:error:2107C080:PKCS7
routines:PKCS7_get0_signers:signer certificate not
found:pk7_smime.c:476:

is this because I didn't provide a cert to sign it with ?

No, it is because it cannot find the certificate that Symantec
used to sign the response, specifically the certificate with
Subject name "/C=US/O=Symantec Corporation/OU=Symantec Trust
Network/CN=Symantec SHA256 TimeStamping Signer - G1".

I am kind of disappointed in how little detail is included in
the output from ts -reply -text, I expected it to output all
the fields, similar to what other openssl commands do when
passed the -text option.

So I guess the next step would be to dump SHA.sha.tsr using
Peter Gutmann's dumpasn1.c program, something like

openssl base64 -d -in SHA.sha.tsr -out SHA.sha.tsr.bin
dumpasn1 -v SHA.sha.tsr.bin


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

[openssl-users] help with timestamping

[Alex Samad]

Hi

I have a SHA.sha file

/usr/bin/openssl ts -query -data SHA.sha -sha256 | /usr/bin/curl -s -H
Content-Type:application/timestamp-query --data-binary @-
http://sha256timestamp.ws.symantec.com/sha256/timestamp > SHA.sha.tsr

/usr/bin/openssl ts -reply -in SHA.sha.tsr -text  > SHA.sha.ts.txt


cat SHA.sha.ts.txt
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: 2.16.840.1.113733.1.7.23.3
Hash Algorithm: sha256
Message data:
 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6   .m.[...WE.i.
0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5   z.U%..W7>\..
Serial number: 0x570B9C3A11CA318E2478D3680C0FEFD9238E06AB
Time stamp: Apr 19 03:52:25 2016 GMT
Accuracy: 0x1E seconds, unspecified millis, unspecified micros
Ordering: no
Nonce: 0x580E59D87F396B25
TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
Network/CN=Symantec SHA256 TimeStamping Signer - G1
Extensions:


But when I go to verify it

 openssl ts -verify -data SHA.sha -in SHA.sha.tsr
Verification: FAILED
140569777235784:error:2107C080:PKCS7
routines:PKCS7_get0_signers:signer certificate not
found:pk7_smime.c:476:

is this because I didn't provide a cert to sign it with ?

I just want to verify the timestamp.

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

Re: [openssl-users] [openssl-dev] where is PEM_read_bio_X509_AUX()

[Viktor Dukhovni]

[ Redirecting to openssl-users@openssl.org ]

On Tue, Apr 19, 2016 at 01:11:38AM +, CHOW Anthony wrote:

> I am trying to do “openssl verify –CAfile server.pem” and the command hang.

It is supposed to hang (reading standard input) when (incorrectly)
invoked this way.  You've left out the CAfile filename.  The correct
way to verify a certificate is:

$ trusted=ta.pem
$ untrusted=intermediate.pem
$ subject=server.pem
$ openssl verify -CAfile $trusted -untrusted $untrusted $subject

where 

 * "ta.pem" contains your trust-anchor (root CA) certificates,
 * "intermediate.pem" contains any intermediate certificates needed to
build a trust path from a root down to the server certificate,
 * "server.pem" contains the subject certificate to be verified.

Leave out the "-untrusted $untrusted" option if you're verifying
a certificate that is directly issued by a trust-anchor.

With a sufficiently recent version of OpenSSL replace "-CAfile
$trusted" with "-trusted $trusted" to make sure you're not
inadvertently using any of the default trust-anchors installed on
your system.

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

Re: [openssl-users] FIPS compile issue with Perl on Windows

[Jakob Bohm]

On 19/04/2016 01:51, Steve Marquess wrote:

On 04/18/2016 04:05 PM, Leaky wrote:

plus you're constrained by the
requirements of the Security Policy to build the module with precisely
the commands:

  gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
  cd openssl-fips-2.0.12
  ./config
  make

Silly question... I know that you should only run the above commands, but
can you deviate from the unzip tool, i.e. use 7zip?

I managed to get it to work without editing anything, but I am now wondering
if my process to compile the FIPS canister is bad purely because i am
storing the deflated tarball on our SVN and using that uncompressed code to
build from.  Putting aside the fact that this is automated, and that it is
best to "run once and use many", should my script work with the raw tarball
straight from the web, and not a locally expanded copy?

This is a mistake I've seen many times ("storing the deflated tarball on
our SVN"). You're thinking like a software engineer, when you should be
thinking like Alice down in the FIPS 140-2 rabbit hole.

There is no point in attempting to do the usual configuration management
and software version control on the contents of the
openssl-fips-2.0.12.tar.gz tarball. You CANNOT change the content; there
can be no changes to manage!!!

Almost true.  If it wasn't banned by the FIPS security policy, checking in
the uncompressed tarball could be used to efficiently manage and track new
upstream releases of the tarball and to document which exact upstream FIPS
cannister source code (and hence corresponding validation date) was
incorporated into which product version (an aspect of FIPS compliance which
someone might want to audit

But alas, as you clarify below, this is not permitted by the OpenSSL FIPS
security policy directly incorporated into the validation.

The slightly less efficient idea of putting the compressed tarball into
the configuration control repository (which in this case *is* tracking the
build configuration, not the code versions) is probably (I am not sure)
againstthe policy that the tarball must be taken "securely" from the
physical CD mailed out by the OpenSSL foundation.

So the thing that can probably be put into a repository is the binary
FIPSCannister.o file along with copies of any documents certifying how,
where, from what and by whom said FIPS cannister was built.

Of cause, one could, purely for debugging/documentation purposes, include
a copy of the FIPS Cannister source code in the repository, one just
cannot compile anything releasable from it.



The Security Policy is quite specific on the requirements, which make no
allowance for the common sense (to a software engineer) fact that there
are equivalent multiple ways to accomplish each step (such as unzipping
the tarball). You are also specifically required to begin with the
official tarball. Per the Security Policy, you *must* do:

   gunzip -c openssl-fips-2.0.12.tar.gz | tar xf -

and *not* any functionally equivalent alternative such as:

   tar -zxf openssl-fips-2.0.12.tar.gz

or even worse, a checkout of the expanded contents from your version
management system.

This is why I recommend you build the FIPS module once, manually,
exactly per the documented requirements. It doesn't make sense, from the
software engineering viewpoint, but is what the FIPS 140-2 validation
bureaucracy insists on.

-Steve M.





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] FIPS compile issue with Perl on Windows

[Steve Marquess]

On 04/18/2016 04:05 PM, Leaky wrote:
>>> plus you're constrained by the
>>> requirements of the Security Policy to build the module with precisely
>>> the commands:
>>>
>>>  gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
>>>  cd openssl-fips-2.0.12
>>>  ./config
>>>  make
> 
> Silly question... I know that you should only run the above commands, but
> can you deviate from the unzip tool, i.e. use 7zip?
> 
> I managed to get it to work without editing anything, but I am now wondering
> if my process to compile the FIPS canister is bad purely because i am
> storing the deflated tarball on our SVN and using that uncompressed code to
> build from.  Putting aside the fact that this is automated, and that it is
> best to "run once and use many", should my script work with the raw tarball
> straight from the web, and not a locally expanded copy?

This is a mistake I've seen many times ("storing the deflated tarball on
our SVN"). You're thinking like a software engineer, when you should be
thinking like Alice down in the FIPS 140-2 rabbit hole.

There is no point in attempting to do the usual configuration management
and software version control on the contents of the
openssl-fips-2.0.12.tar.gz tarball. You CANNOT change the content; there
can be no changes to manage!!!

The Security Policy is quite specific on the requirements, which make no
allowance for the common sense (to a software engineer) fact that there
are equivalent multiple ways to accomplish each step (such as unzipping
the tarball). You are also specifically required to begin with the
official tarball. Per the Security Policy, you *must* do:

  gunzip -c openssl-fips-2.0.12.tar.gz | tar xf -

and *not* any functionally equivalent alternative such as:

  tar -zxf openssl-fips-2.0.12.tar.gz

or even worse, a checkout of the expanded contents from your version
management system.

This is why I recommend you build the FIPS module once, manually,
exactly per the documented requirements. It doesn't make sense, from the
software engineering viewpoint, but is what the FIPS 140-2 validation
bureaucracy insists on.

-Steve M.


-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS compile issue with Perl on Windows

[Leaky]

>> plus you're constrained by the
>> requirements of the Security Policy to build the module with precisely
>> the commands:
>>
>>  gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
>>  cd openssl-fips-2.0.12
>>  ./config
>>  make

Silly question... I know that you should only run the above commands, but
can you deviate from the unzip tool, i.e. use 7zip?

I managed to get it to work without editing anything, but I am now wondering
if my process to compile the FIPS canister is bad purely because i am
storing the deflated tarball on our SVN and using that uncompressed code to
build from.  Putting aside the fact that this is automated, and that it is
best to "run once and use many", should my script work with the raw tarball
straight from the web, and not a locally expanded copy?







--
View this message in context: 
http://openssl.6102.n7.nabble.com/FIPS-compile-issue-with-Perl-on-Windows-tp65574p65577.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS compile issue with Perl on Windows

[Steve Marquess]

On 04/18/2016 11:01 AM, Tristan Leask wrote:
> Hi All,
> 
> I am currently trying to setup an automated build process for a
> cloned copy of the code.  ...
> 
> In the link mentioned, it is talked about modifying the perl script
> to change how STDOUT works, however when you are compiling FIPS you
> aren't meant to modify the code shipped in the tarball, so how does
> one work around this issue apart from just compiling the code
> manually all the time?

There is really no point in trying to automate the build of the FIPS
module (fipscanister.o). As noted you can't change the source code
(contents of the tarball) at all, plus you're constrained by the
requirements of the Security Policy to build the module with precisely
the commands:

  gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
  cd openssl-fips-2.0.12
  ./config
  make

The Security Policy doesn't expressly prohibit you from embedding those
commands in a script, but IMHO you gain nothing but grief by doing so.
Build it manually, once, with some sort of record as a CYA for your file
cabinet.

Once you have the one and only copy of fipscanister.o you need (per
platform), you can then use normal software engineering best practice
for building OpenSSL proper (e.g. 1.0.2g) and your application code, and
automation would make more sense.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] FIPS compile issue with Perl on Windows

[Tristan Leask]

Hi All,

I am currently trying to setup an automated build process for a cloned copy of 
the code.  I can run through the process manually by issuing all the commands 
required from a command line without issue.  If I then take all these commands 
and put them into a CI job using Jenkins, I then see the following type of 
error...
set ASM=ml64 /c /Cp /Cx /Zi
perl crypto\modes\asm\ghash-x86_64.pl tmp32dll\ghash-x86_64.asm
perl util\fipsas.pl . tmp32dll\ghash-x86_64.asm norunasm /MD /Ox 
-DOPENSSL_FIPSCANISTER -DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -Gy -nologo 
-DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE 
-D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
-DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 
-DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE
ml64 /c /Cp /Cx /Zi /Fotmp32dll\ghash-x86_64.obj 
tmp32dll\ghash-x86_64.asm
 Assembling: tmp32dll\ghash-x86_64.asm
tmp32dll\ghash-x86_64.asm(868
tmp32dll\ghash-x86_64.asm(868) : error A2008:syntax 
errortmp32dll\ghash-x86_64.asm(1012)e
tmp32dll\ghash-x86_64.asm(1012) : fatal error A1010:unmatched block nesting : 
gcm_gMicrosoft (R) Macro Assembler (x64) Version 14.00.23026.0
Copyright (C) Microsoft Corporation.  All rights reserved.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\BIN\amd64\ml64.EXE"' : return code '0x1'

I have done some digging and I am sure I am running into the issue discussed 
here...
https://rt.openssl.org/Ticket/Display.html?id=2963&user=guest&pass=guest

This is to do with Perl not being able to flush the STDOUT pipe to disk fast 
enough before the ml compiler tries to pick the ASM file up.

In the link mentioned, it is talked about modifying the perl script to change 
how STDOUT works, however when you are compiling FIPS you aren't meant to 
modify the code shipped in the tarball, so how does one work around this issue 
apart from just compiling the code manually all the time?

I am running Visual Studio 2015 and ActivePerl-5.22.1.2201-MSWin32-x64-299574, 
and I am trying to compile openssl-1.0.2g and openssl-fips-2.0.12.

Thanks

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

Re: [openssl-users] EVP_EncryptUpdate and EVP_CIPHER callback do_cipher

[Dmitry Belyavsky]

Dear Matt,

On Mon, Apr 18, 2016 at 6:00 PM, Matt Caswell  wrote:

>
>
> On 18/04/16 15:55, Dmitry Belyavsky wrote:
> > Hello,
> >
> > Could anybody explain how to deal with the output length in the
> > EVP_EncryptUpdate?
> >
> > The function EVP_EncryptUpdate has the outl output parameter, which is
> > designed for returning the length of the resulting ciphertext. Then
> > internally it calls the do_cipher callback which does not take such a
> > parameter.
> >
> > Is there a way to return an expected buffer length from the callback?
> > It may be necessary when we call the EVP_EncryptUpdate some times, and
> > we get the case when ctx->buf from the previous calls has enough bytes
> > to be processed together with the input buffer so the output is longer
> > then the input.
>
> The man page advises that the size of the output buffer should be:
>
> inl + cipher_block_size - 1
>
> This should cater for all eventualities.
>

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EVP_EncryptUpdate and EVP_CIPHER callback do_cipher

[Matt Caswell]

On 18/04/16 15:55, Dmitry Belyavsky wrote:
> Hello,
> 
> Could anybody explain how to deal with the output length in the
> EVP_EncryptUpdate?
> 
> The function EVP_EncryptUpdate has the outl output parameter, which is
> designed for returning the length of the resulting ciphertext. Then
> internally it calls the do_cipher callback which does not take such a
> parameter.
> 
> Is there a way to return an expected buffer length from the callback?
> It may be necessary when we call the EVP_EncryptUpdate some times, and
> we get the case when ctx->buf from the previous calls has enough bytes
> to be processed together with the input buffer so the output is longer
> then the input.

The man page advises that the size of the output buffer should be:

inl + cipher_block_size - 1

This should cater for all eventualities.

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

[openssl-users] EVP_EncryptUpdate and EVP_CIPHER callback do_cipher

[Dmitry Belyavsky]

Hello,

Could anybody explain how to deal with the output length in the
EVP_EncryptUpdate?

The function EVP_EncryptUpdate has the outl output parameter, which is
designed for returning the length of the resulting ciphertext. Then
internally it calls the do_cipher callback which does not take such a
parameter.

Is there a way to return an expected buffer length from the callback?
It may be necessary when we call the EVP_EncryptUpdate some times, and we
get the case when ctx->buf from the previous calls has enough bytes to be
processed together with the input buffer so the output is longer then the
input.

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl-users Digest, Vol 17, Issue 24

[danigrosu]

So the problem is on client side since you receive server hello.
Please give some more details. What are you trying to do and
especially how.

Regards,
Dani Grosu




--
View this message in context: 
http://openssl.6102.n7.nabble.com/Re-openssl-users-Digest-Vol-17-Issue-24-tp65568p65570.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl-users Digest, Vol 17, Issue 24

[james sqawz]

@danigrosu

Not exactly Apache server.
But from some different client it properly responded with "SERVER HELLO" .

Thanks

On Mon, Apr 18, 2016 at 6:22 PM,  wrote:

> Send openssl-users mailing list submissions to
> openssl-users@openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
> openssl-users-requ...@openssl.org
>
> You can reach the person managing the list at
> openssl-users-ow...@openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>1. API question; v3_asid/v3_addr (Salz, Rich)
>2. 1.1.0-pre4: openssl speed chacha (c^)
>3. Unable to load/add a dynamic engine (danigrosu)
>4. Regarding TLS 1.3 (James)
>5. Re: Regarding TLS 1.3 (Matt Caswell)
>6. ssl connect failed (james sqawz)
>7. Re: ssl connect failed (danigrosu)
>
>
> --
>
> Message: 1
> Date: Thu, 14 Apr 2016 16:57:56 +
> From: "Salz, Rich" 
> To: "openssl-...@openssl.org" ,
> "openssl-users@openssl.org" 
> Subject: [openssl-users] API question; v3_asid/v3_addr
> Message-ID:
> <
> f583e20aef574e55a5761812440da...@usma1ex-dag1mb1.msg.corp.akamai.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Do you use the v3_asid_xxx or v3_addr_xxx API's?  Please let me know.
>
> (They are not going away, we just need to know if they're internal-only or
> if people are using them.)
>
> --
> Senior Architect, Akamai Technologies
> IM: richs...@jabber.at Twitter: RichSalz
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20160414/052eaa82/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: Fri, 15 Apr 2016 15:29:16 +0100
> From: "c^" 
> To: openssl-users@openssl.org
> Subject: [openssl-users] 1.1.0-pre4: openssl speed chacha
> Message-ID:
>  6...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi there,
>
> I don't seem to be able to benchmark chacha, nor does it appear in the list
> when I test all.
> Is this expected?
>
> I can see it in 'openssl ciphers -V "ALL"' and also negotiate from a
> client.
>
> Thanks
> CraigT
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20160415/70647e35/attachment-0001.html
> >
>
> --
>
> Message: 3
> Date: Sun, 17 Apr 2016 01:26:29 -0700 (MST)
> From: danigrosu 
> To: openssl-users@openssl.org
> Subject: [openssl-users] Unable to load/add a dynamic engine
> Message-ID: <1460881589415-65563.p...@n7.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi. I am using the OpenSSL 1.0.1f and I built a RSA engine using CUDA code.
> I want to load this engine dynamically, i.e. when I type /# openssl
> engine/,
> I want
> to see my engine id on the list, but all I see is this:
> /(rsax) RSAX engine support
> (dynamic) Dynamic engine loading support/ where the rsax is builtin
>
> I have modified the openssl.cnf file by adding the following lines:
> /openssl_conf = openssl_def
> [openssl_def]
> engines = engine_section
>
> [engine_section]
> foo = gpu_section
>
> [gpu_section]
> dynamic_path =
> /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/librsax_gpu.so
> engine_id = rsax_gpu
> default_algorithms = RSA
> init = 1/
>
> I tried this: /# openssl speed rsa512 -engine rsax_gpu/ and everything went
> well.
>
> Please tell me why I can't load dynamically the engine?
>
>
>
> --
> View this message in context:
> http://openssl.6102.n7.nabble.com/Unable-to-load-add-a-dynamic-engine-tp65563.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
>
>
> --
>
> Message: 4
> Date: Mon, 18 Apr 2016 11:02:40 +0530
> From: James 
> To: openssl-users@openssl.org
> Subject: [openssl-users] Regarding TLS 1.3
> Message-ID:
> <
> cajlnlpfahwa7quxwubug4wtnw0u1izucodyxhz36gb22_m+...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi there,
> In the below link I could see TLS 1.3 support will 

Re: [openssl-users] ssl connect failed

[danigrosu]

Hi.

Are you using the Apache server?

On 18 April 2016 at 14:46, james sqawz [via OpenSSL] <
ml-node+s6102n65566...@n7.nabble.com> wrote:

> Hi all,
>
> Thanks for the providing the forum for discussion on TLS/OPENSSL related
> issue.
>
> I am very new to openssl.
>
> Currently I am trying to implement HTTP over TLS.(TLS Version 1.2)
> For that purpose I send connect request to the server,but connection is
> getting failed.
>
> Following fields are abscent in my ssl packet.
>
> Extension: server name present
> Extension:application layer protocol negotiation
>
> Apart from that I did not set path of Server Certificate.
>
> Shall these impact my connect request.
> Can somebody help.
>
> Thanks
> James
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://openssl.6102.n7.nabble.com/ssl-connect-failed-tp65566.html
> To unsubscribe from OpenSSL - User, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://openssl.6102.n7.nabble.com/ssl-connect-failed-tp65566p65567.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] ssl connect failed

[james sqawz]

Hi all,

Thanks for the providing the forum for discussion on TLS/OPENSSL related
issue.

I am very new to openssl.

Currently I am trying to implement HTTP over TLS.(TLS Version 1.2)
For that purpose I send connect request to the server,but connection is
getting failed.

Following fields are abscent in my ssl packet.

Extension: server name present
Extension:application layer protocol negotiation

Apart from that I did not set path of Server Certificate.

Shall these impact my connect request.
Can somebody help.

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

Re: [openssl-users] Regarding TLS 1.3

[Matt Caswell]

On 18/04/16 06:32, James wrote:
> Hi there,
> In the below link I could see TLS 1.3 support will be added in future
> releases
>  https://www.openssl.org/policies/roadmap.html
> 
> I think the support is not yet added. From when it will be added 

TLS1.3 will not be in the next release which is currently in beta (i.e.
1.1.0). I hope that it will be in the release after that but we have not
yet got a timescale for that.

Matt

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