strange Problem with Bio_do_connect
Hello Everybody,
i have very strange problem.
I'am trying to write a FTP Client for using with FTPES.
so here are the steps i perform
1) Connect to the FTP Server with unsecured BIO on port 21, works fine.
2) Sending AUHT TLS and perform SLL_Connect Get a new BIO and aply the SSL to
the BIO with BIO_set_ssl, works fine.
3) Login to the Server with regular FTP Commands
4) Sending FTP PASV Commonad to the Server and retriving port Number for Data
Connection
5) Connect to the Dataport with a new secured BIO
and now something strange happens. I'am working with non Blocking IO
BIO_do_connect return -1 and BIO_should_retry returns false, but the Connection
is established, I Can see the Connection in TCPView.
So if I Ignore that i can send Commands on the Command Connection and receive
Data on the Data Connection for witch BIO_do_connect has failed.
I'am using openssl-1.0.0.d and running on Windows XP, can anyobody help?
Here the Code i'am Using. I have written a own Socketclass using openssl i'am
also using in other Projects, but some stange behavior i didnt have seen
anytime before.
In that case m_SSLCtx is not NULL and m_bBlocking is false.
nt SecureSocket::Connect( )
{
SSL* ssl;
if( NULL == m_SSLCtx )
{// Erstmal Unverschlüsselt, Es kann später immer noch eine Explizite
Verschlüsselung mit der Funktion STARTTLS gesetzt werden
m_bio = BIO_new_connect( m_sConnect.Ptr() );
if( NULL == m_bio )
{
QError.Message( LogOnly,21410, QText(21410, m_sConnect
),
QString( DLL/QInet
SecureSocket::Connect $1$,
ERR_error_string(ERR_get_error(), NULL) ) );
return CONNECT_ERROR;
}//if( NULL == m_bio )
}//if( NULL == m_SSLCtx )
else
{
//Impliziete SLL Verschlüsselung. Heißt wir bauen eine Verbindung immer
von Anfang an verschlüsselt auf
m_bio = BIO_new_ssl_connect(m_SSLCtx);
if( NULL == m_bio )
{
QError.Message( LogOnly,21409, QText(21409, m_sConnect
),
QString( DLL/QInet
SecureSocket::Connect $1$,
ERR_error_string(ERR_get_error(), NULL) ) );
return CONNECT_ERROR;
}//if( NULL == m_bio )
BIO_get_ssl(m_bio, ssl);
SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY); //Auto Retry falls
Blocking Mode
BIO_set_conn_hostname(m_bio, m_sConnect.Ptr() );
}//else zu if( NULL == m_SSLCtx )
if( !m_bBlocking )
{
BIO_set_nbio( m_bio, 1 );
bool bRetry = false;
int r = 0;
do
{
r= BIO_do_connect( m_bio );
}while( r = 0 BIO_should_retry( m_bio) );
if( r = 0 )
{
QError.Message( LogOnly,21410, QText(21410, m_sConnect
),
QString( DLL/QInet
SecureSocket::Connect $1$,
ERR_error_string(ERR_get_error(), NULL) ) );
return CONNECT_ERROR;
}
}
else
{
if( 0 = BIO_do_connect( m_bio ) )
{
QError.Message( LogOnly,21410, QText(21410, m_sConnect
),
QString( DLL/QInet
SecureSocket::Connect $1$,
ERR_error_string(ERR_get_error(), NULL) ) );
return CONNECT_ERROR;
}//if( 0 = BIO_do_connect( m_bio ) )
}
if( NULL != m_SSLCtx )
{
int r = SSL_get_verify_result(ssl);
if( X509_V_OK != r )
{
if( !m_IgnoreTrusStoreError )//Sollen wir das
ignorieren?
{
QError.Message( LogOnly,21415, QText(21415, m_sConnect, QString(r)
),
QString( DLL/QInet
SecureSocket::Connect \n$1$,
GetZertifikatInfo(
SSL_get_peer_certificate(ssl) ) ) );
return CONNECT_NOTRUSTCERT;
}//if( !m_IgnoreTrusStoreError )
}//if(SSL_get_verify_result(ssl) != X509_V_OK)
}
return CONNECT_OK;
}//int
Problems with certificates validity dates
Hi list, I'm currently setting up a small PKI using Bash scripts calling OpenSSL and Apache. However, whatever days of validity I put on the command line, it remains to it's default, 365 days. - On the CSR generation side, i'm using the following command : $openssl req -config $dossier/$config -new -newkey rsa:4096 -subj $subject -nodes -keyout $dossier/test/$filename.key -out $dossier/test/$filename.csr In the OpenSSL conf used on this side : default_days= 3650 - On the CS validation side, I use the following command : $openssl ca -config $dossier/$config -policy policy_match -out $dossier/subca/$filename.crt -infiles $dossier/requests/$filename.csr -days 3650 Still, I get the following output when OpenSSL asks me if I want to confirm the certificate validation : Certificate Details: Serial Number: 1 (0x1) Validity Not Before: Jun 28 14:53:37 2011 GMT Not After : Jun 27 14:53:37 2012 GMT Subject: countryName = *** stateOrProvinceName = *** organizationName = *** organizationalUnitName= *** commonName= *** emailAddress = *** X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: Object Signing Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: DA:55:28:C2:BF:03:F4:C9:2F:E5:00:13:F3:8B:0D:39:72:61:6B:EA X509v3 Authority Key Identifier: keyid:CF:01:8E:EF:EF:65:44:08:77:61:69:96:73:CA:83:8F:56:6A:55:E5 Certificate is to be certified until Jun 27 14:53:37 2012 GMT (365 days) And I just can't seem to understand why. Any ideas guys ? Eric
RE: Problems with certificates validity dates
From: owner-openssl-us...@openssl.org On Behalf Of Eric Viseur Sent: Tuesday, 28 June, 2011 11:11 I'm currently setting up a small PKI using Bash scripts calling OpenSSL and Apache. However, whatever days of validity I put on the command line, it remains to it's default, 365 days. - On the CSR generation side, i'm using the following command : snip; and config That doesn't matter. The CSR doesn't specify the lifetime. - On the CS validation side, I use the following command : $openssl ca -config $dossier/$config -policy policy_match -out $dossier/subca/$filename.crt -infiles $dossier/requests/$filename.csr -days 3650 Still, I get snip: 365 days And I just can't seem to understand why. Any ideas guys ? -infiles causes all subsequent arguments to be treated as input files, and not checked for options. If you proceed(ed) you should get (have gotten) an error for no such file -days. Either put -days N before -infiles, or use -in instead of -infiles. Or use default_days in config *for ca* instead of commandline. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How much memory leaks for BIO, SSL and SSL_CTX
Hi, Its a very vague question, it will be great if someone can answer? How much memory leak per connection if we do not free BIO, SSL and SSL_CTX. Thanks. // Harshvir
Re: Reliable identification by DN (or something else) for commercially-signed certs?
On 26 June 2011 22:39, Leo Richard Comerford leocomerf...@gmail.com wrote: Hello. CA? - viz. the cross-signing spaghetti of doubt and so on. If the answer is 'no' - if DN (or DN alone) won't guarantee uniqueness under those circumstances - is there some other field, or combination of fields, which would? DN plus Issuer? SubjectAltName? While others offers you to become a CA itself and other external auth. solutions, I would like to advice to consider to use CN, O or OU fields. CN= is normally a human name Brian Adams. (For client certificates it is not web-server DNS-name!) O= is an organisation. My Mega Company Inc. for example. OU= is an organisation unit. Accaount Department for example. You may use combination of these parameters for you proposes. Andrey.
