Re: Core occurred while executing SSL_library_init() and call back method locking_function()
Gayathri the core and the binary file are attached with the message.
Please let me know if you get any idea.
If you aware how the call back mechanism works. Please share the same.
Thanks in advance.
Gayathri Sundar-3 wrote:
Can u share the parsed core file?
On Wednesday, May 11, 2011, Mani Suresh suresh84...@gmail.com wrote:
While executing the below code its coring randomly in two cases,
1) While executing the method SSL_library_init() in the constructor.
2) Coring while executing the call back method locking_function().
We are not sure, now the call back method is calling after it is set to
NULL
Ex : CRYPTO_set_locking_callback(NULL)
Here, after we set to NULL its calling the call back method.
We want to make sure it should not be called after setting to NULL.
It will be great if someone explain me in detail, how the call back
mechanism works internally.
Code:
-
pthread_mutex_t *SslBIO::_lnSslBioMutex=NULL;
void SslBIO::locking_function(int mode, int type, const char * file, int
line)
{
int rstat;
if (mode CRYPTO_LOCK)
{
fprintf(stderr, \nDEBUG: Locking the Mutex _lnSslBioMutex[%d] Mode =
%d
File :%s Line No : %d\n,type,mode,file,line);
rstat = pthread_mutex_lock((SslBIO::_lnSslBioMutex[type]));
lnChkMutex(rstat, FL);
}
else
{
fprintf(stderr, \nDEBUG: UnLocking the Mutex _lnSslBioMutex[%d] Mode
=
%d File :%s Line No : %d\n,type,mode,file,line);
rstat = pthread_mutex_unlock((SslBIO::_lnSslBioMutex[type]));
lnChkMutex(rstat, FL);
}
}
unsigned long SslBIO::id_function()
{
unsigned long ulThreadId = (unsigned long)pthread_self();
fprintf(stderr, \nDEBUG: Thread ID = %d\n,ulThreadId);
return (ulThreadId);
}
int SslBIO::init(const char * initarg)
{
int i;
_lnSslBioMutex = (pthread_mutex_t *)
OPENSSL_malloc(CRYPTO_num_locks() *
sizeof(pthread_mutex_t));
if (!_lnSslBioMutex)
return 0;
fprintf(stderr, \nDEBUG: Number of Locks(CRYPTO_NUM_LOCKS) = %d
\n,CRYPTO_num_locks());
for(i=0;iCRYPTO_num_locks();i++)
{
fprintf(stderr, \nDEBUG: Initialize the Mutex
_lnSslBioMutex[%d]\n,i);
int rstat = pthread_mutex_init((_lnSslBioMutex[i]),
pthread_mutexattr_default);
lnChkMutex(rstat, FL);
}
CRYPTO_set_id_callback(SslBIO::id_function);
CRYPTO_set_locking_callback(SslBIO::locking_function);
return 0;
}
int SslBIO::terminate()
{
int i = 0;
int rstat;
if (!_lnSslBioMutex)
{
return 0;
}
CRYPTO_set_id_callback(NULL);
CRYPTO_set_locking_callback(NULL);
for(i=0;iCRYPTO_num_locks();i++)
{
fprintf(stderr, \nDEBUG: Cleanup the Mutex _lnSslBioMutex[%d]\n,i);
rstat = pthread_mutex_destroy((_lnSslBioMutex[i]));
lnChkMutex(rstat, FL);
}
OPENSSL_free(_lnSslBioMutex);
_lnSslBioMutex = NULL;
}
SslBIO::SslBIO(const char *host,
const int port, const int timeout,
int retCode, int blockingConnect)
{
_debug = 0;
_lnreqctx = 0;
_type = SslBIO::CALLER;
_totSent = 0;
_totReceived = 0;
_errBuf[0] = '\0';
if(host!=NULL)
strcpy(_hostName,(char *)host);
_portNum = port;
retCode = FAIL;
/* Set up the library */
SSL_library_init();
ERR_load_BIO_strings();
SSL_load_error_strings();
OpenSSL_add_all_algorithms();
_sslctx = SSL_CTX_new(SSLv23_client_method());
if(_sslctx == 0)
{
fprintf(stderr, failed SslBIO::SslBIO. SslBIO not initialized.
_sslctx=0\n);
return;
}
_bio = BIO_new_ssl_connect(_sslctx);
BIO_get_ssl(_bio, _ssl);
SSL_set_mode(_ssl, SSL_MODE_AUTO_RETRY);
/* Create and setup the connection */
BIO_set_conn_hostname(_bio, _hostName); //
cdc13-www.lexisnexis.com:https);
BIO_set_conn_int_port(_bio, _portNum); // 443);
if(BIO_do_connect(_bio) = 0)
{
fprintf(stderr, Error attempting to connect
[%s[%d]]\n,_hostName,_portNum);
ERR_print_errors_fp(stderr);
BIO_free_all(_bio);
_bio = NULL; //Nullify the _bio member object after deallocating
return;
}
else
{
fprintf(stderr, SslBIO: connected[%s[%d]]\n,_hostName,_portNum);
}
/* Check the certificate */
if(SSL_get_verify_result(_ssl) != X509_V_OK)
{
fprintf(stderr, Certificate verification error: %i\n,
SSL_get_verify_result(_ssl));
}
_timeout = timeout;
retCode = OK;
}
SslBIO::~SslBIO() {
/* Close the connection and free the context */
if (_bio != 0)
{
BIO_free_all(_bio);
_bio=NULL; // bulletproof for webstar 3019980
}
if (_sslctx != 0)
{
fprintf(stderr, Freeing SslBIO::_sslctx\n);
SSL_CTX_free(_sslctx);
_sslctx=NULL; // bulletproof for webstar 3019980
}
}
int SslBIO::read(char *buf, int len, int currRead)
{
int retCode;
if (buf == LN_NULL)
{
return(FAIL);
}
printf(DEBUG: Before Read \n);
currRead = BIO_read(_bio, buf, len);
printf(DEBUG:
RE: key length discrepancy in key generated by sect233r1
dhoward wrote on Wednesday, May 11, 2011 20:01: I was recently playing around with OpenSSL's EC_KEY interface, specifically generating and examining keys generated using the curve sect233r1, when I decided to print the raw key out, in hex form. A quick analysis showed me that the key was stored in 232 bits, not 233 bits as the curve sect233r1 requires - in fact, no matter how many keys I generated and checked this way, I was always missing a bit. Is there some reason that OpenSSL uses only 232 bits instead of the full 233? Did you take into account the point compression as described in SEC 1: Elliptic Curve Cryptography 2.3.3 EllipticCurvePoint-to-OctetString Conversion [http://www.secg.org/collateral/sec1_final.pdf] -- Peter-Michael Hager - acm senior - HAGER-ELECTRONICS GmbH - Germany __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Application is failing with cipher or hash unavailable
Any inputs? This same application on windows does hand shake successfully. Server is same in both linux and windows client application. pradeepreddy wrote: Hi, I have the SSL_library_init() in my app, which will load the algos. Erik Tkal wrote: I think that means you have not enabled the cipher or hash that is required at that point. Did you forget to call something like OpenSSL_add_all_algorithms() in your app? Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of pradeepreddy Sent: Wednesday, May 11, 2011 3:55 PM To: openssl-users@openssl.org Subject: Application is failing with cipher or hash unavailable Hi , My application is running with OpenSSL 0.9.8h 28 May 2008 in gentoo linux: uname -a Linux localhost 2.6.32.9 #1 SMP Thu Jul 8 14:30:23 Local time zone must be set--see zic m i686 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux But ssl hand shake is failing with below error: SSL_ERROR_SSL error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash unavailable But on same linux, openssl s_client -connect server:8443 -cert client.pem -CAfile ca-win.pem, is wokring CONNECTED(0003) --- Certificate chain 0 s:/C=/ST=/L=/O=/OU=DGM/DC=CN=A1 1 s:/DC=/DC=/DC=/DC=/CN=A1 i:/DC=/DC=/DC=/DC=/CN=A1 --- Server certificate -BEGIN CERTIFICATE- MAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBBQUAA4IBAQBd4LfcDl5d3ODPjBBDy7bL YX6uDP6yG+RdbwR9ul4WRhOUXqb0jkHbaGy/Qlz70TGqfSme81yvLsYmChKTFloU 3NDIRAqagGntPXyaR6WjbV652SYtENTL7RONZhxGyeqDF0ns5fLUAdE2eGYN9f3Y X/k/vFrFnKEmEBEWlciwQjr7vag21YGBtIEeopqnRqN64HCGUVKWqap0sQXAJD/4 -END CERTIFICATE- subject=/C=/ST=/L=/O=/OU=/CN=XY2 issuer=/DC=/DC=/DC=dev/DC=/CN=A1 --- Acceptable client certificate CA names /DC=/DC=/DC=/DC=/CN=A1 --- SSL handshake has read 3241 bytes and written 3148 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA Session-ID: Session-ID-ctx: Master-Key: C47BF1691AB846E449B5FA9E29EC4E25312D4C501 Key-Arg : None Start Time: 1305122070 Timeout : 300 (sec) Verify return code: 0 (ok) --- -- View this message in context: http://old.nabble.com/Application-is-failing-with-cipher-or-hash-unavailable-tp31597508p31597508.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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/Application-is-failing-with-cipher-or-hash-unavailable-tp31597508p31601027.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: key length discrepancy in key generated by sect233r1
It's not clear if you're talking about the private or public part of the key.
If you're talking about the private part, that's because only a
negligible number of private keys for that curve need 233 bits to be
stored. This is due to the fact that the large, prime-order subgroup
has the form 2^{232} + a where a is a constant close to sqrt(2^{232}).
So with overwhelming probability, the top bit will always be zero.
(You can still hit these negligible private keys in OpenSSL; it just
won't happen in your lifetime. The implementation is correct.)
Billy
On Thu, May 12, 2011 at 9:37 AM, PMHager h...@prima.de wrote:
dhoward wrote on Wednesday, May 11, 2011 20:01:
I was recently playing around with OpenSSL's EC_KEY interface, specifically
generating and examining keys generated using the curve sect233r1, when I
decided to print the raw key out, in hex form. A quick analysis showed me
that the key was stored in 232 bits, not 233 bits as the curve sect233r1
requires - in fact, no matter how many keys I generated and checked this
way, I was always missing a bit. Is there some reason that OpenSSL uses only
232 bits instead of the full 233?
Did you take into account the point compression as described in
SEC 1: Elliptic Curve Cryptography
2.3.3 EllipticCurvePoint-to-OctetString Conversion
[http://www.secg.org/collateral/sec1_final.pdf]
--
Peter-Michael Hager - acm senior - HAGER-ELECTRONICS GmbH - Germany
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-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
vulnerability management
Hi all, I have run a vulnerability scanning against some systems and some vulnerabilities have come up related with OpenSSL. However, some of them have not 443 port open or have nothing but a single file named as openSSL inside some other's application folder. I asked about the operation of that application and whether it uses openSSL somehow. It does not. Not to mention that OpenSSL does not appear among the tasks or services running. Sometimes, I find OpenSSH being used but not OpenSSL. Does that use any OpenSSL libraries? I am trying to understand how my vulnerability scanner detects OpenSSL in cases like the ones I described above... Is there any way to check whether OpenSSL is being used by a system (eg. Windows server)? I would appreciate anyone's help with this as I am not experienced with OpenSSL. Thank you.
Re: vulnerability management
On Thu May 12 2011, Argyris Ps wrote: Hi all, I have run a vulnerability scanning against some systems and some vulnerabilities have come up related with OpenSSL. However, some of them have not 443 port open or have nothing but a single file named as openSSL inside some other's application folder. I asked about the operation of that application and whether it uses openSSL somehow. It does not. Not to mention that OpenSSL does not appear among the tasks or services running. Sometimes, I find OpenSSH being used but not OpenSSL. Does that use any OpenSSL libraries? OpenSSH can be built against the OpenSSL (or other) libraries. So it is possible that is why your seeing OpenSSL use, check your build of OpenSSH to see how it was created. Although many applications build against the OpenSSL libraries, so the OpenSSH that you see may not be the only reason you see the OpenSSL usage. Mike I am trying to understand how my vulnerability scanner detects OpenSSL in cases like the ones I described above... Is there any way to check whether OpenSSL is being used by a system (eg. Windows server)? I would appreciate anyone's help with this as I am not experienced with OpenSSL. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Application is failing with cipher or hash unavailable
can you give some specific cipher like rc4-md5 using the --cipher command and see if it goes thro? maybe the 1st cipher suite sent by the client is not available with the server or something..you can use mozilla and edit the cipher suites in the advance tab or use openssl client connect command and supply some specific cipher which u know for sure is available on the server. On Wed, May 11, 2011 at 2:54 PM, pradeepreddy pradeepreddy@gmail.comwrote: Hi , My application is running with OpenSSL 0.9.8h 28 May 2008 in gentoo linux: uname -a Linux localhost 2.6.32.9 #1 SMP Thu Jul 8 14:30:23 Local time zone must be set--see zic m i686 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux But ssl hand shake is failing with below error: SSL_ERROR_SSL error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash unavailable But on same linux, openssl s_client -connect server:8443 -cert client.pem -CAfile ca-win.pem, is wokring CONNECTED(0003) --- Certificate chain 0 s:/C=/ST=/L=/O=/OU=DGM/DC=CN=A1 1 s:/DC=/DC=/DC=/DC=/CN=A1 i:/DC=/DC=/DC=/DC=/CN=A1 --- Server certificate -BEGIN CERTIFICATE- MAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBBQUAA4IBAQBd4LfcDl5d3ODPjBBDy7bL YX6uDP6yG+RdbwR9ul4WRhOUXqb0jkHbaGy/Qlz70TGqfSme81yvLsYmChKTFloU 3NDIRAqagGntPXyaR6WjbV652SYtENTL7RONZhxGyeqDF0ns5fLUAdE2eGYN9f3Y X/k/vFrFnKEmEBEWlciwQjr7vag21YGBtIEeopqnRqN64HCGUVKWqap0sQXAJD/4 -END CERTIFICATE- subject=/C=/ST=/L=/O=/OU=/CN=XY2 issuer=/DC=/DC=/DC=dev/DC=/CN=A1 --- Acceptable client certificate CA names /DC=/DC=/DC=/DC=/CN=A1 --- SSL handshake has read 3241 bytes and written 3148 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA Session-ID: Session-ID-ctx: Master-Key: C47BF1691AB846E449B5FA9E29EC4E25312D4C501 Key-Arg : None Start Time: 1305122070 Timeout : 300 (sec) Verify return code: 0 (ok) --- -- View this message in context: http://old.nabble.com/Application-is-failing-with-cipher-or-hash-unavailable-tp31597508p31597508.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: Application is failing with cipher or hash unavailable
Hi, I have tried with all the ciphers. This same application works well on windows. I run my application again with s_server, but hit with the same error: SSL_ERROR_SSL error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash unavailable This time, instead of using my own server, I have run openssl s_server. openssl s_server -accept 9000 -cert client.pem -Verify 0/1 -CAfile ca-win.pem -msg -debug And on s_server, folwing messages are : client hello server hello SSL_accept:SSLv3 write certificate A TLS 1.0 Handshake [length 0004], ServerHelloDone 0e 00 00 00 SSL_accept:SSLv3 write server done A SSL_accept:SSLv3 flush data SSL_accept:failed in SSLv3 read client certificate A ERROR shutting down SSL CONNECTION CLOSED SSL_accept:failed in SSLv3 read client certificate A Above with verify is 0 -- SSL_accept:SSLv3 write certificate A TLS 1.0 Handshake [length 007b], CertificateRequest SSL_accept:SSLv3 write certificate request A SSL_accept:SSLv3 flush data SSL_accept:failed in SSLv3 read client certificate A With verify is ON This mean, client and server are agreed on cipher. In what cases client verifies the TLS1_SETUP_KEY_BLOCK? which drove client to throw this error? Gayathri Sundar-3 wrote: can you give some specific cipher like rc4-md5 using the --cipher command and see if it goes thro? maybe the 1st cipher suite sent by the client is not available with the server or something..you can use mozilla and edit the cipher suites in the advance tab or use openssl client connect command and supply some specific cipher which u know for sure is available on the server. On Wed, May 11, 2011 at 2:54 PM, pradeepreddy pradeepreddy@gmail.comwrote: Hi , My application is running with OpenSSL 0.9.8h 28 May 2008 in gentoo linux: uname -a Linux localhost 2.6.32.9 #1 SMP Thu Jul 8 14:30:23 Local time zone must be set--see zic m i686 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux But ssl hand shake is failing with below error: SSL_ERROR_SSL error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash unavailable But on same linux, openssl s_client -connect server:8443 -cert client.pem -CAfile ca-win.pem, is wokring CONNECTED(0003) --- Certificate chain 0 s:/C=/ST=/L=/O=/OU=DGM/DC=CN=A1 1 s:/DC=/DC=/DC=/DC=/CN=A1 i:/DC=/DC=/DC=/DC=/CN=A1 --- Server certificate -BEGIN CERTIFICATE- MAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBBQUAA4IBAQBd4LfcDl5d3ODPjBBDy7bL YX6uDP6yG+RdbwR9ul4WRhOUXqb0jkHbaGy/Qlz70TGqfSme81yvLsYmChKTFloU 3NDIRAqagGntPXyaR6WjbV652SYtENTL7RONZhxGyeqDF0ns5fLUAdE2eGYN9f3Y X/k/vFrFnKEmEBEWlciwQjr7vag21YGBtIEeopqnRqN64HCGUVKWqap0sQXAJD/4 -END CERTIFICATE- subject=/C=/ST=/L=/O=/OU=/CN=XY2 issuer=/DC=/DC=/DC=dev/DC=/CN=A1 --- Acceptable client certificate CA names /DC=/DC=/DC=/DC=/CN=A1 --- SSL handshake has read 3241 bytes and written 3148 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA Session-ID: Session-ID-ctx: Master-Key: C47BF1691AB846E449B5FA9E29EC4E25312D4C501 Key-Arg : None Start Time: 1305122070 Timeout : 300 (sec) Verify return code: 0 (ok) --- -- View this message in context: http://old.nabble.com/Application-is-failing-with-cipher-or-hash-unavailable-tp31597508p31597508.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 -- View this message in context: http://old.nabble.com/Application-is-failing-with-cipher-or-hash-unavailable-tp31597508p31607141.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: Replace renewed intermediate certificate in the keystore chain
From: owner-openssl-us...@openssl.org On Behalf Of Mohan Radhakrishnan Sent: Thursday, 12 May, 2011 00:04 I think I have been able to replace only the intermediate certificate which has a different validity period. I believe this can be done because what the intermediate certificate is signing is still valid. Only the expiry date is changing and it is being renewed. And the new intermediate is for the same key(pair) as the old, as surmised upthread? 1. Root is valid 2. Sub root or intermediate is replaced 3. Public key certificate is valid. No new CSR is required. I have done this by using keystore commands. From your example below, Java jks using keytool? I exported all the contents of the existing keystore including the private key as a .pem and then replaced only the new intermediate. This was imported back. Now when I run the command Are you sure? Java keytool can't export a privatekey to any kind of pem -- but it can export the CERT FOR a privatekey = the first or only cert in a privatekey entry to either DER or PEM (slightly confusingly called -rfc). That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) Java keytool CAN convert a jks privatekey (AND chain) to PKCS12 by doing -importkeystore with -deststoretype PKCS12. See below. Keytool -list -v -keystore store I can see the chain with the new intermediate in the middle. We are going to test the SSL part to validate. Has anyone does this to the Java keystore with OpenSSL ? OpenSSL cannot manipulate jks directly. OpenSSL can operate on PKCS12. If you use keytool to convert to PKCS12 (or, less likely, have PKCS12 already) you can use OpenSSL to unpack, modify, and rebuild the PKCS12, which keytool can then convert back to jks. But why bother? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Replace renewed intermediate certificate in the keystore chain
Hi, Actually the procedure is similar 1. Use Keytool and convert JKS to PKCS12. 2. Use OpenSSL to convert PKCS12 contents to pem. Now this has the private key and the entire chain. 3. Use open source Java tool to build a new keystore *after replacing the intermediate with the one received*. List the keytool contents and verify the expiry date has changed. That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. I think this procedure is different. I think you mean that I have to export the lowermost leaf and then add the new intermediate and import it back using the same alias of the chain it will work. Will try this. (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) This point is not clear. The root is not touched at all either in the client's store or the server's store. Thanks, Mohan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Friday, May 13, 2011 6:41 AM To: openssl-users@openssl.org Subject: RE: Replace renewed intermediate certificate in the keystore chain From: owner-openssl-us...@openssl.org On Behalf Of Mohan Radhakrishnan Sent: Thursday, 12 May, 2011 00:04 I think I have been able to replace only the intermediate certificate which has a different validity period. I believe this can be done because what the intermediate certificate is signing is still valid. Only the expiry date is changing and it is being renewed. And the new intermediate is for the same key(pair) as the old, as surmised upthread? 1. Root is valid 2. Sub root or intermediate is replaced 3. Public key certificate is valid. No new CSR is required. I have done this by using keystore commands. From your example below, Java jks using keytool? I exported all the contents of the existing keystore including the private key as a .pem and then replaced only the new intermediate. This was imported back. Now when I run the command Are you sure? Java keytool can't export a privatekey to any kind of pem -- but it can export the CERT FOR a privatekey = the first or only cert in a privatekey entry to either DER or PEM (slightly confusingly called -rfc). That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) Java keytool CAN convert a jks privatekey (AND chain) to PKCS12 by doing -importkeystore with -deststoretype PKCS12. See below. Keytool -list -v -keystore store I can see the chain with the new intermediate in the middle. We are going to test the SSL part to validate. Has anyone does this to the Java keystore with OpenSSL ? OpenSSL cannot manipulate jks directly. OpenSSL can operate on PKCS12. If you use keytool to convert to PKCS12 (or, less likely, have PKCS12 already) you can use OpenSSL to unpack, modify, and rebuild the PKCS12, which keytool can then convert back to jks. But why bother? __ 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
RE: Application is failing with cipher or hash unavailable
From: owner-openssl-us...@openssl.org On Behalf Of pradeepreddy Sent: Thursday, 12 May, 2011 18:37 I have tried with all the ciphers. This same application works well on windows. I run my application again with s_server, but hit with the same error: SSL_ERROR_SSL error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash unavailable And on s_server [with -msg -debug], folwing messages are : client hello server hello SSL_accept:SSLv3 write certificate A TLS 1.0 Handshake [length 0004], ServerHelloDone 0e 00 00 00 SSL_accept:SSLv3 write server done A SSL_accept:SSLv3 flush data SSL_accept:failed in SSLv3 read client certificate A ERROR shutting down SSL CONNECTION CLOSED SSL_accept:failed in SSLv3 read client certificate A Both -msg and -debug should have given you (redundant) hex dumps of all messages; did you delete them? But only -state, which you didn't say you used, should give lines like 'SSL_accept:SSLv3 write server done A' . If there is no ServerKeyExchange (you didn't just delete it) then the selected suite probably uses RSA key agreement. But that doesn't help much; there are kRSA suites with all or nearly all data-ciphers and several hashes. You can decode the dump of client-hello to determine what list of suites (and compressions) the client is offering, and of server-hello to determine what the server selected. If you can install wireshark from www.wireshark.org on a personal Windows machine that sees the same network link, that can do the decode for you automatically. There may be equivalent tools for Unix, but I don't know. This mean, client and server are agreed on cipher. In what cases client verifies the TLS1_SETUP_KEY_BLOCK? which drove client to throw this error? It's not a matter of verifying. The client is trying to *do* setup for the selected suite, and also compression, and failing. Key setup is a slightly misleading name; it's actually setting several internal pointers as well as the actual keys, and this first step -- determining pointers effectively to code for the selected cipher, hash, and compression -- is what is failing. Most likely the client has offered a suite or compression it doesn't actually support, which it shouldn't, or some of OpenSSL's memory has been clobbered by a bug in your client. Look at the selected suite in server-hello, and compare to the build options for the build(s) you are using. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Replace renewed intermediate certificate in the keystore chain
So I tried that procedure. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. 1. If my lowermost leaf is first in the .pem file then a new alias is created and the certificate is imported. Not what I want. 2. If the new intermediate is first in the .pem file then the intermediate is renewed successfully. But the lowermost leaf is gone from the keystore. It is being deleted. The chain now has the root and the intermediate but the public key certificate. It is broken. Thanks, Mohan -Original Message- From: Mohan Radhakrishnan Sent: Friday, May 13, 2011 9:28 AM To: 'openssl-users@openssl.org' Subject: RE: Replace renewed intermediate certificate in the keystore chain Hi, Actually the procedure is similar 1. Use Keytool and convert JKS to PKCS12. 2. Use OpenSSL to convert PKCS12 contents to pem. Now this has the private key and the entire chain. 3. Use open source Java tool to build a new keystore *after replacing the intermediate with the one received*. List the keytool contents and verify the expiry date has changed. That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. I think this procedure is different. I think you mean that I have to export the lowermost leaf and then add the new intermediate and import it back using the same alias of the chain it will work. Will try this. (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) This point is not clear. The root is not touched at all either in the client's store or the server's store. Thanks, Mohan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Friday, May 13, 2011 6:41 AM To: openssl-users@openssl.org Subject: RE: Replace renewed intermediate certificate in the keystore chain From: owner-openssl-us...@openssl.org On Behalf Of Mohan Radhakrishnan Sent: Thursday, 12 May, 2011 00:04 I think I have been able to replace only the intermediate certificate which has a different validity period. I believe this can be done because what the intermediate certificate is signing is still valid. Only the expiry date is changing and it is being renewed. And the new intermediate is for the same key(pair) as the old, as surmised upthread? 1. Root is valid 2. Sub root or intermediate is replaced 3. Public key certificate is valid. No new CSR is required. I have done this by using keystore commands. From your example below, Java jks using keytool? I exported all the contents of the existing keystore including the private key as a .pem and then replaced only the new intermediate. This was imported back. Now when I run the command Are you sure? Java keytool can't export a privatekey to any kind of pem -- but it can export the CERT FOR a privatekey = the first or only cert in a privatekey entry to either DER or PEM (slightly confusingly called -rfc). That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) Java keytool CAN convert a jks privatekey (AND chain) to PKCS12 by doing -importkeystore with -deststoretype PKCS12. See below. Keytool -list -v -keystore store I can see the chain with the new intermediate in the middle. We are going to test the SSL part to validate. Has anyone does this to the Java keystore with OpenSSL ? OpenSSL cannot manipulate jks directly. OpenSSL can operate on PKCS12. If you use keytool to convert to PKCS12 (or, less likely, have PKCS12 already) you can use OpenSSL to unpack, modify, and rebuild the PKCS12, which keytool can then convert back to jks. But why bother? __ 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 List
