thanks dave and martin. with all that information i think i should start
the process again. Do you have some materials that have step by step
process of configuring two way connections
On Fri, Jan 10, 2014 at 7:30 AM, Dave Thompson wrote:
> > From: owner-openssl-users On Behalf Of Martin Hecht
>
I found this post：
https://groups.google.com/forum/#!topic/mailing.openssl.dev/ZLQcp87Zx8A
This is the right solution
Lee
On Fri, Jan 10, 2014 at 1:04 PM, yueyue papa wrote:
> I use these macro to disable TLSEXT,
> CPPOPTS +=-DOPENSSL_NO_TLSEXT -DOPENSSL_NO_HEARTBEATS -DOPENSSL_NO_SRTP
> -DO
You are complete right. I disabled TLSEXT, because of the code size.
Up to now, the result is very clear now.
Lee
On Fri, Jan 10, 2014 at 12:30 PM, Dave Thompson wrote:
> (Due to Outlook upgrade, I can no longer reply inline to richtext. Sorry.)
>
>
>
> Is it possible your failing client open
I am also disable the TLSEXT in the openSSL 0.9.8. It is a strange, why
server gave different response.
It is true that server give different response. (openSSL request is also
different.)
Lee
On Fri, Jan 10, 2014 at 12:44 PM, yueyue papa wrote:
> You are complete right. I disabled TLSEXT
I use these macro to disable TLSEXT,
CPPOPTS +=-DOPENSSL_NO_TLSEXT -DOPENSSL_NO_HEARTBEATS -DOPENSSL_NO_SRTP
-DOPENSSL_NO_DTLS1
whether there is other macro is required to set, so openSSL 1.0.1 won't
tell server TLS features
Lee
On Fri, Jan 10, 2014 at 12:30 PM, Dave Thompson wrote:
> (Due to
(Due to Outlook upgrade, I can no longer reply inline to richtext. Sorry.)
Is it possible your failing client openssl was built with -no-tlsext ?
Both ServerHello replies do contain the RI extension (because the
cipherlist contained SCSV_ERI); if the code to parse extensions
isn't executed
> From: owner-openssl-users On Behalf Of Martin Hecht
> Sent: Thursday, January 09, 2014 11:54
Generally good explanation, but a few quibbles:
> I don't know what exactly you are doing, so it is difficult to speculate
> why you are receiving code 19.
>
> Some information is exchanged during esta
#
read from 0x1fee3f0 [0x1e6ea5b] (5 bytes => 5 (0x5))
- 16 03 00 00 51Q
read from 0x1fee3f0 [0x1e6ea60] (81 bytes => 81 (0x51))
- 02 00 00 4d 03 00 52 cf-5a 99 be 19 c0 7e 80 55 ...M..R.Z~.U
0010 - d6 4c 2d af 05 41 f8 19-79 24 a3 66 ba 8
The 0.9.8h openSSL version is working correct in my system. Recently, I
updated to 1.0.1e openSSL, I meet the SSL connection failure.
The problem is in here
case SSL3_ST_CR_SRVR_HELLO_A:
case SSL3_ST_CR_SRVR_HELLO_B:
ret=ssl3_get_server_hello(s);
if (ret <= 0)
## My embedded environment con
On Thu, Jan 09, 2014, Jakob Bohm wrote:
> On 1/9/2014 8:14 PM, Dr. Stephen Henson wrote:
> >On Thu, Jan 09, 2014, Bin Lu wrote:
> >
> >> Here is the problem, in cert_crl():
> >>
> >>/* The rules changed for this... previously if a CRL contained
> >> * unhandled critical extension
On 09.01.2014 19:48, Watson, Patrick wrote:
I'd recommend using VerifyVersionInfo:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms725492(v=vs.85).aspx.
It's supported from Win2k onward and isn't deprecated as of Win 8.1. I don't
remember for sure if it's present in Windows CE and un
On 1/9/2014 8:14 PM, Dr. Stephen Henson wrote:
On Thu, Jan 09, 2014, Bin Lu wrote:
Here is the problem, in cert_crl():
/* The rules changed for this... previously if a CRL contained
* unhandled critical extensions it could still be used to indicate
* a certificate
On Thu, Jan 09, 2014, Bin Lu wrote:
> Here is the problem, in cert_crl():
>
>/* The rules changed for this... previously if a CRL contained
> * unhandled critical extensions it could still be used to indicate
> * a certificate was revoked. This has since been changed si
I'd recommend using VerifyVersionInfo:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms725492(v=vs.85).aspx.
It's supported from Win2k onward and isn't deprecated as of Win 8.1. I don't
remember for sure if it's present in Windows CE and unfortunately I don't have
my CE documentation
On 1/9/2014 6:46 AM, Dongsheng Song wrote:
[1] GetVersionEx may be altered or unavailable for releases after
Windows 8.1. Instead, use the Version Helper APIs.
> [1]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx
Scandalous! According to that page, Microso
Here is the problem, in cert_crl():
/* The rules changed for this... previously if a CRL contained
* unhandled critical extensions it could still be used to indicate
* a certificate was revoked. This has since been changed since
* critical extension can change th
I don't know what exactly you are doing, so it is difficult to speculate
why you are receiving code 19.
Some information is exchanged during establishment of the ssl
connection. For example if you have a web server and a browser, the web
server shows the host certificate to the browser and the br
On Thu, Jan 09, 2014, Eric J. Van der Velden wrote:
> There is a asm and a C implementation of sha1_block_data_order, in
> sha256-x86_64.s and in sha1dgst.c When I do,
>
> $ gdb openssl
> (gdb) r dgst -sha1 data.txt
>
> I see that the asm implementation is taken. What do I have to do so the C
>
There is a asm and a C implementation of sha1_block_data_order, in
sha256-x86_64.s and in sha1dgst.c When I do,
$ gdb openssl
(gdb) r dgst -sha1 data.txt
I see that the asm implementation is taken. What do I have to do so the C
implementation is taken?
Thanks,
Eric J.
could you please explain the last reason.
On Thu, Jan 9, 2014 at 3:38 PM, Martin Hecht wrote:
> X509_V_OK would be code 0
> 19 means that the CA certificate could be found, the chain could be
> built and verified completely up to the CA certificate but the latter is
> not trusted. (see http://
On Thu, Jan 09, 2014, Bin Lu wrote:
> Hi,
>
> I have a piece of code doing CRL revocation check which worked fine with
> 0.9.8 but now failing in 1.0.1.
> The code does something like:
> X509_STORE_add_crl(store,crl);
> X509_STORE_CTX_init(ctx, store, cert, NULL);
>
On Thu, Jan 09, 2014, Abdul Anshad wrote:
> Hello All,
>
> I have a set up in which i have installed OpenSSL-1.0.0l and httpd-2.4.7.
>
> httpd-2.4.7 was compiled against OpenSSL-1.0.1e.
>
> Now, when i try to start httpd-2.4.7 with mod_ssl enabled ( OpenSSL
> installed version is 1.0.0l ) it th
X509_V_OK would be code 0
19 means that the CA certificate could be found, the chain could be
built and verified completely up to the CA certificate but the latter is
not trusted. (see http://www.openssl.org/docs/apps/verify.html)
ah, for some things to work correctly, the file name must be the su
thanks martin. i made the changes and now im getting
Verify return code: 19 (self signed certificate in certificate chain)
is this ok, or i need code 0
On Thu, Jan 9, 2014 at 1:33 PM, Martin Hecht wrote:
> I was thinking about manual verification of certificates on the command
> line. From wha
I was thinking about manual verification of certificates on the command
line. From what you wrote now, it seems that you are using some calls to
the openssl library in a client-server application, maybe via other
tools/webserver or so, and I understand that the server certificate was
issued by a di
25 matches
Mail list logo
