Re: This is one for the Pros: cert is not privkey
(Since you top-posted, I will do so too in this thread) The certificate does not include the private key, only the public key. In a real (not test) setup you would use these like this: 1. Use the certificate file alone on any computer to encrypt data using theopenssl cms or openssl pkcs7 command. 2. Use the key file AND the certificate file on the recipient computer to decrypt data using the openssl cms or openssl pkcs#7 command, with different options. To tell the difference between the kinds of PEM files, just look at the first line in a text viewer such as Windows Notepad or GNU less, it will say so in nice big friendly letters. P.S. The differences between the OpenSSL CMS and PKCS#7 commands and features have little to do with differences between the CMS and PKCS#7 standards, it is just that some members of the OpenSSL team had different ideas about what they wanted the command to do, and then used two names of the standard to tell their work apart. On 11/22/2012 12:21 AM, Peter Parker wrote: Dave, Thank you for the quick and thorough response. This is good stuff. Yes, so the files I will be encrypting will be over 100 bytes. I am aware of the key size requirements - 1028 was only used as a placeholder for the example commands I provided. Does this mean that I will be able to use RSA or not? You lost me with the chaining and AKI stuff. I have no idea what either of those mean. Does the CMS approach that you suggested address this issue? In either case, I like the idea of using CMS. The major reason that I am using the x509 (or originally the ca) utility is that I want to be able to set begin and end valid dates (-startdate, -enddate) for the public and private keys and create certificates as well. I also want to associate some metadata with them like organization and locality, for that I am currently using the -subj command. Am I correct that the large PEM file includes both a public and private key? If so I should be able to extract them from the PEM and then use something (rsautl, enc or ...) to encrypt and decrypt the files. After successfully extracting what I understand to be a public key from the PEM, I receive this error from the rsautl utility: unable to load Public Key. Error in rsautl Could you give me some examples of how you would use CMS or, just use these utilities properly, to achieve what I'm trying to do. I really appreciate your help. Thanks, Peter On Tue, Nov 20, 2012 at 10:17 PM, Dave Thompson dthomp...@prinpay.com mailto:dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org mailto:owner-openssl-us...@openssl.org On Behalf Of Peter Parker Sent: Tuesday, 20 November, 2012 20:59 Subject: This is one for the Pros Not really. This is pretty basic. I've been trying to generate a public/private key pair after generating the certificates, but OpenSSL keeps giving me an error. The commands and the error are below. Thanks. No you're not; you're generating a CA keypair and cert (directly), then an application keypair, then an application cert (via CSR). Which is the (well, a) correct sequence, for one entity. Commands #openssl req -new -x509 -extensions v3_ca -days 365 -keyout caKey.pem -passout pass:test -out caCert.crt -batch #openssl genrsa -out application.pem -passout pass:test -des3 1028 1028 is an unusual size for an RSA key; most folks use power-of-2 based values like 1024 1536 2048. 1024 is presently rather marginal for security; for example, NIST has it deprecated since the end of 2010, and prohibited after the end of 2013, for US government use. #openssl req -new -key application.pem -passin pass:test -out application.csr -batch A second req -new -batch generates a CSR with the same DN ... #openssl x509 -req -days 365 -in application.csr -CA caCert.crt -CAcreateserial -CAkey caKey.pem -passin:test -out test-key.pem -extensions ssl_cert ... thus this creates a CA-signed cert which appears to be self-signed, and will not chain correctly with OpenSSL. If the ssl_cert section of your config file (which doesn't exist in the distro file) includes AKI, other software that chains primarily by AKI may work, but this is still incorrect. This puts the cert in a file named test-key.pem, which is a misleading name. #openssl rsa -in test-key.pem -passin pass:test -out pub-key.pem -outform PEM -pubout And therefore this command, which is not the last one, fails because you told it to read the privatekey from a file which is a certificate. application.pem is your privatekey. #openssl rsautl -encrypt -inkey pub-key.pem -pubin -in testfile.txt -out eFile.ssl Error unable to load Private Key (I receive this after the last command) Not last. The key thing that I am trying to do is to encrypt some files with the key that I generate. I
thread-safety questions on 1.0.1c
I am seeing lots of errors whose error message reads S server_ip: 2851965808:error:14092105:SSL routines:SSL3_GET_SERVER_HELLO:wrong cipher returned:s3_clnt.c:963: if I run it in at least several (8+) threads. Single threaded it's all doing fine, so I guess the kind of issue is obvious. I assumed this was related to my code initiating OpenSSL thread-safety with deprecated calls, e.g. CRYPTO_set_locking_callback(ssl_lock); CRYPTO_set_id_callback(ssl_get_thread_id); where ssl_lock() simply uses glib mutexes to do the locking and ssl_get_thread_id() uses pthread_self() to return the thread's id. These have worked perfectly in the past for a long time so I didn't expect them to be the source of the problem. Anyway, since the docs at http://www.openssl.org/docs/crypto/threads.html advise to use the new calls with any version = 1.0.0 I replaced CRYPTO_set_locking_callback(ssl_lock); with CRYPTO_THREADID_set_callback(threadid_func)); where threadid_func is just CRYPTO_THREADID_set_numeric(id, pthread_self()); and also added the dynamic locking functions. Before, though, I checked the OpenSSL sources and I got the feeling those dynamic locks would only rarely (if at all) get get called. So far, my dynamic locks have not been called once by OpenSSL - confirming this here http://fixunix.com/openssl/359957-re-clarification-questions-openssl-thread-safe-support.html In my application, there is only one global context and it is used to set up all SSL sessions. To be able to do so, it is modified heavily (read: for every connection) prior to calling SSL_new(ssl_ctx). This may include setting the ciphers, the certificates, SNI, etc., depending on the situation and the needs for that connection. Since I couldn't find a locking callback inside the SSL_CTX, the whole code is protected by a mutex on my end so I am fairly sure concurrent access on the SSL_CTX in my code is not the problem. But maybe after calling SSL_new(ssl_ctx) there's some magic going on behind the doors which accesses the context again ? Of course, such access would no longer be safe and would need to be controlled (how?). As a side note: Am I correct in assuming the 'old' CRYPTO_set_locking_callback() function did not get a replacement, as did CRYPTO_set_id_callback() ? I couldn't find any such replacement in the sources and I suppose that's one of the places where the dyn locks are supposed to come in, in future versions. Anyone got an idea on how to procede ? Regards, Thomas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EAP-TLS error: RSA_padding_check_PKCS1_type_1:block type is not 01
Hi All,
I'm using Freeradius server2.1.12 on x86 fedora14. My client is using
(armel ubuntu 10.04 lucid) IMX53 board. When I try connecting to radius
server I am receiving the following errors.
Do we require different certificates for arm boards, as I was able to
run without any issues on x86 with same certificates.
openssl version is 0.98g (on arm board)
openssl version is 1.0.0a-fips (on x86 free radius server 2.1.12)
/*ERROR:
---
*/
rad_recv: Access-Request packet from host 10.0.0.70 port 2050, id=8,
length=166
User-Name = testuser
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Called-Station-Id = 68-7F-74-64-0A-AA:linksys
Calling-Station-Id = 00-23-A7-3B-29-2C
Framed-MTU = 1400
NAS-Port-Type = Wireless-802.11
Connect-Info = CONNECT 0Mbps 802.11
EAP-Message = 0x020300060d00
State = 0xba89e950b88ae454eff4b9964b6ca194
Message-Authenticator = 0x3f69e77da835e1450b33224899e816b2
Tue Nov 20 16:48:05 2012 : Info: # Executing section authorize from file
/usr/local/etc/raddb/radiusd.conf
Tue Nov 20 16:48:05 2012 : Info: +- entering group authorize {...}
Tue Nov 20 16:48:05 2012 : Info: ++[preprocess] returns ok
Tue Nov 20 16:48:05 2012 : Info: ++[chap] returns noop
Tue Nov 20 16:48:05 2012 : Info: ++[mschap] returns noop
Tue Nov 20 16:48:05 2012 : Info: [suffix] No '@' in User-Name =
testuser, looking up realm NULL
Tue Nov 20 16:48:05 2012 : Info: [suffix] No such realm NULL
Tue Nov 20 16:48:05 2012 : Info: ++[suffix] returns noop
Tue Nov 20 16:48:05 2012 : Info: [eap] EAP packet type response id 3
length 6
Tue Nov 20 16:48:05 2012 : Info: [eap] No EAP Start, assuming it's an
on-going EAP conversation
Tue Nov 20 16:48:05 2012 : Info: ++[eap] returns updated
Tue Nov 20 16:48:05 2012 : Info: [files] users: Matched entry testuser
at line 131
Tue Nov 20 16:48:05 2012 : Info: ++[files] returns ok
Tue Nov 20 16:48:05 2012 : Info: Found Auth-Type = EAP
Tue Nov 20 16:48:05 2012 : Info: # Executing group from file
/usr/local/etc/raddb/radiusd.conf
Tue Nov 20 16:48:05 2012 : Info: +- entering group authenticate {...}
Tue Nov 20 16:48:05 2012 : Info: [eap] Request found, released from the list
Tue Nov 20 16:48:05 2012 : Info: [eap] EAP/tls
Tue Nov 20 16:48:05 2012 : Info: [eap] processing type tls
Tue Nov 20 16:48:05 2012 : Info: [tls] Authenticate
Tue Nov 20 16:48:05 2012 : Info: [tls] processing EAP-TLS
Tue Nov 20 16:48:05 2012 : Info: [tls] Received TLS ACK
Tue Nov 20 16:48:05 2012 : Info: [tls] ACK handshake fragment handler
Tue Nov 20 16:48:05 2012 : Info: [tls] eaptls_verify returned 1
Tue Nov 20 16:48:05 2012 : Info: [tls] eaptls_process returned 13
Tue Nov 20 16:48:05 2012 : Info: ++[eap] returns handled
Sending Access-Challenge of id 8 to 10.0.0.70 port 2050
EAP-Message =
0x0104020d0d8005f9bd300c0603551d13040530030101ff301d0603551d0e04160414b3807b965fdd9f8fee8fca751d47bf2aebac11fd30818d0603551d230481853081828014b3807b965fdd9f8fee8fca751d47bf2aebac11fda15fa45d305b310a3008060355040a130161310a3008060355040b1301613110300e06092a864886f70d010901160161310a30080603550407130161310a30080603550408130161310b3009060355040613026161310a30080603550403130161820900958dbc5fc22a1e39300d06092a864886f70d010104050003818100a8e4f602c2235087e8a8e93f610ce12e5e3e6a54103b1dccc56529aab99cc32649af
EAP-Message =
0x88b6fb15bdb71452ca8657933581fd72e30615d551ba01f76475e2809c53ca6c798138de31621f62e3644e3f847199de6a1a00ce71c631e200b4cf2747a9714a7bb778fec35669dd1c63102371576fc66ec5bbdf2c9f4fd956782216a10b16030100ad0da502010200a0003f303d310b3009060355040613026161310a30080603550408130161310a3008060355040a130161310a3008060355040b130161310a30080603550403130161005d305b310a3008060355040a130161310a3008060355040b1301613110300e06092a864886f70d010901160161310a30080603550407130161310a30080603550408130161310b3009060355040613
EAP-Message = 0x026161310a300806035504031301610e00
Message-Authenticator = 0x
State = 0xba89e950b98de454eff4b9964b6ca194
Tue Nov 20 16:48:05 2012 : Info: Finished request 8.
Tue Nov 20 16:48:05 2012 : Debug: Going to the next request
Tue Nov 20 16:48:05 2012 : Debug: Waking up in 0.5 seconds.
rad_recv: Access-Request packet from host 10.0.0.70 port 2050, id=9,
length=1287
User-Name = testuser
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Called-Station-Id = 68-7F-74-64-0A-AA:linksys
Calling-Station-Id = 00-23-A7-3B-29-2C
Framed-MTU = 1400
NAS-Port-Type = Wireless-802.11
Connect-Info = CONNECT 0Mbps 802.11
EAP-Message =
Re: EVP Padding size
So how do I fix this? -- View this message in context: http://openssl.6102.n7.nabble.com/EVP-Padding-size-tp42413p42447.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: This is one for the Pros: cert is not privkey
Peter Parker wrote: Dave, Thank you for the quick and thorough response. This is good stuff. Yes, so the files I will be encrypting will be over 100 bytes. I am aware of the key size requirements - 1028 was only used as a placeholder for the example commands I provided. Does this mean that I will be able to use RSA or not? You lost me with the chaining and AKI stuff. I have no idea what either of those mean. Does the CMS approach that you suggested address this issue? In either case, I like the idea of using CMS. The major reason that I am using the x509 (or originally the ca) utility is that I want to be able to set begin and end valid dates (-startdate, -enddate) for the public and private keys and create certificates as well. I also want to associate some metadata with them like organization and locality, for that I am currently using the -subj command. Am I correct that the large PEM file includes both a public and private key? If so I should be able to extract them from the PEM and then use something (rsautl, enc or ...) to encrypt and decrypt the files. After successfully extracting what I understand to be a public key from the PEM, I receive this error from the rsautl utility: "unable to load Public Key. Error in rsautl" Without going into the ins and outs of using the openssl utility, you can actually infer a lot from the output PEM files themselves. They are text files with the certificate parts and key parts base64 encoded and bookended by -BEGIN CERTIFICATE- ... -END CERTIFICATE- for certificates in which case you can use 'openssl x509 arguments' to inspect them, run "openssl x509 -help" for the options in this case. AND -BEGIN RSA PRIVATE KEY- ... -END RSA PRIVATE KEY- for a key (but notice this key is actually an RSA key, you can have other types of keys so this text may be something like 'BEGIN other type PRIVATE KEY'). The RSA keyword gives you the clue to use 'openssl rsa args' to inspect this one, try 'openssl rsa -help' to see what is available. You should also know the password for the private key or you will be told zip by 'openssl rsa'. The private key should be passworded, but you can strip the password from them, which is not recommended but procedurally easier in some circumstances beyond this discussion. Also note that some certificates may or may not include a key in the output file, if they don't you will have a separate key file. But just looking at the certificate or key file and the bookends of the base64 encoded part will tell you which file contains what. Could you give me some examples of how you would use CMS or, just use these utilities properly, to achieve what I'm trying to do. I really appreciate your help. Thanks, Peter On Tue, Nov 20, 2012 at 10:17 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Peter Parker Sent: Tuesday, 20 November, 2012 20:59 Subject: This is one for the Pros Not really. This is pretty basic. I've been trying to generate a public/private key pair after generating the certificates, but OpenSSL keeps giving me an error. The commands and the error are below. Thanks. No you're not; you're generating a CA keypair and cert (directly), then an application keypair, then an application cert (via CSR). Which is the (well, a) correct sequence, for one entity. Commands #openssl req -new -x509 -extensions v3_ca -days 365 -keyout caKey.pem -passout pass:test -out caCert.crt -batch #openssl genrsa -out application.pem -passout pass:test -des3 1028 1028 is an unusual size for an RSA key; most folks use power-of-2 based values like 1024 1536 2048. 1024 is presently rather marginal for security; for example, NIST has it deprecated since the end of 2010, and prohibited after the end of 2013, for US government use. #openssl req -new -key application.pem -passin pass:test -out application.csr -batch A second req -new -batch generates a CSR with the same DN ... #openssl x509 -req -days 365 -in application.csr -CA caCert.crt -CAcreateserial -CAkey caKey.pem -passin:test -out test-key.pem -extensions ssl_cert ... thus this
RE: EVP Padding size
From: coderl [mailto:forumme5...@subdomain10.info] Sent: Wednesday, November 21, 2012 2:34 PM So how do I fix this? -- View this message in context: http://openssl.6102.n7.nabble.com/EVP- Padding-size-tp42413p42447.html You change whatever you're doing wrong and do it right instead. As always, if you were to present the minimal subset of your code showing exactly what you are doing someone might be able to help you find what you are doing wrong - or perhaps even to nail a bug in OpenSSL and advise on a fix or workaround. You'd likely benefit from absorbing http://www.catb.org/~esr/faqs/smart-questions.html __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: linking error
From: Priyaranjan Nayak [mailto:priyaranjan4...@gmail.com] Sent: Thursday, November 22, 2012 2:36 PM While build the tls server I got this link error.Below I mentioned bild log . Can any one help me ? Linking console executable: bin/Debug/dtlsServer ../openssl-1.0.1c/libssl.a(ssl_algs.o): In function `SSL_library_init': ssl_algs.c:(.text+0x1e): undefined reference to `EVP_idea_cbc' ... At a guess, you're not linking against libcrypto.a. If you are linking against libcrypto.a, then some versions of some linkers on some OSes are fussy about the order of libraries in the link command, and you'd need to make sure that libcrypto.a is listed after libssl.a. If neither of those do it, then provide some basic information - what OS are you building on, what compiler and linker are you using, and what exactly is the linker command line you are running? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: thread-safety questions on 1.0.1c
From: Thomas Eckert [mailto:thomas.eck...@sophos.com] Sent: Tuesday, November 20, 2012 9:44 AM I am seeing lots of errors whose error message reads S server_ip: 2851965808:error:14092105:SSL routines:SSL3_GET_SERVER_HELLO:wrong cipher returned:s3_clnt.c:963: if I run it in at least several (8+) threads. Single threaded it's all doing fine, so I guess the kind of issue is obvious. I assumed this was related to my code initiating OpenSSL thread-safety with deprecated calls, e.g. CRYPTO_set_locking_callback(ssl_lock); CRYPTO_set_id_callback(ssl_get_thread_id); where ssl_lock() simply uses glib mutexes to do the locking and ssl_get_thread_id() uses pthread_self() to return the thread's id. These have worked perfectly in the past for a long time so I didn't expect them to be the source of the problem. Anyway, since the docs at http://www.openssl.org/docs/crypto/threads.html advise to use the new calls with any version = 1.0.0 I replaced CRYPTO_set_locking_callback(ssl_lock); with CRYPTO_THREADID_set_callback(threadid_func)); where threadid_func is just CRYPTO_THREADID_set_numeric(id, pthread_self()); That threads man page got updated as part of these changes, which was a great idea, but unfortunately it got mangled in the process. In particular, while it talks in detail about locking and thread ID callbacks it apparently no longer gives any clue how to actually set the locking callback. It also now contains a lot of stuff which appears to be internal implementation detail and APIs which are private to the library, getting in the way of finding the required information for the external APIs (the most important bit of which is no longer there, or it's ended up so well hidden that I can't find it at least). My understanding is that you still need to call CRYPTO_set_locking_callback() to register your locking function, as before. Without that you have no locking, leading to what you're seeing. What's really changed is the thread ID mechanism. The biggest change for people working on normal OSes (such as Windows, and UNIX and other POSIXy things) is that you no longer need thread ID callbacks at all. If your OS is Windows, or if errno has a different address in each thread, then the built-in thread ID mechanism is all you need. My code runs only on such server OSes, and my change when moving up to 1.0.0 and later was simply to remove my dodgy thread ID callback function and the call to CRYPTO_set_id_callback(). All the standard and dynamic locking stuff stays the same. I can't say for certain that this is correct, and I've only just made the change and haven't yet tested it thoroughly, but it's my understanding after some thinking and digging. Not that this explains why you started seeing the problem when you still had your original locking callback in place, that is worrying ... Regards, jjf and also added the dynamic locking functions. Before, though, I checked the OpenSSL sources and I got the feeling those dynamic locks would only rarely (if at all) get get called. So far, my dynamic locks have not been called once by OpenSSL - confirming this here http://fixunix.com/openssl/359957-re-clarification-questions-openssl- thread-safe-support.html In my application, there is only one global context and it is used to set up all SSL sessions. To be able to do so, it is modified heavily (read: for every connection) prior to calling SSL_new(ssl_ctx). This may include setting the ciphers, the certificates, SNI, etc., depending on the situation and the needs for that connection. Since I couldn't find a locking callback inside the SSL_CTX, the whole code is protected by a mutex on my end so I am fairly sure concurrent access on the SSL_CTX in my code is not the problem. But maybe after calling SSL_new(ssl_ctx) there's some magic going on behind the doors which accesses the context again ? Of course, such access would no longer be safe and would need to be controlled (how?). As a side note: Am I correct in assuming the 'old' CRYPTO_set_locking_callback() function did not get a replacement, as did CRYPTO_set_id_callback() ? I couldn't find any such replacement in the sources and I suppose that's one of the places where the dyn locks are supposed to come in, in future versions. Anyone got an idea on how to procede ? Regards, Thomas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EVP_Decrypt_Final_ex with Microsoft clients
Hi all, I'm working on an e-mail server written in node.js called Haraka. STARTTLS is supported in Haraka by use of the node.js crypto/TLS modules which wrap OpenSSL 1.0.0f + Chromium patches from Android. Last week I noticed some peculiarities on two clients that were sending e-mail to my server using TLS, both appear to be running recent versions of Microsoft Exchange and both failing with the following error: Error: 3074500304:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:../deps/openssl/openssl/crypto/evp/evp_enc.c:467:#0123074500304 I've captured packet traces using Wireshark which show the session is successfully encrypted after STARTTLS is issued and MAIL/RCPT and DATA command are subsequently sent but this error is generated after the client has sent all of the message data and the ending dot. At which point this error is logged and the client is forcefully disconnected. I've tried enabling SSL_OP_ALL to enable all existing workarounds to no avail. STARTTLS works without issue with hundreds of other clients that connect to this system - it only appears to be failing with Microsoft clients. Obviously there could be a bug in the node.js bindings to OpenSSL or in our application code itself - but I'm at a loss as to where to start looking. Here are the details of one of the failing clients and the ciphers/versions in use: [tls] secured: cipher=AES128-SHA version=TLSv1/SSLv3 verified=true cn=mail.global.frontbridge.com organization=Microsoft Corporation issuer=undefined expires=Jun 16 06:39:25 2013 GMT fingerprint=51:96:58:27:1A:49:FF:A3:E6:19:EE:41:66:20:EF:52:45:52:10:3F Any pointers or hints about this error would be greatly appreciated. Kind regards, Steve. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: EVP_Decrypt_Final_ex with Microsoft clients
On Thu, Nov 22, 2012, Steve Freegard wrote: Hi all, I'm working on an e-mail server written in node.js called Haraka. STARTTLS is supported in Haraka by use of the node.js crypto/TLS modules which wrap OpenSSL 1.0.0f + Chromium patches from Android. Last week I noticed some peculiarities on two clients that were sending e-mail to my server using TLS, both appear to be running recent versions of Microsoft Exchange and both failing with the following error: Error: 3074500304:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:../deps/openssl/openssl/crypto/evp/evp_enc.c:467:#0123074500304 I've captured packet traces using Wireshark which show the session is successfully encrypted after STARTTLS is issued and MAIL/RCPT and DATA command are subsequently sent but this error is generated after the client has sent all of the message data and the ending dot. At which point this error is logged and the client is forcefully disconnected. I've tried enabling SSL_OP_ALL to enable all existing workarounds to no avail. STARTTLS works without issue with hundreds of other clients that connect to this system - it only appears to be failing with Microsoft clients. Obviously there could be a bug in the node.js bindings to OpenSSL or in our application code itself - but I'm at a loss as to where to start looking. Here are the details of one of the failing clients and the ciphers/versions in use: [tls] secured: cipher=AES128-SHA version=TLSv1/SSLv3 verified=true cn=mail.global.frontbridge.com organization=Microsoft Corporation issuer=undefined expires=Jun 16 06:39:25 2013 GMT fingerprint=51:96:58:27:1A:49:FF:A3:E6:19:EE:41:66:20:EF:52:45:52:10:3F Any pointers or hints about this error would be greatly appreciated. The function EVP_DecryptFinal_ex isn't often used in the TLS code and you normally wouldn't come across this error so it may not be TLS related. You might see it related to session tickets but that shouldn't be a fatal error: try SSL_OP_NO_TICKET anyway though. I'd suggest you print out the whole error queue instead of just the top so it is clearer where the actual error is occurring. Alternatively a stack trace under a debugger would be useful. 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
Openssl - Bouncy Castle : Signature Verification Failure
I am trying to develop a java utility based on Bouncy Castle that should be able to sign and encrypt data which can later be decrypted and verified on the server side (openssl). Data encrypted by BC gets decrypted fine with Openssl Data signed by BC gets verified fine with Openssl But when I sign and encrypt data with BC and use OpenSSL to decrypt and verify, it fails. But if I only decrypt this content, it decrypts fine. However the output of this decryption when I try to verify, it fails. I then opened the output of decryption, removed the first 3 lines from it. These lines were the 2 Headers and a blank line. After this the verification also went thru fine. So I am not sure how to avoid these extra headers that gets passed as input to openssl verification. My decrypt and verify is something like this - openssl smime -decrypt -in $1 -recip $2 -inkey $3 | openssl smime -verify -CAfile $4 -out $5 These were the extra lines I deleted - Content-Type: application/octet-stream Content-Transfer-Encoding: binary A blank line Anyone know of a solution, please let me know. Thanks, Dwipin. -- View this message in context: http://openssl.6102.n7.nabble.com/Openssl-Bouncy-Castle-Signature-Verification-Failure-tp42468.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: Openssl - Bouncy Castle : Signature Verification Failure
Its not exactly Signature Verification Failure. I get the following error - Error reading S/MIME message 24746:error:2107A083:PKCS7 routines:SMIME_read_PKCS7:invalid mime type:pk7_mime.c:364:type: application/octet-stream -- View this message in context: http://openssl.6102.n7.nabble.com/Openssl-Bouncy-Castle-Signature-Verification-Failure-tp42468p42469.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
