Re: RFC 4130 checksum in SHA1
Hi and thanks again: Completely clear. I found some weird content in the original message which is only a XML in 2 lines. It's not a multipart (not a multipart inside another multipart, but only an XML in UTF-8, which is then signed and finally encrypted, then sent). The weird content to which I refer is that the original message is not exactly UTF-8. And also, when verifying, the crlf just after the XML content -and before the boundary- is removed, because that's not part of original content. I will be testing with my trading partner what is exactly the original content but this time sent via email, because I suspect this parter has her UTF-8 file (the very original one), which produces the right MIC, but the encoder of her WebSphere saves it in ISO-8859-1, according the codes shown in certain word which is the name of the othe trading partner. (i.e. DISEÑOS is transformed to DISEÃOS if you see the UTF-8 as ISO-8859-1, but this time I'm reading the content as UTF-8 and I don't see DISEÑOS) I think we are close to the end of this problem. Greetings jkoehring wrote: The mechanism for calculating the MIC for an AS2 message is exactly the same as that for an AS1 message. The two protocols are practically identical except that the outermost contents of AS1 messages are frequently encoded (base64 , quoted-printable, etc) so that they may be transported safely over SMTP. Otherwise, AS21 and AS2 messages are packaged identically. p The paragraph you are referring to in section 7.1 of RFC 4130 is referring to the situation in which the data being transported in an AS2 message is a multipart. That is, the first part of the multipart/signed is, itself, another multipart. It is not saying that the MIC should be calculated over the entire multipart/signed, just the first part of the multipart/signed. p Another way to look at it is when the original AS2 message is signed, the MIC for the MDN should be exactly the same as the hash used in the calculation of the signature for the multipart/signed. -- View this message in context: http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p18067119.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 [EMAIL PROTECTED]
Re: RFC 4130 checksum in SHA1
jkoehring wrote: I have to admit, I am not very familiar with the openssl commands. The one question I have is exactly what are the contents of original.txt after running the commands you list? Does it contain exactly the contents of the first part of the multipart/signed? javierm wrote: Thanks for the wait: Well, these are the steps followed ul li Encrypted body with Mime headers.- body decrypted and multipart/signed message obtained/li li Signature in binary, so processed with openssl pkcs7 to convert the binary signature to b64 (script in perl to extract the binary signature, process it with pkcs7 it and put it back in between the 2nd an 3rd boundary, Content-transfer-encoding changed from : binary to base64--- file produced: signed.txt/li li openssl smime -verify -in signed.txt -nosigs -noverify -signer who.pem -out original.txt (successful, cert found inside used in signature written to who.pem-yes the signer is right)/li li openssl sha1 -binary original.txt|openssl enc -a , /li li and... I don't get the signature that the signer claims I should get!! :confused:/li /ul What do you think? Thanks javierm wrote: Hi jkoehring: pThanks a lot for the help, (ah just noticed another reply from you on this question placed in another way, thanks). I tried that part too but did not get the expected checksum. Not that I doubt what you say, but perhaps I'm mistaken at some point. When I do the verify, the openssl smime -verify outputs the original document and optionally the certificate. I was doing the checksum not after the verification, but instead, I was just processing the multipart/signed document, and extracting the first portion between the first and second boundary. I will do it again right now and be right back./p pOn the other hand, don't you think the 7.1.8 paragraph of RFC4130 misleads one, by saying div style=background-color:#cc; border:1px solid red; margin:20px MIC MUST be calculated across the entire multi-part content, including the MIME headers./div It seems to me a trick to give clients to somebody./p pThanks/p Later, br Javier jkoehring wrote: If I understand your question correctly, you are asking how to calculate the MIC (SHA1 checksum) to put in an AS2 MDN. p The MIC should be calculated over exactly that data that was signed in the original AS2 message. The data used to calculate the MIC should not include the actual signature. Thus, the MIC should be calculated over that data that appears between the first two boundary markers in the multipart/signed of the original AS2 message. Note that the first boundary marker includes the trailing CRLF and the second boundary marker includes the leading CRLF. Thus, those CRLF sequences should not be included in the MIC calculation. javierm wrote: Can anyone help me with the procedure to calculate the message integrity check in this RFC? it's about calculating the sha1 checksum over a multipart message. This is the text in the RFC (http://www.ietf.org/rfc/rfc4130.txt), chapter 7.1, paragraph 8) div style=color:#ff; background:#cc; font-size:8pt; border:1px solid red; margin:20px The EC Interchange and the RFC 1767 MIME EDI content header can actually be part of a multi-part MIME content-type. When the EDI Interchange is part of a multi-part MIME content-type, the MIC MUST be calculated across the entire multi-part content, including the MIME headers. /div My problem is that i think I understood, but another software gives me a different checksum for the same message. ul liI canonicalize headers, no problem/li liI process signature of message with openssl which provides a multipart file/li liI calculate sha1 over exactly that output file/li /ul Is there something done wrong in this procedure? Whant to try some examples? This file is a multipart output from openssl http://www.nabble.com/file/p18034577/mictest.txt mictest.txt Ok, not directly. Because openssl produces the base64 signature, which I detach to then transform to binary or DER and I attach it back, with the corresponding change in Content-enconding: binary. For this file I get IpWFspJ2hKwfja5CkOPnDW2ctT8= The other trading partner says: Uiaz1kOChhlSb/f3SJsmJ/O/8SI= Could this be a mere misunderstanding of the RFC?, I've seen way different interpretations on the net, which I have tried but don't work either. Well thanks for the help -- View this message in context: http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p18067148.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 [EMAIL PROTECTED]
using NNTPS (nnrp with ssl) with windows mail / thunderbird on windows vista
Hello, i have working nnrpd with SSL configuration. I am using my custom generated SSL certificate signed with my own Certification Authority. Each time i am accessing news in Windows Mail client i am getting message , that certificate is not trusted and cannot be verified. I want to get rid off this message by importing my custom CA (or probably custom certificate) into windows certification storage and make it trusted so i will not get this message again. So far, i have converted my cacert.pem to der format using : openssl x509 -inform PEM -outform DER -in cacert.pem -out cacert.der Then, i have converted my nnrpd certificate to pk12 format using: openssl pkcs12 -export -clcerts -in nnrpd.cert.pem -inkey nnrpd.key.pem -out clcert.p12 Then i have by clicking on cacert.der and following tutorial installed CA certificate into Windows Vista. In second step by clicking on clcert.p12 i have installed client certificate. But so far, it is not working and i am allways getting message about not trusted certificate. Can someone help me please, or point me to solution? Thanks in advance! Regards, David
Re: RFC 4130 checksum in SHA1
Hi: After I decrypt and then verify, the original content is the set of 2 blue lines below and without lt;crgt;lt;lfgt; at the end of the second blue line. Content-Type: multipart/signed; micalg=sha1; protocol=application/pkcs7-signature; boundary==_Part_49479_882783390.1213441157558 --=_Part_49479_882783390.1213441157558 Content-Type: application/xml lt;?xml version=1.0 encoding=utf-8 ?gt; lt;PurchaseOrdergt;lt;Sendergt;ZZ-sendername... DISEÃOS [this is the weir word not really in UTF-8]...lt;/InvoiceTogt;lt;/POgt;lt;/PurchaseOrdergt; --=_Part_49479_882783390.1213441157558 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIIETQYJKoZIhvcNAQcCoIIEPjCCBDoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCAoMwggJ/MIIB6KADAgECAgRGjSnmMA0GCSqGSIb3DQEBBAUAMIGDMQsw ... ... CQYDVQQGEwJNWDEOMAwGA1UEERMFNjYyNjAxCzAJBgNVBAgTAk5MMRIwEAYDVQQH EwlNb250ZXJyZXkxGjAYBgNVBAoTEUhvbWUgRGVwb3QgTWV4aWNvMQwwCgYDVQQL WQ== --=_Part_49479_882783390.1213441157558-- Thanks jkoehring wrote: I have to admit, I am not very familiar with the openssl commands. The one question I have is exactly what are the contents of original.txt after running the commands you list? Does it contain exactly the contents of the first part of the multipart/signed? javierm wrote: Thanks for the wait: Well, these are the steps followed Encrypted body with Mime headers.- body decrypted and multipart/signed message obtained Signature in binary, so processed with openssl pkcs7 to convert the binary signature to b64 (script in perl to extract the binary signature, process it with pkcs7 it and put it back in between the 2nd an 3rd boundary, Content-transfer-encoding changed from : binary to base64--- file produced: signed.txt openssl smime -verify -in signed.txt -nosigs -noverify -signer who.pem -out original.txt (successful, cert found inside used in signature written to who.pem-yes the signer is right) openssl sha1 -binary original.txt|openssl enc -a , and... I don't get the signature that the signer claims I should get!! :confused: What do you think? Thanks javierm wrote: Hi jkoehring: Thanks a lot for the help, (ah just noticed another reply from you on this question placed in another way, thanks). I tried that part too but did not get the expected checksum. Not that I doubt what you say, but perhaps I'm mistaken at some point. When I do the verify, the openssl smime -verify outputs the original document and optionally the certificate. I was doing the checksum not after the verification, but instead, I was just processing the multipart/signed document, and extracting the first portion between the first and second boundary. I will do it again right now and be right back. On the other hand, don't you think the 7.1.8 paragraph of RFC4130 misleads one, by saying MIC MUST be calculated across the entire multi-part content, including the MIME headers. It seems to me a trick to give clients to somebody. Thanks Later, Javier jkoehring wrote: If I understand your question correctly, you are asking how to calculate the MIC (SHA1 checksum) to put in an AS2 MDN. The MIC should be calculated over exactly that data that was signed in the original AS2 message. The data used to calculate the MIC should not include the actual signature. Thus, the MIC should be calculated over that data that appears between the first two boundary markers in the multipart/signed of the original AS2 message. Note that the first boundary marker includes the trailing CRLF and the second boundary marker includes the leading CRLF. Thus, those CRLF sequences should not be included in the MIC calculation. javierm wrote: Can anyone help me with the procedure to calculate the message integrity check in this RFC? it's about calculating the sha1 checksum over a multipart message. This is the text in the RFC (http://www.ietf.org/rfc/rfc4130.txt), chapter 7.1, paragraph 8) The EC Interchange and the RFC 1767 MIME EDI content header can actually be part of a multi-part MIME content-type. When the EDI Interchange is part of a multi-part MIME content-type, the MIC MUST be calculated across the entire multi-part content, including the MIME headers. My problem is that i think I understood, but another software gives me a different checksum for the same message. I canonicalize headers, no problem I process signature of message with openssl which provides a multipart file I calculate sha1 over exactly that output file Is there something done wrong in this procedure? Whant to try some examples? This file is a multipart output from openssl http://www.nabble.com/file/p18034577/mictest.txt mictest.txt Ok, not directly. Because openssl produces the base64 signature, which I detach to then transform to
Re: using NNTPS (nnrp with ssl) with windows mail / thunderbird on windows vista
Your logic is correct, in Thunderbird, you have the preferences|advanced and this shows you a set of tabs, the last one of which is Certificates. Press View Certificates Button and you get another dialog with 4 tabs 1.- the first tab (your certificates) is for the pk12 ones 2.- other people's certs, for the pem of other people 3.- websites certs 4.- and authorities to put your CA cert. Just make sure your certificate is actually one son of your CA. It is right To make one CA cert with the 509 extensions set to CA X509v3 Basic Constraints: CA:TRUE X509v3 Key Usage: Certificate Sign, CRL Sign Netscape Cert Type: SSL CA, S/MIME CA But it is a mistake to make the son as ANOTHER SELF SIGNED cert with those extensions not set as CA X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Client, SSL Server, S/MIME, Object Signing X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment Netscape Comment: I know of important companies doing this mistake. The second cert has to be one SIGNED by the first CA authority, not a selfsigned one with CA fields off of false. Said in other words: the second cert is the result or output of a CSR (certificate signing request) signed by the CA cert. Thunderbird accepts PEM format, so you don't need the DER transformation. The above outputs are part of openssl x509 -in anycert.pem -text David Hlacik wrote: Hello, i have working nnrpd with SSL configuration. I am using my custom generated SSL certificate signed with my own Certification Authority. Each time i am accessing news in Windows Mail client i am getting message , that certificate is not trusted and cannot be verified. I want to get rid off this message by importing my custom CA (or probably custom certificate) into windows certification storage and make it trusted so i will not get this message again. So far, i have converted my cacert.pem to der format using : openssl x509 -inform PEM -outform DER -in cacert.pem -out cacert.der Then, i have converted my nnrpd certificate to pk12 format using: openssl pkcs12 -export -clcerts -in nnrpd.cert.pem -inkey nnrpd.key.pem -out clcert.p12 Then i have by clicking on cacert.der and following tutorial installed CA certificate into Windows Vista. In second step by clicking on clcert.p12 i have installed client certificate. But so far, it is not working and i am allways getting message about not trusted certificate. Can someone help me please, or point me to solution? Thanks in advance! Regards, David -- View this message in context: http://www.nabble.com/using-NNTPS-%28nnrp-with-ssl%29-with-windows-mail---thunderbird-on-windows-vista-tp18069198p18069930.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 [EMAIL PROTECTED]
DH Generator 2
Does anyone have a technical reference on the use of special generator value 2 in DH keys? Steven Pauly Pitney Bowes GMS This email message may contain confidential, proprietary and/or privileged information. It is intended only for the use of the intended recipient(s). If you have received it in error, please immediately advise the sender by reply email and then delete this email message. Any disclosure, copying, distribution or use of the information contained in this email message to or by anyone other than the intended recipient is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to the views of the Company. Thank you.
Re: RFC 4130 checksum in SHA1
The mechanism for calculating the MIC for an AS2 message is exactly the same as that for an AS1 message. The two protocols are practically identical except that the outermost contents of AS1 messages are frequently encoded (base64 , quoted-printable, etc) so that they may be transported safely over SMTP. Otherwise, AS21 and AS2 messages are packaged identically. The paragraph you are referring to in section 7.1 of RFC 4130 is referring to the situation in which the data being transported in an AS2 message is a multipart. That is, the first part of the multipart/signed is, itself, another multipart. It is not saying that the MIC should be calculated over the entire multipart/signed, just the first part of the multipart/signed. Another way to look at it is when the original AS2 message is signed, the MIC for the MDN should be exactly the same as the hash used in the calculation of the signature for the multipart/signed. javierm wrote: Just a note, I've found documents like http://ietfreport.isoc.org/all-ids/draft-ietf-ediint-compression-08.txt which in secction 2.1 says to calculate MIC on the original data that was signed as PER [AS1] (but 4130 is AS2) In section 7.3.1.3 of 4130, first paragraph in bullets it is said: For any signed messages, the MIC to be returned is calculated on the RFC1767/RFC3023 MIME header and content. Canonicalization on the MIME headers MUST be performed before the MIC is calculated, since the sender requesting the signed receipt was also REQUIRED to canonicalize. and in 7.1.8 of 4130 The EC Interchange and the RFC 1767 MIME EDI content header can actually be part of a multi-part MIME content-type. When the EDI Interchange is part of a multi-part MIME content-type, the MIC MUST be calculated across the entire multi-part content, including the MIME headers. In any case I tried *the original data *the 1767 (edi block with header and content) *the whole multipart/signed document (this multipart/signed header + the edi block and the signature block with boundaries, etc) which else should I try? Thanks -- View this message in context: http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p18062776.html Sent from the OpenSSL - User mailing list archive at Nabble.com.
Re: RFC 4130 checksum in SHA1
I have to admit, I am not very familiar with the openssl commands. The one question I have is exactly what are the contents of original.txt after running the commands you list? Does it contain exactly the contents of the first part of the multipart/signed? javierm wrote: Thanks for the wait: Well, these are the steps followed Encrypted body with Mime headers.- body decrypted and multipart/signed message obtained Signature in binary, so processed with openssl pkcs7 to convert the binary signature to b64 (script in perl to extract the binary signature, process it with pkcs7 it and put it back in between the 2nd an 3rd boundary, Content-transfer-encoding changed from : binary to base64--- file produced: signed.txt openssl smime -verify -in signed.txt -nosigs -noverify -signer who.pem -out original.txt (successful, cert found inside used in signature written to who.pem-yes the signer is right) openssl sha1 -binary original.txt|openssl enc -a , and... I don't get the signature that the signer claims I should get!! :confused: What do you think? Thanks javierm wrote: Hi jkoehring: Thanks a lot for the help, (ah just noticed another reply from you on this question placed in another way, thanks). I tried that part too but did not get the expected checksum. Not that I doubt what you say, but perhaps I'm mistaken at some point. When I do the verify, the openssl smime -verify outputs the original document and optionally the certificate. I was doing the checksum not after the verification, but instead, I was just processing the multipart/signed document, and extracting the first portion between the first and second boundary. I will do it again right now and be right back. On the other hand, don't you think the 7.1.8 paragraph of RFC4130 misleads one, by saying MIC MUST be calculated across the entire multi-part content, including the MIME headers. It seems to me a trick to give clients to somebody. Thanks Later, Javier jkoehring wrote: If I understand your question correctly, you are asking how to calculate the MIC (SHA1 checksum) to put in an AS2 MDN. The MIC should be calculated over exactly that data that was signed in the original AS2 message. The data used to calculate the MIC should not include the actual signature. Thus, the MIC should be calculated over that data that appears between the first two boundary markers in the multipart/signed of the original AS2 message. Note that the first boundary marker includes the trailing CRLF and the second boundary marker includes the leading CRLF. Thus, those CRLF sequences should not be included in the MIC calculation. javierm wrote: Can anyone help me with the procedure to calculate the message integrity check in this RFC? it's about calculating the sha1 checksum over a multipart message. This is the text in the RFC (http://www.ietf.org/rfc/rfc4130.txt), chapter 7.1, paragraph 8) The EC Interchange and the RFC 1767 MIME EDI content header can actually be part of a multi-part MIME content-type. When the EDI Interchange is part of a multi-part MIME content-type, the MIC MUST be calculated across the entire multi-part content, including the MIME headers. My problem is that i think I understood, but another software gives me a different checksum for the same message. I canonicalize headers, no problem I process signature of message with openssl which provides a multipart file I calculate sha1 over exactly that output file Is there something done wrong in this procedure? Whant to try some examples? This file is a multipart output from openssl http://www.nabble.com/file/p18034577/mictest.txt mictest.txt Ok, not directly. Because openssl produces the base64 signature, which I detach to then transform to binary or DER and I attach it back, with the corresponding change in Content-enconding: binary. For this file I get IpWFspJ2hKwfja5CkOPnDW2ctT8= The other trading partner says: Uiaz1kOChhlSb/f3SJsmJ/O/8SI= Could this be a mere misunderstanding of the RFC?, I've seen way different interpretations on the net, which I have tried but don't work either. Well thanks for the help -- View this message in context: http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p18062910.html Sent from the OpenSSL - User mailing list archive at Nabble.com.
Handshake before BIO pairs using
Hi, all!
How can i do handshake before using BIO pairs for encrypt/decrypt, if as
transport i use Winsock(WSASend and WSARecv)?
some example
this is send function:
DWORD CSSLTLSLayer::Send(IN OVERLAPPED *pOverlapped,
IN WSABUF *pBuffer,
OUT PDWORD pdwWasSend)
{
size_t iBuffered = BIO_write(m_pSSLBIO, pBuffer-buf, pBuffer-len);
BIO_flush(m_pSSLBIO);
iBuffered = (int)BIO_ctrl_pending(m_pNetworkBIO);
if (iBuffered = 0){
return(WSA_IO_PENDING);
}
m_vcLayeredBuffer.clear();
m_vcLayeredBuffer.resize(iBuffered);
iBuffered = BIO_read(m_pNetworkBIO,
m_vcLayeredBuffer.front(),
(int)iBuffered);
pBuffer-buf = m_vcLayeredBuffer.front();
pBuffer-len = (u_long)m_vcLayeredBuffer.size();
//Method of parent class which only send message as WSASend()
DWORD dwStatus = __super::Send(pOverlapped, pBuffer, pdwWasSend);
return(dwStatus);
}
DWORD CSSLTLSLayer::Send(IN OVERLAPPED *pOverlapped,
IN WSABUF *pBuffer,
OUT PDWORD pdwWasSend)
{
size_t iBuffered = BIO_write(m_pSSLBIO, pBuffer-buf, pBuffer-len);
BIO_flush(m_pSSLBIO);
iBuffered = (int)BIO_ctrl_pending(m_pNetworkBIO);
if (iBuffered = 0){
return(WSA_IO_PENDING);
}
m_vcLayeredBuffer.clear();
m_vcLayeredBuffer.resize(iBuffered);
iBuffered = BIO_read(m_pNetworkBIO,
m_vcLayeredBuffer.front(),
(int)iBuffered);
pBuffer-buf = m_vcLayeredBuffer.front();
pBuffer-len = (u_long)m_vcLayeredBuffer.size();
//Method of parent class which only send message as WSASend()
DWORD dwStatus = __super::Send(pOverlapped, pBuffer, pdwWasSend);
return(dwStatus);
}
this is receive function (common problem, because DWORD Send() work
correctly):
DWORD CSSLTLSLayer::Receive(IN OVERLAPPED *pOverlapped,
IN WSABUF *pBuffer,
OUT PDWORD pdwWasRecv)
{
if (!m_bKEXed){
this-Handshake();
this-InitBIOAbstractions();
return 0;
}
//Receive method in parent class only do WSARecv()
DWORD dwRet = __super::Receive(pOverlapped, pBuffer, pdwWasRecv);
BIO_write(m_pNetworkBIO, pBuffer-buf, *pdwWasRecv);
BIO_flush(m_pNetworkBIO);
size_t iBuffered = BIO_ctrl_pending(m_pSSLBIO);
if (iBuffered = 0){
return(WSA_IO_PENDING);
}
m_vcLayeredBuffer.clear();
m_vcLayeredBuffer.resize(iBuffered);
iBuffered = BIO_read(m_pSSLBIO, m_vcLayeredBuffer.front(),
(int)iBuffered);
pBuffer-buf = m_vcLayeredBuffer.front();
pBuffer-len = (u_long)m_vcLayeredBuffer.size();
return(dwRet);
}
DWORD CSSLTLSLayer::Receive(IN OVERLAPPED *pOverlapped,
IN WSABUF *pBuffer,
OUT PDWORD pdwWasRecv)
{
if (!m_bKEXed){
this-Handshake();
this-InitBIOAbstractions();
return 0;
}
//Receive method in parent class only do WSARecv()
DWORD dwRet = __super::Receive(pOverlapped, pBuffer, pdwWasRecv);
BIO_write(m_pNetworkBIO, pBuffer-buf, *pdwWasRecv);
BIO_flush(m_pNetworkBIO);
size_t iBuffered = BIO_ctrl_pending(m_pSSLBIO);
if (iBuffered = 0){
return(WSA_IO_PENDING);
}
m_vcLayeredBuffer.clear();
m_vcLayeredBuffer.resize(iBuffered);
iBuffered = BIO_read(m_pSSLBIO, m_vcLayeredBuffer.front(),
(int)iBuffered);
pBuffer-buf = m_vcLayeredBuffer.front();
pBuffer-len = (u_long)m_vcLayeredBuffer.size();
return(dwRet);
}
and Handshake() method:
void CSSLTLSLayer::Handshake(void){
if (!m_bKEXed m_pSSL){
SSL_set_fd(m_pSSL, (int)m_Socket);
SSL_set_accept_state(m_pSSL);
SSL_do_handshake(m_pSSL);
m_bKEXed = true;
}
return;
}
void CSSLTLSLayer::Handshake(void){
if (!m_bKEXed m_pSSL){
SSL_set_fd(m_pSSL, (int)m_Socket);
SSL_set_accept_state(m_pSSL);
SSL_do_handshake(m_pSSL);
m_bKEXed = true;
}
return;
}
after Handshake() calling in Receive() i always request 0 bytes and empty
buffer... why?
maybe i can do handshake without using SSL_set_fd(), SSL_set_accept_state()
and SSL_do_handshake()?
Thanks for support!
Problems with KEY validation on different platforms
Hello everybody, I have a problem that I consider unusual and hope you can help me with it. I must execute some EDI files transmissions with a customer and these files must go encrypted. So, Ive generated a CSR file (with the .KEY using a password and all the other stuff) in my machine (Win Vista Ultimate) with the OpenSSL (0.9.8g 19 Oct 2007) windows version. However, the app that I use for the transmissions (IP*Works AS2 EDI Connector free version) requires a PFX file to sign the sending files. No problem with that. Ive generated the PFX using the OpenSSL (openssl pkcs12 -inkey File.key -in File.crt -export -out File.pfx) and submitted to my app. That password was validated and the test transmissions made in our intranet was ok (Vista to Vista machines). Now the mystery comes up. When I try to use the same .PFX file in the installed app on a Win XP or Win 2K machine, the password is simply refused, not validated. Do you think that for some reason the CSR file stores some information about the machine that have generated the file? Best regards, cid:image002.jpg@01C87AB9.0A707620 José Leonardo Ayres Pereira Systems Analyst Aduana Despachos e Assessoria de Comércio Exterior Ltda. R. Franco de Sá, 270 - 10o. floor S. Francisco - Manaus - AM - Brazil Ph: + 55 92 3612-0100 http://www.aduana-dsp.com.br/ http://www.aduana-dsp.com.br image001.jpg
Generating certificates from IIS certificate requests
I have an IIS (.NET 2.0) server from which I generated a certificate request using the standard wizard. I am now trying to use OpenSSL to generate a certificate from that certificate request. I tried just generating another certificate but IIS caught the mismatch and will not install the certificate itself. So, How do I respond to the IIS-generated certificate request with OpenSSL? Eric Chamberlain VentriPoint, Inc. | www.ventripoint.com | Software Engineer Helping heart care through innovative diagnostic solutions attachment: winmail.dat
