TLS renegotiation failure (on receiving application data during handshake)

Hi, We are using openssl 1.0.1c version. We are seeing an issue during client initiated renegotation with TLSv1.2. I was hoping to get some advice from the experts in this mailer. The issue appears to be related to handling of application data in the client side, after it has started the

SMIME CRLF line ending on command line also with -binary flag

Hi, I'm currently using OpenSSL to encrypt and decrypt SMIME messages. A new request from our customer is the possibility to prevent storing decrypted plaintext on harddisk. My idea is now to decrypt the message on command line with openssl.exe smime without -out parameter. The response is

openssl 1.0.1e and X509_STORE_add_cert

Hello guys, I do not know if this is a openssl issue or curl/xmlsec. I have certificates for trust chain (x509) that are not loaded by xmlsec and also does not validate peer on ssl connection. The fails in xmlsec report error at openssl function X509_STORE_add_cert Run environment is arm.

RE: SMIME CRLF line ending on command line also with -binary flag [solved]

Hi, meanwhile I tested the latest openssl release (1.0.1f) and my problem disappeared. Please excuse any trouble. Best regards, Marco Köllner From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Marco Köllner Sent: Dienstag, 14. Januar 2014 13:00 To:

Re: Deadlock in openssl1.0.1e.

and what are all the other threads doing? some other thread must already own this lock and is waiting on something else. -lee On 2014-01-10 13:11, Tayade, Nilesh wrote: Hi, I am facing a deadlock issue on openssl1.0.1e. Please see the stack below. Could anyone please advise if this is a

OCSP result embedded in PKCS #7

Hi, I try to embed an OCSP basic response in a PKCS #7 SignedData object. When I run openssl pkcs7 -inform DER -text -in file.p7c, I get: unable to load PKCS7 object 5024:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:.\crypto\as n1\tasn_dec.c:1319: 5024:error:0D07803A:asn1

Re: TLS renegotiation failure (on receiving application data during handshake)

Shashank, I don't think there is a workaround for this. I've faced this very recently and the only solution is to modify your application protocol in a way that allows renegotiation to happen when things are quiet. I've rambled about it before in OpenSSL forums :

RE: Deadlock in openssl1.0.1e.

Hi, I am not able to understand what’s going wrong, below is the latest stack trace I got. Thread 19 is killed by a watchdog, and it was waiting on a lock. Other threads do not show any lock being held. 21 Thread 23735 0x00373d2a6a8d in nanosleep () at

MODSSL: RFC 2560

Hey all, I am wondering if anyone here could point me in the right direction or even assist with a problem I have having. According to RFC 2560: All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following: -- the CA who

Re: TLS renegotiation failure (on receiving application data during handshake)

Hi Karthik, Thanks a lot for the response. I will also go through the route of modifying the application for renegotiation. -Shashank On 1/14/14 7:44 AM, Karthik Krishnamurthy karthik3...@gmail.com wrote: Shashank, I don't think there is a workaround for this. I've faced this very recently

Re: MODSSL: RFC 2560

On Tue, Jan 14, 2014, socket wrote: Hey all, I am wondering if anyone here could point me in the right direction or even assist with a problem I have having. According to RFC 2560: All definitive response messages SHALL be digitally signed. The key used to sign the response MUST

Re: MODSSL: RFC 2560

What I am saying is that one falls into the delegated trust model, and one does not, but I should be able to validate either because RFC 2560 allows for a Trusted Responder whose public key is trusted by the requester. I am asking if mod_ssl in apache 2.4.x is RFC compliant. it seems to me openssl

Re: MODSSL: RFC 2560

On Tue, Jan 14, 2014, socket wrote: What I am saying is that one falls into the delegated trust model, and one does not, but I should be able to validate either because RFC 2560 allows for a Trusted Responder whose public key is trusted by the requester. I am asking if mod_ssl in apache 2.4.x

Re: [openssl-users] MODSSL: RFC 2560

Bonsoir, Le 14/01/2014 19:44, socket a écrit : Hey all, I am wondering if anyone here could point me in the right direction or even assist with a problem I have having. According to RFC 2560: All definitive response messages SHALL be digitally signed. The key used to sign the response

Re: Deadlock in openssl1.0.1e.

On Tue, Jan 14, 2014, Tayade, Nilesh wrote: Hi, I am not able to understand what???s going wrong, below is the latest stack trace I got. Thread 19 is killed by a watchdog, and it was waiting on a lock. Other threads do not show any lock being held. I'd suggest you modify your locking

How to use the CRL in ssl connection

Hello everyone, I have a question about the crl in ssl server, I load the crl's file successed, but when one new connection come in, SSL_accept return NULL, whether the client cert is in crl's file.l certainly if I didn't load crl file, the ssl server is very ok. and the ssl_accept