|= X509_V_FLAG_CRL_CHECK;
}
else if (strcmp(*argv,-crl_check) == 0)
{
vflags |= X509_V_FLAG_CRL_CHECK|
X509_V_FLAG_CRL_CHECK_ALL;
}
--
Daniel Black
--
Proudly a Gentoo Linux User.
Gnu-PG
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 email
The check for SSL_OP_NO_TICKET is performed as the first line of code in the
function tls1_process_ticket so there's no need to check it later in the same
function. Attached patch removes the second check.
Index: ./ssl/t1_lib.c
===
for the dup on openssl-dev@ - only just found the rt.
--
Daniel Black
--
Proudly a Gentoo Linux User.
Gnu-PG/PGP signed and encrypted email preferred
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x76677097
GPG Signature D934 5397 A84A 6366 9687 9EB2 861A 4ABA 7667 7097
signature.asc
'BIO_printf(bio_err, -' s_server.c | cut -f 2 -d ' ' |
xargs -n1 -t -I{} fgrep -- {}\ s_server.c
s_client is missing doco for:
-crl_check
-crl_check_all
-verify_return_error
-prexit
-timeout
-no_comp
other apps untested.
--
Daniel Black
--
Proudly a Gentoo Linux User.
Gnu-PG/PGP signed
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 email
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 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
in the declaration for clarity.
--
Daniel Black, Engineer @ Open Query (http://openquery.com)
Remote expertise maintenance for MySQL/MariaDB server environments.
SSL_CTX_set_tlsext_ticket_key_cb.pod
Description: Binary data
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 ==
:28:20 [info] 14977#0: *20 SSL_do_handshake() failed (SSL:
error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message) while SSL
handshaking, client: 127.0.0.1, server: localhost
--
Daniel Black
__
OpenSSL Project
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
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
:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected
message:s3_both.c:460:
--
Daniel Black
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev
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
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
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
yep that works.
- Original Message -
From: Stephen Henson via RT r...@openssl.org
To: daniel black daniel.bl...@openquery.com
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
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
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
20 matches
Mail list logo
