Cannot decrypt file - maybe wrong key?
Hello List, I'm trying to decrypt a backup file, using openssl enc -d -aes-256-cbc -in etc.bz2.aes256 -out etc.tar.bz2 -pass file:autobackup.aeskey It returns bad decrypt 34560:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_enc.c:330: I encrypted the file using openssl enc -aes-256-cbc -salt -in etc.bz2 -out etc.bz2.aes256 -pass file:autobackup.aeskey Now, I'm fairly certain that it's the same key but not 100%. Is there some other reason the decrypt could fail? Regards, James __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl s_client -dtls1 and ECC key
I would like to follow up on the path that Robin provided to fix bug associated with DTLS issue when using ECC keypair. In summary, I was able to apply the patch into openssl-1.0.0e. I verified that the patch fixed the issued associated with bad encryption error. I verified the dtls1 connection (s_client and s_server) with and without -Verify at the server. The server, issuing CA, and root CA use prime256v1 curve. The cert signature is ecdsa-with-sha256. Thanks to Robin. Erwin On Fri, Oct 21, 2011 at 10:30 AM, Robin Seggelmann seggelm...@fh-muenster.de wrote: Hi Erwin, The patch is for the current release 1.0.0e but should work with 1.0.0d as well. However, I recommend using 1.0.0e anyway because several bugs have been fixed in this version, as you might have seen on our website. Robin On 21.10.2011, at 17:27, Erwin Himawan wrote: Robin, Thanks for looking into this. Is this patch applicable to openssl-1.0.0d, or is it for another release? I will definitely let you know whether the patch solve the issue. Erwin On Fri, Oct 21, 2011 at 2:44 AM, Robin Seggelmann seggelm...@fh-muenster.de wrote: Hi Erwin, Thanks for the report. I found the bug and submitted a patch (#2628). You can also download it from our website at http://sctp.fh-muenster.de/dtls-patches.html and it would be very helpful if you can confirm that the patch fixes your issue. Robin On Oct 12, 2011, at 11:33 PM, Erwin Himawan wrote: Hi, Does anybody know whether openssl s_client and s_server support the use of -dtls1 option while the server uses ECC key? The issuing CA and root CA use ECC keypair. These are my openssl s_server and s_client options: openssl s_server -accept 12000 -cert server.pem -certform pem -key server_key.pem -keyform pem -CApath . -CAfile CAECCRoot.pem -dtls1 -cipher ALL -debug -msg -state openssl s_client -connect:10.8.122.106:12000 -CApath . -CAfile CAECCRoot.pem -dtls1 -cipher ALL -debug -msg -state When I attempted to do this, the s_client gives error: SSL3 alert write:fatal:decrypt error SSL_connect:error in SSLv3 read server key exchange B 5551756:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad signature:s3_clnt.c:1610 further down, I notice that the Verify return code: 0 (ok). I also use openssl verify to verify the server certificate using the issuing CA and root CA. The result agrees with the result shown by the s_client debug message. On the second note, I also try the s_server with RSA keypair, issued by the same issuing CA; the server certificate has RSA public key with signature algorithm is ecdsa-with-SHA256. In this scenario, the s_client was able to establish tls connection with the s-server. Does this mean that the openssl s_client and s_server does not support ECC keypair? Any pointer or idea how further troubleshoot this? Thanks, Erwin Viele Grüße Robin
Support for Indirect CRL
Hello,
We have an application using openssl that acts as a server and receives an SSL
connection.
Based on the configuration, the server requests a client certificate and
validates it by check to see that it is signed by a trusted CA + others checks
(CN...) but it was not validating against a crl. We used the following
function from the openssl libraries to enable that in the libraries:
SSL_set_verify (ssl, SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
verify_callback);
SSL_set_verify_depth (ssl,G_PPROFS[profIndex].certdef);
Our verify_callback also does other checks. And we were getting the client
certificate and doing the validation, with no problems. We now have been
requested to add support for CRL.
The CRL file is loaded at the time the software is started.
1) The CRL support works fine when the client certificate is signed by the same
authority (CA) and the CRL is issued by that same authority. We had to add the
following in the code to support Client validation against a CRL:
// Get the store structure
X509_STORE *x509_store =
SSL_CTX_get_cert_store(G_SSLINFO[profIndex].ctx);
// Add the CRLs
if(!load_file_lookup(x509_store, G_PPROFS[profIndex].crlfile)){
sprintf ( obuf,load_file_lookup failed for crl file %s
on profile %i,G_PPROFS[profIndex].crlfile,profIndex );
SSLPrintErr(IMMED, DANGER_,
XLPRGFLO,obuf);
return ( -1);
}
/* NOTE: we use the method above instead of X509_STORE_add_crl. The
CRLs are in a file and we believed that has the same result
than processing each CRL and adding them into the X509_store. Hope it
is correct. It seems to work but we are using one CRL so
more testing may be needed */
//X509_STORE_add_crl(x509_store, crl);
X509_VERIFY_PARAM *param;
param = X509_VERIFY_PARAM_new();
X509_VERIFY_PARAM_set_flags(param,
X509_V_FLAG_CRL_CHECK|X509_V_FLAG_CRL_CHECK_ALL|X509_V_FLAG_EXTENDED_CRL_SUPPORT);
SSL_CTX_set1_param(G_SSLINFO[profIndex].ctx, param);
X509_VERIFY_PARAM_free(param);
We tested that for a while and it seems to work just fine. Certificates that
are revoked are detected and the connection ends with an error of the type:
SSL alert (write): fatal: certificate revoked
Certificates that are valid process with no issues and the connections are
established. However, if a client certificate is received, and it is signed by
a different CA than the one that issued the CRL, we get an error unable to
get certificate CRL. So it seems to work fine in that Direct CRL scenario.
Now the issue is around indirect CRL:
2) The CRL support does not work if the client certificate is not signed by the
same authority that issued the CRL. Below is one example:
Client certificate is signed by CA1 and in the CRL Distribution Points we have:
CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://luc.com/luc.crl
CRL Issuer:
Directory Address:
CN=Luc CRL Issuer
O=Luc
The CRL is issued by Luc CRL Issuer and the Luc CRL Issuer certificate is
signed by CA1.
I was hoping that the code above will still work given that I added the flag
X509_V_FLAG_EXTENDED_CRL_SUPPORT and was expecting that the libraries would:
a) Look for direct CRL by checking if it is able to find a CRL that is issued
by the same issuer that issued the client certificate. If not then,
b) Check the CRLIssuer from the client certificate and check if there is a CRL
issued using that issuer name. If yes, then use, else
c) CRL not found.
Could someone take a look and let me know if my assumptions are correct with
regard to the behavior of OpenSSL with regards to support of Indirect CRL? If
my assumptions are correct, could you tell me what I am missing as it is not
working. If my assumptions are not valid, do you know how I should approach
support for indirect CRL?
Thanks!!
*
Benjamin Sligar
Manager, Development Support
P: 703.453.8324
us_dev_supp...@tnsi.com
*
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Failing to verify the certificate of one specific site
On 10/22/2011 4:52 AM, Lucas Clemente Vella wrote: 2011/10/21 Jakob Bohmjb-open...@wisemo.com: According to the Digicert CPS http://www.digicert.com/docs/cps/DigiCert_EV-CPS.pdf, that DigiCert root is cross-certified by the Entrust root. Some trusted certificate bundles include only the Entrust root CA and will need the Entrust-signed cross intermediary certificate to validate, other trusted certificate bundles include the Digicert self-signed root for this key directly. It is expected from the standards and the behavior of other X.509 libraries that upon seeing the keyid of a known root, the library should stop following the chain and ignore any extra certificate provided by the entity being verified. So, the behavior I get with OpenSSL when using the Digicert root is non-conformant with X.509? The peer's certificate should have been verified when I provided the Digicert root? Just my unqualified opinion though. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
