TLSEXT_TYPE_application_layer_protocol_negotiation was defined in
RFC7301 for which the IANA assigned #16
A non-IANA definition of TLSEXT_TYPE_next_proto_neg = 13172 is used.
The openssl tls code for #ifndef OPENSSL_NO_NEXTPROTONEG all used the
non-iana definition.
This patch corrects openssl to
sorry this should of been part of #2888.
I've rechecked tls1, tls1_1 and tls1_2 on cvs HEAD (today) and they all work
after verifing the order of messages.
apps/openssl s_client -connect nginxtest.openquery.com:4433 -sess_out
/tmp/ss.test -msg -tls1_2; sleep 15; apps/openssl s_client -connect
yep that works.
- Original Message -
From: "Stephen Henson via RT"
To: "daniel black"
Cc: openssl-dev@openssl.org
Sent: Tuesday, 11 December, 2012 3:49:10 AM
Subject: [openssl.org #2888] rfc5077 violation client side causing client
issued tls alert fatal unexpected message
Thank yo
looks like this has been implemented and can be closed
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
correct. the current implementation does exactly this.
this ticket can be closed.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
the correct fix is to use EHLO which is what the current implementation does.
can close this.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@
due to operational reasons (needing a real web server) The server side for
testing is now on https://nginxtest.openquery.com:4433
I tested the openssl client again just compiled from cvs and it still tls
alerts and aborts connection:
apps/openssl s_client -connect nginxtest.openquery.com:4433 -
The last bit of documentation I wrote was really bad. Sorry.
Attached is an improvement now that I've actually used it correctly
(trac.nginx.org/nginx/ticket/120)
Hope this is satisfactory.
--
Daniel Black
SSL_CTX_set_tlsext_ticket_key_cb.pod
Description: Binary data
> RFC5077 3.4 paragraph two
correction rfc5077 3.3 paragraph 2
I've also setup a server for testing:
https://nginxtest.openquery.com/
--
Daniel Black
__
OpenSSL Project http://www.openssl.org
RFC5077 3.4 paragraph two allows for renewing session tickets.
SSL_CTX_set_tlsext_ticket_key_cb facilitates its implemenation on the server
side allowing a return value of 2. Unfortunately the client side doesn't
recognise the sequence of messages generated and aborts.
I've use the SSL_CTX_set
This adds a few message output bits based on IANA TLS registries.
diff --git a/apps/s_cb.c b/apps/s_cb.c
index 2cd7337..833588a 100644
--- a/apps/s_cb.c
+++ b/apps/s_cb.c
@@ -439,6 +439,9 @@ void MS_CALLBACK msg_cb(int write_p, int version, int content_type, const void *
version == DTLS1_V
The SSL_CTX_set_tlsext_ticket_key_cb was introduced here
http://cvs.openssl.org/chngview?cn=17101
as part of a Google consultancy in2008. Since then RC4507bis has become
RFC5077. I've created the documentation for this as attached. I've used the
size limits used internally within in the declara
-crl_check / -crl_check_all don't do anything.
Other status options added to help
verify_return_error needs something better but I can't quite explain it. Some
documentation for it is in the CHANGELOG
Cheers,
Daniel
Index: apps/s_server.c
=
The cert passed to the ocsp app contains ocsp_uri so we can use that if not
specified.
We also can use the CApath to look up a issuer certificate if not specified.
hence a simple line works:
$ openssl ocsp -no_cert_verify -nonce -CApath /etc/ssl/certs/ -cert cert.pem
Response verify OK
cert.p
When I try to get the OCSP url out of a certificate I am presented with the
ironical response:
$ openssl x509 -in cert.pem -ocspurl -nout
unknown option -ocspurl
usage: x509 args
the irony:
$ openssl x509 -in cert.pem -ocspurl -nout
unknown option -ocspurl
usage: x509 args
...
-ocspurl- print OCSP Responder URL(s)
The working bit:
$ openssl x50
On Sat, 31 May 2008 07:13:32 pm Hanno Böck wrote:
> This patch adds some dependencies to the Makefile targets to allow parallel
> make to succeed. Please apply.
>
> (Patch is taken from Gentoo Linux)
as attached?
--
Daniel Black
--
Proudly a Gentoo Linux User.
Gnu-PG/PGP signed and encrypted em
On Sun, 18 May 2008 11:53:35 pm Stephen Henson via RT wrote:
> According to our records, your request has been resolved. If you have any
> further questions or concerns, please respond to this message.
May as well do the documentation too - guess attached.
Looking for other missing undocumented f
just came across this while attempting to work out how to do crl checking.
>From yesterdays openssl snapshot openssl-0.9.8-stable-SNAP-20080517.tar.gz
I assume the second branch is unreachable.
./apps/s_server.c
line 308
else if (strcmp(*argv,"-crl_check") == 0)
19 matches
Mail list logo