Re: Windows 2000 Professional does not consider valid certificates from Openssl 0.9.8

2005-11-29 Thread José Luis Gómez

Hello,
unfortunately it did not work. But I think it's not a problem but a 
misconfiguration: I've checked my openssl.cnf and I've noticed a 
property called nsCertType, which, if not set, means every purpose but 
object signing. I think this could be the problem with my user certificates.


Could it be that my problem? From the screenshots (not included), I see 
that the CA certificate is, as explained, taken as valid, but the 
personal certificates although linked to the CA, are invalid: This 
certificate issuer entity seems not authorized to issue certificates or 
it can not be used as a certificate for a final entity (sorry, message 
actually is in Spanish, that's only a translation).


In the openssl.cnf file I've also seen other property: CA: which can be 
FALSE or TRUE. I've understood that FALSE is for certificates and TRUE 
for CA's. But it's under X509v3 properties. Should I convert the 
cacert.pem file into x509 format as some howto's suggest?


Kind regards
Jose

Dr. Stephen Henson wrote:


On Mon, Nov 28, 2005, Jos Luis Gmez wrote:

 


Hello,
I have installed Openssl 0.9.8 in a Linux box. Then I've created my own 
CA (CA.sh -newca).
Then, I create a certificate for a Windows machine, with CA.sh -newreq, 
then CA.sh -sign to sign it. Then I convert them into PKCS12 format to 
export to a Windows 2000 Professional machine. This p12 contains the 
personal key and the server certificate:
/usr/local/ssl/misc# openssl pkcs12 -export -in newcert.pem -inkey 
newkey.pem -certfile demoCA/cacert.pem -out /tmp/client.p12


(some howtos explain that the key is in newreq.pem, but I've checked 
they are actually, at least for this version, in newkey.pem; actually if 
I try the former command with newreq.pem it complains about the missing 
private key).


Once under Windows, I import the file p12 under Root Certificate 
Authorities; Windows 2000 considers valid such CA certificate for all 
purposes.


Then, I import the p12 again as it contains the client key, under 
Personal certificates. But when I double click in it, it says that the 
certificate is invalid or the CA does not have authority to issue 
certificates. Hence I cannot  use IPSEC with this certificate, as IPSEC 
complains of not having any valid certificate.


I've installed previously the High Encription package in Windows 2000 
Professional box, so I don't understand the problem. The service pack is 
SP4, which, I think, it's the last available version.


Any help?

   



Don't use CA.sh use CA.pl instead.

Don't import the PKCS#12 file under root authorities. Instead import
cacert.pem and it should be added as a trusted root.

Then when you later import the PKCS#12 file it should verify correctly. 


Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


 



begin:vcard
fn;quoted-printable:Jos=C3=A9 Luis G=C3=B3mez
n;quoted-printable;quoted-printable:G=C3=B3mez;Jos=C3=A9 Luis
email;internet:[EMAIL PROTECTED]
x-mozilla-html:TRUE
version:2.1
end:vcard



Re: Questions about OCSP

2005-11-29 Thread Stefan Vatev
Citation from Dr. Stephen Henson [EMAIL PROTECTED]:

 On Mon, Nov 28, 2005, Stefan Vatev wrote:

 
  Hi guys,
  I had to look in-depth the ocsp stuff of openssl and
 some
  questions arise. Well, in ocsp.c I don't get why after
  trying OCSP_basic_verify(bs, verify_other, store,
  verify_flags) and the result is negative openssl ties
 to
  verify the signer's certificate again, but without the
  stack of certs (which to be verified) and all flags set
 to
  zero. I really don't understand this piece of code :(
 

 I have to admit that I wasn't sure why that was there
 either :-)

 Checking through CVS it looks like it is some legacy code
 from the initial
 support for -VAfile which is now handled differently and
 that isn't needed any
 more.

 Steve.


Another question that arises is that when -VAfile option is
supplied I think it's a good idea to set the OCSP_NOINTERN
flag for resoponse verification. My point is that if the
cert supplied by the -VAfile option is not able to verify
the response, then the ocsp cert from the response is used
for verification and I don't think that's expected in most
cases.
Anyway, I don't think it's a good idea to look at the certs
chain in the response either.

Stefan.


-

Всички говорят безплатно.
Каквото изговориш до 6-ти януари, се презарежда по твоята vivatel сметка на 
7-ми януари.
http://www.vivatel.bg/

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


RE: Certificates

2005-11-29 Thread Mark
Hi Goetz, 

 But since you are using an own program, this doesn't matter.
 
 Could you do an
 c_rehash ca_directory
 openssl verify -CApath ca_directory cert_to_check

error 20 at 0 depth lookup:unable to get local issuer certificate
 
 If this doesn't work, but a
 cat ca_directory/*.pem ca.pem
 openssl verify -CAfile ca.pem cert_to_check
 works, there is something really strange with your system ...

Same error:

error 20 at 0 depth lookup:unable to get local issuer certificate

Cheers, Mark
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


RE: ssl_connect timer???

2005-11-29 Thread seema . jagatap




Hi Mark,

Thanks for the response. I will try to explain my scenario a little
further.

My application does an ssl_connect. But the server application is buggy,
becuase of which the ssl_connect does not succeed, but returns
SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE error, which my application
interprets as an inporgress connection attempt.
However, the ssl_connect call does not seem to return at all even after a
long time. Thus, resources in my application which are associated with this
inprogress connection, remain indefinitely hanging.

Thus, there seems to be a need for ssl_connect to timeout, in order to
protect against such buggy servers. My query was:

1) Does ssl_connect have such an internal timeout mechanism after which the
OpenSSL will give up on the connection attempt and return failure for the
ssl_connect call?
OR
2) Does a client application have to implement such a timer in its own
scope?

Any pointers on the same will be appreciated.


thanks and regards
Seema



   
 Mark
 [EMAIL PROTECTED] 
 mail.com  To 
 Sent by:  openssl-users@openssl.org   
 owner-openssl-use  cc 
 [EMAIL PROTECTED]
   Subject 
   RE: ssl_connect timer???
 11/28/2005 03:02  
 PM
   
   
 Please respond to 
 [EMAIL PROTECTED] 
 nssl.org  
   
   




Hi,

 with a UA using SSL_connect and due to some reason if
 SSL_get_error returns
 SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE. For non
 blocking BIOs I belive the operation of
 SSL_connect with endpoint will still be going on in this case

Try using SSL_CTX_set_mode(ctx, SSL_MODE_AUTO_RETRY);

Mark.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]



***  FSS-Private   ***
DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


RE: ssl_connect timer???

2005-11-29 Thread Mark
Hi Seema, 

 Thus, there seems to be a need for ssl_connect to timeout, in order to
 protect against such buggy servers. My query was:
 
 1) Does ssl_connect have such an internal timeout mechanism 
 after which the
 OpenSSL will give up on the connection attempt and return 
 failure for the ssl_connect call?
 OR
 2) Does a client application have to implement such a timer in its own
 scope?

I'm not an expert at SSL but the only way I could see to do this is by
using non blocking I/O.  This will make SSL_connect() return with
SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE.  You can then use select()
to implement your timeout.

I think therefore that option (2) is the answer.

Hope this helps,
   Mark.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


A bio pairs question...

2005-11-29 Thread Usman Riaz

Hi*!
   I am implementing IOCP server (for Windows OS) supporting SSL. For SSL 
part i am trying to use OpenSSL's bio pairs. I have looked at the example in 
ssltest.c. As i understand (please correct me if i am wrong) of the three 
bios (s_ssl_bio, server, server_io) that get created in doit_biopair 
function, the server_io bio is used to read/write Encrypted data  the 
s_ssl_bio is used to read/write UNEncrypted data. I have setup my code 
according to this principle. Now when the client connects, it sends some 
ssl-handshake (Encrypted) data  I have to write it server_io. Here is 
how my function looks for writing to server_io BIO.


bool CSSLSession::OnRecv(const std::string RecvData)
{
bool bRet = false;
char *pData = NULL;
int nRet = -1;
int nLen = -1;

nLen = BIO_ctrl_get_read_request(m_SessionInfo.ioBio);

if( !nLen )
{
bRet = true;
return bRet;
}

nRet = BIO_nwrite0(m_SessionInfo.ioBio, pData);

if( 0 = nRet || nLen  nRet || !pData )
{
return bRet;
}

nRet = nLen;

#pragma warning (disable : 4018)
if( nRet  RecvData.size() )
{
nRet = RecvData.size();
}
#pragma warning (default: 4018)

memcpy(pData, RecvData.data(), nRet);

nRet = BIO_nwrite(m_SessionInfo.ioBio, pData, nRet);
BIO_flush(m_SessionInfo.ioBio);

bRet = true;

return bRet;
}

I am for the time being not handling the retry options (will implement 
later). Now the problem is this call nLen = 
BIO_ctrl_get_read_request(m_SessionInfo.ioBio); always return 0  the 
function returns after that. Shouldn't the SSL engine be wating for some 
data on start of server side session?? since its the client who always sends 
the handshake data first. Can anyone help me solve this problem??? I check 
the return values while setting up ssl context and SSL objects and they all 
are retuning success.

Thanks in Advance,
Regards,
Usman.

_
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Re: Windows 2000 Professional does not consider valid certificates from Openssl 0.9.8

2005-11-29 Thread Dr. Stephen Henson
On Tue, Nov 29, 2005, Jos Luis Gmez wrote:

 Hello,
 unfortunately it did not work. But I think it's not a problem but a 
 misconfiguration: I've checked my openssl.cnf and I've noticed a 
 property called nsCertType, which, if not set, means every purpose but 
 object signing. I think this could be the problem with my user certificates.
 

nsCertType is ignored by applications that use windows for its cryptography.

 Could it be that my problem? From the screenshots (not included), I see 
 that the CA certificate is, as explained, taken as valid, but the 
 personal certificates although linked to the CA, are invalid: This 
 certificate issuer entity seems not authorized to issue certificates or 
 it can not be used as a certificate for a final entity (sorry, message 
 actually is in Spanish, that's only a translation).
 

If you used CA.pl to create the certificates, correctly installed
cacert.pem in the trusted root store and imported the PKCS#12 file that
shouldn't happen. If there are some invalid certificates in the root store
(e.g. a client certificate from a previous attempt) that could cause problems.


 In the openssl.cnf file I've also seen other property: CA: which can be 
 FALSE or TRUE. I've understood that FALSE is for certificates and TRUE 
 for CA's. But it's under X509v3 properties. Should I convert the 
 cacert.pem file into x509 format as some howto's suggest?
 

If cacert.pem is imported into the root store and visible then there's no
point in converting it to DER format.

Any howto that suggests converting to x509 format is more than a little
confused.

If you still can't get this to work can you send a test PKCS#12 file and its
password to me?

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Re: A bio pairs question...

2005-11-29 Thread Alain Damiral

Hi there,

You might have missed one thing in ssltest.c... there is a first call to 
BIO_read on the server side before any data is available. Before that 
call, the read request on server_io is actaully 0. After the call to 
BIO_read, then some data is requested. So if you're using read request, 
the trick would be to first attempt a read before any data is available.


You can also try using write_guarantee. This basically would allow more 
data than requested to be available on the network BIO. In either case, 
be careful not to drop data that you have received from the network but 
that couldn't be fed into the network BIO right away. Since SSL uses a 
reliable transport layer, the other end can rightfully assume that this 
data has been received and it has no obligation to resend it. In your 
code it seems that this would be what is contained at the end in pData, 
beyond offset nRet - I think you should buffer this for future use...


I hope this makes sense and helps :)


Usman Riaz wrote:


Hi*!
   I am implementing IOCP server (for Windows OS) supporting SSL. For 
SSL part i am trying to use OpenSSL's bio pairs. I have looked at the 
example in ssltest.c. As i understand (please correct me if i am 
wrong) of the three bios (s_ssl_bio, server, server_io) that get 
created in doit_biopair function, the server_io bio is used to 
read/write Encrypted data  the s_ssl_bio is used to read/write 
UNEncrypted data. I have setup my code according to this principle. 
Now when the client connects, it sends some ssl-handshake 
(Encrypted) data  I have to write it server_io. Here is how my 
function looks for writing to server_io BIO.


bool CSSLSession::OnRecv(const std::string RecvData)
{
bool bRet = false;
char *pData = NULL;
int nRet = -1;
int nLen = -1;

nLen = BIO_ctrl_get_read_request(m_SessionInfo.ioBio);

if( !nLen )
{
bRet = true;
return bRet;
}

nRet = BIO_nwrite0(m_SessionInfo.ioBio, pData);

if( 0 = nRet || nLen  nRet || !pData )
{
return bRet;
}

nRet = nLen;

#pragma warning (disable : 4018)
if( nRet  RecvData.size() )
{
nRet = RecvData.size();
}
#pragma warning (default: 4018)

memcpy(pData, RecvData.data(), nRet);

nRet = BIO_nwrite(m_SessionInfo.ioBio, pData, nRet);
BIO_flush(m_SessionInfo.ioBio);

bRet = true;

return bRet;
}

I am for the time being not handling the retry options (will implement 
later). Now the problem is this call nLen = 
BIO_ctrl_get_read_request(m_SessionInfo.ioBio); always return 0  the 
function returns after that. Shouldn't the SSL engine be wating for 
some data on start of server side session?? since its the client who 
always sends the handshake data first. Can anyone help me solve this 
problem??? I check the return values while setting up ssl context and 
SSL objects and they all are retuning success.

Thanks in Advance,
Regards,
Usman. 




--
Alain Damiral,

Université Catholique de Louvain - student
alain.damiral'at'student.info.ucl.ac.be

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Re: A bio pairs question...

2005-11-29 Thread Usman Riaz


Thanks for the reply Alain, I have changed as you mentioned by placing a 
call to do a read on s_ssl_bio (for reading/writing UNEncrypted Data). Here 
is how that function looks like...


bool CSSLSession::GetData(std::string RecvData)
{
	/*The RecvData WILL contain UN-ENCRYPTED-DATA that was received 
earlier*/

bool bRet = false;
int nRet = -1;
char RecvBuffer[BUF_LEN * 2] = {0, };

memset(RecvBuffer, 0, sizeof(char) * (BUF_LEN * 2));

	nRet = BIO_read(m_SessionInfo.SSLBio, RecvBuffer, sizeof(char) * (BUF_LEN * 
2));

if( 0  nRet )
{
if( !BIO_should_retry(m_SessionInfo.SSLBio) )
{
return bRet;
}
/* Ignore BIO_should_retry for the time being */
   nRet = 1;
}
   else
   {
   if( nRet )
   {
   RecvData.assign(RecvBuffer, nRet);
   }
   }

if( nRet )
{
bRet = true;
}

return bRet;
}

Now, in the above function, BIO_should_retry returns true or 1 so 
afterwards i call the function (the one mentioned in my first post) to write 
data to server_io BIO (that was received from the client socket). This 
time BIO_ctrl_get_read_request(m_SessionInfo.ioBio); returns 5, and i 
write 5 bytes to the BIO and return (even though i always get something like 
105 bytes in the beginning from the client). Now what should be done next 
with those remaining bytes??? Should try to write on the server_io BIO 
again (i tried that but the second time BIO_ctrl_get_read_request returns 
0. Can you please help me sort this out.

Thanks in Advance,
Regards,
Usman.



My mail server crashed just before I could send this reply to the list so 
I'm using another email to send it directly to you. You can reply to the 
list if there are further questions...



Hi there,

You might have missed one thing in ssltest.c... there is a first call to 
BIO_read on the server side before any data is available. Before that call, 
the read request on server_io is actaully 0. After the call to BIO_read, 
then some data is requested. So if you're using read request, the trick 
would be to first attempt a read before any data is available.


You can also try using write_guarantee. This basically would allow more data 
than requested to be available on the network BIO. In either case, be 
careful not to drop data that you have received from the network but that 
couldn't be fed into the network BIO right away. Since SSL uses a reliable 
transport layer, the other end can rightfully assume that this data has been 
received and it has no obligation to resend it. In your code it seems that 
this would be what is contained at the end in pData, beyond offset nRet - I 
think you should buffer this for future use...


I hope this makes sense and helps :)

_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


b-etch: воспроизведение проблемы (fwd)

2005-11-29 Thread Dmitry Belyavsky
Greetings!

We use openssl 0.9.8a, apache 1.3.34 with mod_ssl 2.8.25 (Debian etch).
The URL we request requires client certificate.

The command is:

zsh% openssl s_client -cipher DHE-DSS-AES256-SHA -cert 
U_x_dsa_dsaparams.pem/cert.pem -key U_x_dsa_dsaparams.pem/seckey.pem -CAfile 
ca_dsa.pem -connect b-etch.vm.cryptocom.ru:444 -ign_eof

The result is:

CONNECTED(0003)
depth=1 /C=RU/L=Moscow/CN=DSA Test CA/O=Cryptocom/OU=OpenSSL CA/[EMAIL 
PROTECTED]
verify return:1
depth=0 /C=RU/O=Cryptocom/OU=OpenSSL team/CN=b-etch.vm.cryptocom.ru/[EMAIL 
PROTECTED]
verify return:1
---
Certificate chain
 0 s:/C=RU/O=Cryptocom/OU=OpenSSL team/CN=b-etch.vm.cryptocom.ru/[EMAIL 
PROTECTED]
   i:/C=RU/L=Moscow/CN=DSA Test CA/O=Cryptocom/OU=OpenSSL CA/[EMAIL PROTECTED]
 1 s:/C=RU/L=Moscow/CN=DSA Test CA/O=Cryptocom/OU=OpenSSL CA/[EMAIL PROTECTED]
   i:/C=RU/L=Moscow/CN=DSA Test CA/O=Cryptocom/OU=OpenSSL CA/[EMAIL PROTECTED]
---
Server certificate
-BEGIN CERTIFICATE-
MIIDMDCCAvCgAwIBAgICAPYwCQYHKoZIzjgEAzCBgDELMAkGA1UEBhMCUlUxDzAN
BgNVBAcTBk1vc2NvdzEUMBIGA1UEAxMLRFNBIFRlc3QgQ0ExEjAQBgNVBAoTCUNy
eXB0b2NvbTETMBEGA1UECxMKT3BlblNTTCBDQTEhMB8GCSqGSIb3DQEJARYSdml0
dXNAY3J5cHRvY29tLnJ1MB4XDTA1MTEyODEzMzUxNVoXDTA2MTEyODEzMzUxNVow
fDELMAkGA1UEBhMCUlUxEjAQBgNVBAoTCUNyeXB0b2NvbTEVMBMGA1UECxMMT3Bl
blNTTCB0ZWFtMR8wHQYDVQQDExZiLWV0Y2gudm0uY3J5cHRvY29tLnJ1MSEwHwYJ
KoZIhvcNAQkBFhJ2aXR1c0BjcnlwdG9jb20ucnUwggG3MIIBLAYHKoZIzjgEATCC
AR8CgYEAyBVEivTrdfcSjI7eva1z9iuzeJphZ3BCkvR3HIEAiDHDZrMLqTjTs/cn
UbfzVsTELUE+OHp6k+GCa1ejqnHEvA2TlofU3kY2KnvCDsbOZkkL1EltnT/Tvrpm
gtMDWZqlJNKTEun5Y7+rvZ7c7WKcd/WDTfNxwQVlczoB+hnkozUCFQCiqb/SJFJ5
CykhPPOQ4eyXad4eTwKBgQCtzKpmgy6+4NEAaVt5qP0CaqqysBTslwdiyzJ7iuc/
SCBpzd2tur4ntBg6X3vPkU7nckJluXUudwc+wvCoXzE6cKAZkUdxEUwVTg8NW2dD
B7FXgMglr0gCWb373wc+f9xlX6zk8g1rKKmgouxk2Cq180Kpqevhk3RV9hWw66bP
bQOBhAACgYAxvt282siMxPPNIJzK/tN8qG11PFfnYLkH94GjKSS30NY8zwnK0W+s
VrsHNyComxnp3MqHLVq+KH/6WAGETwCLtH5FepcRxp+hwib6wki7Kklj1xXx24Kr
Nd0iLSLJovOBrXfWFJrEK31YU/qp7ROS/hSdGORMvc3+9IlUye2LJjAJBgcqhkjO
OAQDAy8AMCwCFCPEhKtJ35S1RhKscutAmmrVSX40AhQEZKhZG1Pg6mTP8kO4CHet
cr4jhA==
-END CERTIFICATE-
subject=/C=RU/O=Cryptocom/OU=OpenSSL team/CN=b-etch.vm.cryptocom.ru/[EMAIL 
PROTECTED]
issuer=/C=RU/L=Moscow/CN=DSA Test CA/O=Cryptocom/OU=OpenSSL CA/[EMAIL PROTECTED]
---
No client certificate CA names sent
---
SSL handshake has read 2126 bytes and written 247 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-DSS-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: DHE-DSS-AES256-SHA
Session-ID: E3EAF6401AF1F8157A2653118728FE9A15322C97FDCC8AFCB084326CE1C9C227
Session-ID-ctx:
Master-Key: 
DABB6DC00DA8A621316F9711263F13D9ED8DE59CC6A5F33800A4D7DCE0135132FF8D30148363A33CDF1C978CD4B974E2
Key-Arg   : None
Start Time: 1133270656
Timeout   : 300 (sec)
Verify return code: 0 (ok)
---
GET /ssl_auth_test.html
depth=1 /C=RU/L=Moscow/CN=DSA Test CA/O=Cryptocom/OU=OpenSSL CA/[EMAIL 
PROTECTED]
verify return:1
depth=0 /C=RU/O=Cryptocom/OU=OpenSSL team/CN=b-etch.vm.cryptocom.ru/[EMAIL 
PROTECTED]
verify return:1
4119:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
record mac:s3_pkt.c:426:

The bug is reproduced about 4 times from 5.

When I add -ssl3 key to command line, I successfully get the page I
request.

openssl-0.9.7 s_client doesn't get an error anyway.

What's wrong?

Thank you!

--
SY, Dmitry Belyavsky (ICQ UIN 6575)


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Re: b-etch: ??????????????? ???????? (fwd)

2005-11-29 Thread Victor Duchovni
On Tue, Nov 29, 2005 at 05:32:45PM +0300, Dmitry Belyavsky wrote:

 Greetings!
 
 We use openssl 0.9.8a, apache 1.3.34 with mod_ssl 2.8.25 (Debian etch).
 The URL we request requires client certificate.
 
 4119:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
 record mac:s3_pkt.c:426:
 
 The bug is reproduced about 4 times from 5.
 
 When I add -ssl3 key to command line, I successfully get the page I
 request.
 
 openssl-0.9.7 s_client doesn't get an error anyway.
 
 What's wrong?
 

http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/2005-November/000418.html

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Re: b-etch: problems with openssl-0.9.8a

2005-11-29 Thread Dmitry Belyavsky
Greetings!

On Tue, 29 Nov 2005, Victor Duchovni wrote:

 On Tue, Nov 29, 2005 at 05:32:45PM +0300, Dmitry Belyavsky wrote:

  Greetings!
 
  We use openssl 0.9.8a, apache 1.3.34 with mod_ssl 2.8.25 (Debian etch).
  The URL we request requires client certificate.
 
  4119:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
  record mac:s3_pkt.c:426:
 
  The bug is reproduced about 4 times from 5.
 
  When I add -ssl3 key to command line, I successfully get the page I
  request.
 
  openssl-0.9.7 s_client doesn't get an error anyway.
 
  What's wrong?
 

 http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/2005-November/000418.html

Thank you!
Whether debian team or openssl team has plans to fix it?

-- 
SY, Dmitry Belyavsky (ICQ UIN 6575)
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Re: any way to debug signature verification failure?

2005-11-29 Thread john guerrero

hi steve,

ok, i tried:
openssl rsautl -verify -in sigfile -pubin -inkey public.pem -asn1parse

and got:
RSA operation error
15946:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block 
type is not 01:rsa_pk1.c:100:
15946:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check 
failed:rsa_eay.c:580:


i'm interpreting this to be the invalid block type that you mentioned 
earlier...so it's either a corrupted signature or else it was signed 
with a different key.  i got this same error when trying both keys that 
i have.


is my understanding correct?

as for readable output, do you mean something like this?  (which i got 
from a known good combination)

   0:d=0  hl=2 l=  33 cons: SEQUENCE
   2:d=1  hl=2 l=   9 cons:  SEQUENCE
   4:d=2  hl=2 l=   5 prim:   OBJECT:sha1
  11:d=2  hl=2 l=   0 prim:   NULL
  13:d=1  hl=2 l=  20 prim:  OCTET STRING
snip


thanks,
jlg

Dr. Stephen Henson wrote:


On Wed, Nov 23, 2005, john guerrero wrote:

 


i have a signature that fails verification.

openssl dgst -sha1 -verify public.pem -signature sigfile myfile
Verification Failure

this one particular pair (sigfile, myfile) fails verification out of a 
group of 500,000 pairs which all succeed.


there are at least 2 possbilities for this that i can think of:
1. it was signed with a different key
2. something corrupted the variable holding the signature before it made 
it to disk


is there some way of looking at the hex of the signature and 
distinguishing between these 2 possibilities?


i have enough other checks to verify that the file and signature were 
not tampered with since they were originally written.


   



Try:

openssl rsautl -verify -in sigfile -pubin -inkey public.pem -asn1parse

if you get an error message about invalid block type it could be the wrong key
or possibly a corrupted signature. Otherwise if you get some readable output
it will tell you the digest it is expecting to see.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

 



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Re: any way to debug signature verification failure?

2005-11-29 Thread Dr. Stephen Henson
On Tue, Nov 29, 2005, john guerrero wrote:

 hi steve,
 
 ok, i tried:
 openssl rsautl -verify -in sigfile -pubin -inkey public.pem -asn1parse
 
 and got:
 RSA operation error
 15946:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block 
 type is not 01:rsa_pk1.c:100:
 15946:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check 
 failed:rsa_eay.c:580:
 
 i'm interpreting this to be the invalid block type that you mentioned 
 earlier...so it's either a corrupted signature or else it was signed 
 with a different key.  i got this same error when trying both keys that 
 i have.
 
 is my understanding correct?
 

Those are by far the most likely possibilities. 

There is an outside chance that its a bug in OpenSSL which produces an invalid
signature or causes the verify to fail.

If you are pretty sure it was signed with one of those keys then you can check
that out by attempting to sign the data again using each key and comparing the
signature to the original.

If you get a match then its an OpenSSL bug.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


steps to use a dynamic engine from an application

2005-11-29 Thread Anil Gunturu
I am just wondering about the steps to use a dynamic engine. Can somebody verify this:   e = ENGINE_by_id("dynamic");   if (!e) { return RC_ERROR; }   if ((!ENGINE_ctrl_cmd_string(e, "SO_PATH", so_path, 0)) || (!ENGINE_ctrl_cmd_string(e, "ID", "ATHENA", 0)) || (!ENGINE_ctrl_cmd_string(e, "LOAD", NULL, 0))) { ENGINE_free(e); return RC_ERROR; } if (!ENGINE_init(e)) { ENGINE_free(e); return RC_ERROR; }  
  ENGINE_set_default_RSA(e);Also, when do I need to call ENGINE_finish() and ENGINE_free()?  Thanks,  -Anil
		 Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

Re: Certificates

2005-11-29 Thread Goetz Babin-Ebell

Mark wrote:
Hi Goetz, 


But since you are using an own program, this doesn't matter.

Could you do an
c_rehash ca_directory
openssl verify -CApath ca_directory cert_to_check


error 20 at 0 depth lookup:unable to get local issuer certificate
 

If this doesn't work, but a
cat ca_directory/*.pem ca.pem
openssl verify -CAfile ca.pem cert_to_check
works, there is something really strange with your system ...


Same error:

error 20 at 0 depth lookup:unable to get local issuer certificate


This indicates that your CA certificate is not in any of the *.pem
files in your CA directory.

if an
openssl verify -CAfile your_ca_file cert_to_check
succeeds, then the CA cert is int the file but not
in the CA dir (at least not with the suffix .pem).

Is it possible you stored the ca cert with an other suffix
(like .crt) ?

Bye

Goetz

--
DMCA: The greed of the few outweighs the freedom of the many


smime.p7s
Description: S/MIME Cryptographic Signature


Re: steps to use a dynamic engine from an application

2005-11-29 Thread Geoff Thorpe
Hi there,

On November 29, 2005 03:05 pm, Anil Gunturu wrote:
 I am just wondering about the steps to use a dynamic engine. Can
 somebody verify this:

   e = ENGINE_by_id(dynamic); 
   if (!e) {
 return RC_ERROR;
 }
   if ((!ENGINE_ctrl_cmd_string(e, SO_PATH, so_path, 0)) ||
 (!ENGINE_ctrl_cmd_string(e, ID, ATHENA, 0)) ||
 (!ENGINE_ctrl_cmd_string(e, LOAD, NULL, 0)))
 {
 ENGINE_free(e);
 return RC_ERROR;
 }

All of that should be equivalent to ENGINE_by_id(athena) if the engine 
has the appropriate name/path and you're using a recent version of 
openssl. But if that works for you, cool.

   if (!ENGINE_init(e)) {
 ENGINE_free(e);
 return RC_ERROR;
 }

   ENGINE_set_default_RSA(e);

   Also, when do I need to call ENGINE_finish() and ENGINE_free()?

Up until you call ENGINE_init() all you have is a *structural* reference, 
the engine may not be able to do anything (eg. if it's for hardware you 
don't have) but it lets you manipulate it. This reference should be 
released by ENGINE_free(). If ENGINE_init() succeeds, you have a 
*functional* reference as well, which is released by ENGINE_finish(). In 
your case, you've got one of each kind of reference so you'd need to 
release both.

However, ENGINE_set_default_RSA() will attempt to initialise the engine if 
it's not already initialised anyway (it can't be a default unless it's 
*working*). So don't bother trying to initialise it, then you only need 
to call ENGINE_free() once you're done. You need to check the return 
value of ENGINE_set_default_RSA() though if you want to know if it 
succeeded.

BTW, your application needs to call ENGINE_cleanup() when closing down, as 
this releases any/all internal references. Eg. ENGINE_set_default_RSA() 
causes an internal functional reference to be kept internally to prevent 
the engine from deinitialising/unloading.

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.openssl.org/

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]