Quoting joshi chandran joshichandran...@gmail.com:
Hi ALL,
I have Applied this patch http://cvs.openssl.org/chngview?cn=18791
on openssl 9.8k . when i have tried renegotiation , it is
disconnecting the connection .
SSL_accept:before accept initialization
TLS 1.0 Alert [length 0002], fatal
Hi Eren!
On Mon, 16 Nov 2009 01:19:11 +0200 Eren Türkay e...@pardus.org.tr
wrote:
The only way to get established ssl handshake openssl s_client is
to use the -ssl3 option. In some cases such as:
This is the same situation in 0.9.8-stable branch, too. The only way
to connect to the
The TLS client in openssl-1.0.0 branch aborts the connection if
SSL_OP_ALLOW_UNSAFE_RENEGOTIATION (or SSL_OP_ALL) flag is not set by the
calling application and the connected server does not return the
extension in the server hello message. Unfortunately too many
applications do not set SSL_OP_ALL
Hi,
just noticed that the s_client man page [1] doesn't mention the XMPP
support for -starttls which has been introduced with 0.9.8j.
-starttls protocol
send the protocol-specific message(s) to switch to TLS
for communication. protocol is a keyword for the
Hi,
I got some weird error. help needed urgent.
SSL_write() is returned with error SSL3_WRITE_PENDING:bad write retry.
I have tried with flags PARTIAL_WRITE and AUTO_RETRY and MOVING
BUFFER.
Still i am facing this problem. Any temporary workaround will also be
appreciated.
Thanks Regards,
smitha daggubati wrote:
Does openssl have support for SHA-2. ?
I know that SHA-2 is part of the crypto library but looking at the way the
context is setup in ssl_ctx_new we are setiing up
ret-sha1=EVP_get_digestbyname(ssl3-sha1))
So is there a way to establish an openssl connection using
Marc,
Thanks for the reply.
On Wed, Nov 18, 2009 at 2:54 PM, Jean-Marc Desperrier jmd...@free.frwrote:
smitha daggubati wrote:
Does openssl have support for SHA-2. ?
I know that SHA-2 is part of the crypto library but looking at the way
the
context is setup in ssl_ctx_new we are setiing
Thanks for the reply,
I have control of the CA in creating certificates. The CRL contains the SN
of the certs that are revoked. I also noticed we have an SRL file which shows
the last SN used for the certificates and it increments by 1 for every
certificate created. You said:
Having the same
The CRL identifies certificates by serial number only; the issuer is
implied. You cannot have a CRL that revokes certificates from more than one
issuing certificate. The only parameter from a certificate to determine if
it is revoked is the serial number. However, it's important to note that a
I tried replacing the SRL SN and it does create a new cert with same SN with
only the CN being different (since it is unique). I do get the problem with CRL
trying to revoke the 2nd cert with the same SN.
I get:
ERROR:name does not match /C=US/ST=foo/L=bar/CN=2
R 09234567Z
Er, *why* are you dropping the connection when renegotiation is tried?
The appropriate response, per RFC, if you don't want to renegotiate
is to send a warning no_renegotiation alert.
-Kyle H
On Mon, Nov 16, 2009 at 10:40 PM, joshi chandra
joshichandran...@gmail.com wrote:
Hi ,
I have lot
Hello. Different versions of OpenSSL install shared libraries with
different names, e.g. libssl.0.9.8.extension and libssl.
1.0.0.extension. However, engines are always installed under $prefix/
lib/engines. Having said that,
a) do/will engines follow the same semantics of OpenSSL versions,
Creating a CRL using openssl does nothing else than reading
the certificatedatabase and creating an entry for all serialnumbers
that have a R.
You can create such a file by hand.
__
OpenSSL Project
I think it's pretty well understood at this point that 0.9.8l does
the wrong thing when a client asks for a renegotiation (hangs the
negotiation, basically). But it looks to me like 0.9.8-stable also
gets it wrong.
AFAICT by code inspection 0.9.8-stable (yesterday's snapshot) sends
a Fatal
14 matches
Mail list logo
