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 return the error msg:
error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
the code:
int ret = SSL_CTX_load_verify_locations(ap_ctx, a_revokeCrl.c_str(), NULL);
if ( ret == 0 )
{
printf("SSL_CTX_load_verify_locations(crl) return 0.");
}
else
{
X509_STORE *pCaCertStore = SSL_CTX_get_cert_store(ap_ctx);
X509_STORE_set_flags(pCaCertStore, X509_V_FLAG_CRL_CHECK);
}
openssl version:OpenSSL 0.9.8k
This question was puzzled me two days, please superman help me, thank u very
much!
best regards!
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 callback to store the location (file, line number) for the lock in question (18 which is CRYPTO_LOCK_RAND) when a lock is acquired successfully and clear it when the lock is released. Then when you get a deadlock you can see the last instance that held (but did not release) the lock. You could try compiling with LOCK_DEBUG but that will create a *lot* of output. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 MUST belong to one of the following: -- the CA who issued the certificate in question * -- a Trusted Responder whose public key is trusted by the requester* -- a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA [...] I am able to successfully validate cc1 and any other client certificates issued from ia1. However, when I try to use cc2, I get the following error: *SSL Library Error: error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted* Looking at a post in the past: http://openssl.6102.n7.nabble.com/OCSP-basic-verify-root-ca-not-trusted-td24451.html it seems that the RFC should allow me to explicitly declare a trusted responder certificate for the client machine (in this case the client is the httpd 2.4 server). However it doesn't seem that mod_ssl allows me to declare this. I would like to know: Am i right in thinking I should be able to do this? That's a strange question. You *want* to do this, so you have to find a software that allows this. If you randomly chose a software that doesn't, you may have some hard time explaining that this software *should* allow this. Who currently supports mod_ssl and how would i present a change request? mod_ssl is part of Apache HTTP server, so it's fully maintained by the Apache foundation, you should visit http://projects.apache.org/projects/http_server.html Does mod_ssl currently support this feature unbenounced to me? It seems it doesn't, but I only looked at the documentation, not the source code. if not, would anyone be willing to teach me how to modify mod_ssl to support something like: *'SSLOCSPTrusted_responder /etc/pki/tls/certs/trustedresponder.pem'* You'll have to learn how Apache modules are coded, add a configuration directive for mod_ssl, add a field in this module's config structure to hold the VA file, and use whatever this field contains when OCSP validation happens (that's where OpenSSL comes in). Optionally, you may find interesting to contribute your enhancement back to Apache httpd, or you'll have to apply your patch each time you want to upgrade your httpd version for security reasons. I bought "The Apache Modules Book", by Nick Kew, and found it helpful for my projects. Working with OpenSSL since its very beginning helps a lot. Other applications like openssl and corestreet desktop validation client allow you to explicitly configure a trusted responder cert. eg: openssl ocsp -CAfile rca2-issuer ia2 -cert cc2 -VAfile ocsp1 -url http://rsp.domain.com:80 That means the PKI core (OpenSSL) is able to do what you're looking for. That's a good start.
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 is RFC compliant. it seems to me openssl > supports this explicitly via the -VAflag, but mod_ssl doesn't. > You don't need the -VAflag option. You can add explicit trust to the root PEM file of the responder chain. See the "ocsp" manual page for details. If you include that trusted root CA PEM file in the mod_ssl trusted certificate store it should work. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 supports this explicitly via the -VAflag, but mod_ssl doesn't. *Trustpoint 1:* [root@va][/usr/local/apache2/conf] openssl verify -CAfile rca1 cc1 cc1: OK [root@va][/usr/local/apache2/conf] openssl ocsp -CAfile rca1 -issuer rca1 -cert cc1 -no_nonce -url http://localhost:3503 Response verify OK cc1: good This Update: Jan 10 21:16:11 2014 GMT Next Update: Jan 18 09:36:11 2014 GMT *Trust Point 2:* [root@va][/usr/local/apache2/conf] openssl verify -CAfile rca2 ia2 ia2: OK [root@va][/usr/local/apache2/conf] openssl verify -CAfile rca2 cc2 cc2: OK [root@va][/usr/local/apache2/conf] openssl ocsp -CAfile rca2 -issuer ia2 -cert cc2 -no_nonce -url http://localhost:3503 Response Verify Failure 140278240200520:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:126:Verify error:unable to get local issuer certificate cc2: good This Update: Jan 14 10:02:14 2014 GMT Next Update: Feb 14 10:02:14 2014 GMT *But if i explicitly declare the trusted VA:*I get no errors. [root@va][/usr/local/apache2/conf] openssl ocsp -CAfile rca2 -issuer ia2 -cert cc2 -no_nonce *-VAfile ocsp1* -url http://localhost:3503 Response verify OK cc2: good This Update: Jan 14 10:02:14 2014 GMT Next Update: Feb 14 10:02:14 2014 GMT -- View this message in context: http://openssl.6102.n7.nabble.com/MODSSL-RFC-2560-tp48136p48141.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 belong to one of the following: > >-- the CA who issued the certificate in question > * -- a Trusted Responder whose public key is trusted by the requester* >-- a CA Designated Responder (Authorized Responder) who holds a > specially marked certificate issued directly by the CA, indicating > that the responder may issue OCSP responses for that CA > > I have Root CA1(RCA1), and Root Ca2(RCA2). also, I have Intermediate > Authority 1(IA1) and Intermediate Authority 2 (IA2). I have an OCSP signing > certificate issued from IA1 (ocsp1). > I have apache 2.4 configured with trust for rca1, rca2, ia1, ia2 and I am > able to use client authentication to login with either client cert 1(cc1), > or Clicnet Cert 2(cc2). > > However, when I enable OCSP it acts differently: > SSLVerifyClient on > SSLVerifyDepth 4 > SSLOCSPEnable on > SSLOCSPDefaultResponder http://rsp.domain.com:80/ > SSLOCSPOverrideResponder on > > I am able to successfully validate cc1 and any other client certificates > issued from ia1. However, when I try to use cc2, I get the following error: > *SSL Library Error: error:27069070:OCSP routines:OCSP_basic_verify:root ca > not trusted* > It isn't entirely clear which certificate belongs to which chain and what the chains are. I'd say from your description that one client certificate supports the OCSP delegated model directly and doesn't need explicit trust while the other does not. It should be possible to add explicit trust to the root CA. See the ocsp manual page for OpenSSL for details. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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" wrote: >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 : > >http://marc.info/?l=openssl-users&m=137873769824420&w=2 > >You can also read my SO post: > >http://stackoverflow.com/questions/18728355/ssl-renegotiation-with-full-du >plex-socket-communication > >My understanding from all this is that OpenSSL doesn't like when >application data is received while waiting for SSL handshake data. In >a way, it makes sense because it is hard to do a handshake if there is >a lot of application data pending in the underlying TCP pipe. > >As suggested above, make room for SSL renegotiation by modifying your >application protocol so that renegotiation happens when the TCP pipe >is empty on either side of the connection. > >Hope this helps. > >Thanks, >Karthik > >On Mon, Jan 13, 2014 at 7:30 PM, Shashank Vinchurkar (sha1) > wrote: >> 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 handshake for the renegotaiton ( >>We >> have built a mechanism to indicate to the client to start rengotiation >>based >> on configuration trigger). Client doesn's seem to like application data >> after it has started renegotiation, that results in an alert from the >>client >> to the server. Our application is a full duplex, client server >>application, >> where both sides can send data to each other asynchronously. Application >> sockets are in non-blocking mode. It seems this issue has been >>reported in >> openssl mailing lists a few times in the past, though I couldn't find >>any >> resolution of the issue. Attaching some of the links related to the >>issue. >> >> http://rt.openssl.org/Ticket/Display.html?id=1019 >> http://rt.openssl.org/Ticket/Display.html?id=2146 >> http://rt.openssl.org/Ticket/Display.html?id=2481 >> >> Here are the relevent logs from the client side on receving the >>application >> data: >> >> 1.Sent handshake msg : version [301] : content_type [16] len [73] >> 2.Sent handshake msg : version [301] : content_type [15] len [2] >> 3.SSL_ERROR_SSL:error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected >> record:[file:line] [s3_pkt.c:1405] >> >> Here are the logs on the server side: >> >> 1.Received handshake msg : version [301] : content_type [16]len [73] >> 2. Sent handshake msg : version [301] : content_type [16] len [82] >> 3. Sent handshake msg : version [301] : content_type [16] len [30] >> 4. Sent handshake msg : version [301] : content_type [16] len [4] >> 5. Received handshake msg : version [301] : content_type [15]len [2] >> 6. error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected >> message:[file:line] [s3_pkt.c:1252] >> 7. error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake >> failure:[file:line] [s3_pkt.c:1330] >> >> Please let me know if there is a patch or workaround for this issue. I >>will >> be happy to provide any additional information. >> >> Thanks for the help. >> -Shashank >> >__ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 issued the certificate in question * -- a Trusted Responder whose public key is trusted by the requester* -- a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA I have Root CA1(RCA1), and Root Ca2(RCA2). also, I have Intermediate Authority 1(IA1) and Intermediate Authority 2 (IA2). I have an OCSP signing certificate issued from IA1 (ocsp1). I have apache 2.4 configured with trust for rca1, rca2, ia1, ia2 and I am able to use client authentication to login with either client cert 1(cc1), or Clicnet Cert 2(cc2). However, when I enable OCSP it acts differently: SSLVerifyClient on SSLVerifyDepth 4 SSLOCSPEnable on SSLOCSPDefaultResponder http://rsp.domain.com:80/ SSLOCSPOverrideResponder on I am able to successfully validate cc1 and any other client certificates issued from ia1. However, when I try to use cc2, I get the following error: *SSL Library Error: error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted* Looking at a post in the past: http://openssl.6102.n7.nabble.com/OCSP-basic-verify-root-ca-not-trusted-td24451.html it seems that the RFC should allow me to explicitly declare a trusted responder certificate for the client machine (in this case the client is the httpd 2.4 server). However it doesn't seem that mod_ssl allows me to declare this. I would like to know: Am i right in thinking I should be able to do this? Who currently supports mod_ssl and how would i present a change request? Does mod_ssl currently support this feature unbenounced to me? if not, would anyone be willing to teach me how to modify mod_ssl to support something like: *'SSLOCSPTrusted_responder /etc/pki/tls/certs/trustedresponder.pem'* Other applications like openssl and corestreet desktop validation client allow you to explicitly configure a trusted responder cert. eg: openssl ocsp -CAfile rca2-issuer ia2 -cert cc2 -VAfile ocsp1 -url http://rsp.domain.com:80 cc2: good This Update: Jan 14 10:02:14 2014 GMT Next Update: Feb 14 10:02:14 2014 GMT -- View this message in context: http://openssl.6102.n7.nabble.com/MODSSL-RFC-2560-tp48136.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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
../sysdeps/unix/syscall-template.S:82
20 Thread 23752 0x00373d2da4f3 in select () at
../sysdeps/unix/syscall-template.S:82
19 Thread 23754 0x00373da0ed70 in __pause_nocancel () at
../sysdeps/unix/syscall-template.S:82
18 Thread 23724 0x00373da0e7ed in accept () at
../sysdeps/unix/syscall-template.S:82
17 Thread 23733 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
16 Thread 23704 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
15 Thread 23732 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
14 Thread 23705 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
13 Thread 23753 0x00373da0e963 in recvfrom () at
../sysdeps/unix/syscall-template.S:82
12 Thread 23563 0x00373d2a6a8d in nanosleep () at
../sysdeps/unix/syscall-template.S:82
11 Thread 23734 0x00373da0e7ed in accept () at
../sysdeps/unix/syscall-template.S:82
10 Thread 23751 0x00373d2a6a8d in nanosleep () at
../sysdeps/unix/syscall-template.S:82
9 Thread 23756 0x00373d2c8c07 in sched_yield () at
../sysdeps/unix/syscall-template.S:82
8 Thread 23757 0x00373d2c8c07 in sched_yield () at
../sysdeps/unix/syscall-template.S:82
7 Thread 23755 0x00373d2c8c07 in sched_yield () at
../sysdeps/unix/syscall-template.S:82
6 Thread 23736 0x00373d2c8c07 in sched_yield () at
../sysdeps/unix/syscall-template.S:82
5 Thread 23759 0x00373d2c8c07 in sched_yield () at
../sysdeps/unix/syscall-template.S:82
4 Thread 23728 0x00373d2c8c07 in sched_yield () at
../sysdeps/unix/syscall-template.S:82
3 Thread 23731 0x00373d2c8c07 in sched_yield () at
../sysdeps/unix/syscall-template.S:82
* 2 Thread 23703 0x00373da0e8ec in __libc_recv (fd=,
buf=, n=, flags=)
at ../sysdeps/unix/sysv/linux/x86_64/recv.c:34
1 Thread 23758 0x00373d2329a5 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
(gdb) thread 19
[Switching to thread 19 (Thread 23754)]#0 0x00373da0ed70 in
__pause_nocancel () at ../sysdeps/unix/syscall-template.S:82
82 ../sysdeps/unix/syscall-template.S: No such file or directory.
in ../sysdeps/unix/syscall-template.S
(gdb) bt
#0 0x00373da0ed70 in __pause_nocancel () at
../sysdeps/unix/syscall-template.S:82
#1 0x00373da08f0b in __pthread_mutex_lock_full (mutex=0x7418438) at
pthread_mutex_lock.c:316
#2 0x009f3591 in locking_function (mode=9, n=19, file=0x3c79bdf93b
, line=387) at ssl_prf.c:665
#3 0x003c79b49403 in ?? ()
--
Thanks,
Nilesh
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Lee Dilkie
Sent: Tuesday, January 14, 2014 7:25 PM
To: openssl-users@openssl.org
Subject: 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 known bug? Is there any workaround/fix?
FIPS is disabled on my system.
(gdb) bt full
#0 __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
No locals.
#1 0x00373da092c5 in _L_lock_868 () from /lib64/libpthread.so.0 No symbol
table info available.
#2 0x00373da09197 in __pthread_mutex_lock (mutex=0x7418430) at
pthread_mutex_lock.c:61
ignore1 = 128
ignore2 = 121734192
ignore3 = -512
type =
id = 10428
#3 0x009f3585 in locking_function (mode=9, n=18, file=0x3c79bdf93b
"md_rand.c", line=228) at ssl_prf.c:653 No locals.
#4 0x003c79b48f69 in ?? () from /usr/lib64/libcrypto.so.10 No symbol table
info available.
#5 0x003c79b06c72 in ?? () from /usr/lib64/libcrypto.so.10 No symbol table
info available.
#6 0x003c79b06aa0 in ?? () from /usr/lib64/libcrypto.so.10 No symbol table
info available.
#7 0x003c79b07be2 in BN_BLINDING_create_param () from
/usr/lib64/libcrypto.so.10 No symbol table info available.
#8 0x003c79b07d6a in BN_BLINDING_update () from /usr/lib64/libcrypto.so.10
No symbol table info available.
#9 0x003c79b07e56 in BN_BLINDING_convert_ex () from
/usr/lib64/libcrypto.so.10 No symbol table info available.
--
Thanks,
Nilesh
Sent via CanvasHD:��I"Ϯ��r�m
(���Z+�K‑�+1���x
��h���[�z�(���Z+�
��f�y�‑�f���h��)z{,��
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 : http://marc.info/?l=openssl-users&m=137873769824420&w=2 You can also read my SO post: http://stackoverflow.com/questions/18728355/ssl-renegotiation-with-full-duplex-socket-communication My understanding from all this is that OpenSSL doesn't like when application data is received while waiting for SSL handshake data. In a way, it makes sense because it is hard to do a handshake if there is a lot of application data pending in the underlying TCP pipe. As suggested above, make room for SSL renegotiation by modifying your application protocol so that renegotiation happens when the TCP pipe is empty on either side of the connection. Hope this helps. Thanks, Karthik On Mon, Jan 13, 2014 at 7:30 PM, Shashank Vinchurkar (sha1) wrote: > 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 handshake for the renegotaiton ( We > have built a mechanism to indicate to the client to start rengotiation based > on configuration trigger). Client doesn's seem to like application data > after it has started renegotiation, that results in an alert from the client > to the server. Our application is a full duplex, client server application, > where both sides can send data to each other asynchronously. Application > sockets are in non-blocking mode. It seems this issue has been reported in > openssl mailing lists a few times in the past, though I couldn't find any > resolution of the issue. Attaching some of the links related to the issue. > > http://rt.openssl.org/Ticket/Display.html?id=1019 > http://rt.openssl.org/Ticket/Display.html?id=2146 > http://rt.openssl.org/Ticket/Display.html?id=2481 > > Here are the relevent logs from the client side on receving the application > data: > > 1.Sent handshake msg : version [301] : content_type [16] len [73] > 2.Sent handshake msg : version [301] : content_type [15] len [2] > 3.SSL_ERROR_SSL:error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected > record:[file:line] [s3_pkt.c:1405] > > Here are the logs on the server side: > > 1.Received handshake msg : version [301] : content_type [16]len [73] > 2. Sent handshake msg : version [301] : content_type [16] len [82] > 3. Sent handshake msg : version [301] : content_type [16] len [30] > 4. Sent handshake msg : version [301] : content_type [16] len [4] > 5. Received handshake msg : version [301] : content_type [15]len [2] > 6. error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected > message:[file:line] [s3_pkt.c:1252] > 7. error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake > failure:[file:line] [s3_pkt.c:1330] > > Please let me know if there is a patch or workaround for this issue. I will > be happy to provide any additional information. > > Thanks for the help. > -Shashank > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:.\ crypto\asn1\tasn_dec.c:381:Type=X509_CRL 5024:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 e rror:.\crypto\asn1\tasn_dec.c:711:Field=crl, Type=PKCS7_SIGNED 5024:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 e rror:.\crypto\asn1\tasn_dec.c:751: 5024:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 erro r:.\crypto\asn1\tasn_dec.c:579:Field=d.sign, Type=PKCS7 An asn1parse of the file give this (truncated to relevant area): 2976:d=3 hl=4 l=1454 cons: cont [ 1 ] 2980:d=4 hl=4 l=1450 cons: cont [ 1 ] 2984:d=5 hl=2 l= 8 prim: OBJECT:1.3.6.1.5.5.7.16.2 2994:d=5 hl=4 l=1436 cons: SEQUENCE 2998:d=6 hl=2 l= 1 prim: ENUMERATED:00 3001:d=6 hl=4 l=1429 cons: cont [ 0 ] 3005:d=7 hl=4 l=1425 cons: SEQUENCE 3009:d=8 hl=2 l= 9 prim: OBJECT:Basic OCSP Response 3020:d=8 hl=4 l=1410 prim: OCTET STRING [HEX DUMP]:3082057E30820117A1819F... And here is the ASN.1 tree as parsed by another program, with non-relevant nodes folded: SEQUENCE (2 elem) -OBJECT IDENTIFIER 1.2.840.113549.1.7.2 -[0] (1 elem) --SEQUENCE (6 elem) ---INTEGER 5 ---SET (1 elem) folded ---SEQUENCE (2 elem) folded ---[0] (3 elem) folded ---[1] (1 elem) [1] (2 elem) -OBJECT IDENTIFIER 1.3.6.1.5.5.7.16.2 -SEQUENCE (2 elem) --ENUMERATED --[0] (1 elem) ---SEQUENCE (2 elem) OBJECT IDENTIFIER 1.3.6.1.5.5.7.48.1.1 OCTECT STRING (1 elem) -SEQUENCE (4 elem) folded ---SET (1 elem) folded I only get the error when the OCSP response is embedded. All I could find on the internet about this, is another post to this list but I don't see what's wrong in my file. Has anyone an idea why OpenSSL is rejecting this file? Thank you Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 known bug? Is there any
> workaround/fix? FIPS is disabled on my system.
>
> (gdb) bt full
> #0 __lll_lock_wait () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
> No locals.
> #1 0x00373da092c5 in _L_lock_868 () from /lib64/libpthread.so.0 No
> symbol table info available.
> #2 0x00373da09197 in __pthread_mutex_lock (mutex=0x7418430) at
> pthread_mutex_lock.c:61
> ignore1 = 128
> ignore2 = 121734192
> ignore3 = -512
> type =
> id = 10428
> #3 0x009f3585 in locking_function (mode=9, n=18, file=0x3c79bdf93b
> "md_rand.c", line=228) at ssl_prf.c:653 No locals.
> #4 0x003c79b48f69 in ?? () from /usr/lib64/libcrypto.so.10 No symbol
> table info available.
> #5 0x003c79b06c72 in ?? () from /usr/lib64/libcrypto.so.10 No symbol
> table info available.
> #6 0x003c79b06aa0 in ?? () from /usr/lib64/libcrypto.so.10 No symbol
> table info available.
> #7 0x003c79b07be2 in BN_BLINDING_create_param () from
> /usr/lib64/libcrypto.so.10 No symbol table info available.
> #8 0x003c79b07d6a in BN_BLINDING_update () from
> /usr/lib64/libcrypto.so.10 No symbol table info available.
> #9 0x003c79b07e56 in BN_BLINDING_convert_ex () from
> /usr/lib64/libcrypto.so.10 No symbol table info available.
>
> --
> Thanks,
> Nilesh
> Sent via CanvasHD:??I"???r?m
> (???Z+?K ?+1???x ??h???[?z?(???Z+? ??f?y????? ?f???h??)z{,??
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: openssl-users@openssl.org Subject: 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 stored in memory for further operations. This works fine for Text files and I'm very happy with it. But when working with binary data (e.g.: decrypting packed files to reduce network load) I observe changes in decrypted output that results in corrupt zip/gzip file. I've read in documentation that SMIME specification expects CRLF line ending and openssl will adapt this by default to every message when -binary flag is not set. In my case I use this flag for encryption and for decryption and this works when the output is saved to file by openssl. But on command line output CRLF resists regardless of the -binary flag. The current revision on customer side is 0.9.8k Any hints or ideas? Thanks for your help.
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 Run environment is arm. xmlsec library on host (x86) it works it works is same version. On host openssl is older.the default version from ubuntu 12.04 and i have no problems ..neither with errors from xmlsec neither from curl. *certifcates have same md5sum both on host and arm environment. If you know a patch that is must apply please share. Thanks, Ionut
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 stored in memory for further operations. This works fine for Text files and I'm very happy with it. But when working with binary data (e.g.: decrypting packed files to reduce network load) I observe changes in decrypted output that results in corrupt zip/gzip file. I've read in documentation that SMIME specification expects CRLF line ending and openssl will adapt this by default to every message when -binary flag is not set. In my case I use this flag for encryption and for decryption and this works when the output is saved to file by openssl. But on command line output CRLF resists regardless of the -binary flag. The current revision on customer side is 0.9.8k Any hints or ideas? Thanks for your help.
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 handshake for the renegotaiton ( We have built a mechanism to indicate to the client to start rengotiation based on configuration trigger). Client doesn's seem to like application data after it has started renegotiation, that results in an alert from the client to the server. Our application is a full duplex, client server application, where both sides can send data to each other asynchronously. Application sockets are in non-blocking mode. It seems this issue has been reported in openssl mailing lists a few times in the past, though I couldn't find any resolution of the issue. Attaching some of the links related to the issue. http://rt.openssl.org/Ticket/Display.html?id=1019 http://rt.openssl.org/Ticket/Display.html?id=2146 http://rt.openssl.org/Ticket/Display.html?id=2481 Here are the relevent logs from the client side on receving the application data: 1.Sent handshake msg : version [301] : content_type [16] len [73] 2.Sent handshake msg : version [301] : content_type [15] len [2] 3.SSL_ERROR_SSL:error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected record:[file:line] [s3_pkt.c:1405] Here are the logs on the server side: 1.Received handshake msg : version [301] : content_type [16]len [73] 2. Sent handshake msg : version [301] : content_type [16] len [82] 3. Sent handshake msg : version [301] : content_type [16] len [30] 4. Sent handshake msg : version [301] : content_type [16] len [4] 5. Received handshake msg : version [301] : content_type [15]len [2] 6. error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message:[file:line] [s3_pkt.c:1252] 7. error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:[file:line] [s3_pkt.c:1330] Please let me know if there is a patch or workaround for this issue. I will be happy to provide any additional information. Thanks for the help. -Shashank
