Exchange 2003 and SSL23_GET_SERVER_HELLO
Hello all, Trying to connect to an Exchange 2003 SP2 Virtual SMTP Server with s_client but get the following (OpenSSL 0.9.8g): openssl s_client -connect mail.somehost.com:587 -state CONNECTED(0003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:error in SSLv2/v3 read server hello A 1520:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:583: openssl s_client -connect mail.somehost.com:587 -state -ssl2 CONNECTED(0003) SSL_connect:before/connect initialization SSL_connect:SSLv2 write client hello A (cursor waiting) openssl s_client -connect mail.somehost.com:587 -state -ssl3 CONNECTED(0003) SSL_connect:before/connect initialization SSL_connect:SSLv3 write client hello A SSL3 alert write:fatal:handshake failure SSL_connect:error in SSLv3 read server hello A 1694:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:284: openssl s_client -connect mail.somehost.com:587 -state -starttls smtp CONNECTED(0003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A ***certificate *** ... SSL handshake has read 1022 bytes and written 335 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: RC4-MD5 Session-ID: x ... Session-ID-ctx: Master-Key: x ... Key-Arg : None Start Time: 1247280228 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) The certificate on the Exchange Server was self-signed and was created through the IIS SelfCert tool. I thought perhaps the certificate wasn't trusted but it seems to be failing at the handshake phase; I double-checked by trying out Google's mail server (smtp.gmail.com) which supports SSL/TLS and while the certificate says it's untrusted, I still get a 250 OK, so I'm not thinking it's the certificate. Tried it on another box running 0.9.8a, same results. I'm definitely not ruling out a poorly-configured Exchange box -- I've gone through dozens of technet and web articles and everything *should* be working, but clearly it's not. Any ideas? I've been banging away at this for the last couple days and am at wit's end... any help greatly appreciated. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate with custom fields
Akos Vandra wrote: > Thank you, this was much more helpful. > > 2009/7/10 Victor Duchovni : >> On Fri, Jul 10, 2009 at 11:11:48PM +0200, Akos Vandra wrote: >> The parties involved here are not connected to the internet, and thus don't have any access to a (this is an embedded project), and they must confirm eachother's identity based on the CA-signed certificates. >> Well, my address is not my identity. > > Surely not. But your picture, name, and other infos define who you are. > Actually, those are just attributes - I am me, but the fact that I am white, of Scottish descent, and 6'1" are simply attributes. As is the fact that I work for Carillon Information Security - these are not my Identity, these are attributes tied to my identity - I suggest you read Kim Cameron's Laws of Identity to help you get a better grasp of the differences between the two. > "Identities" are just primary >> keys. It seems that you don't want identity certificates, but >> for some reason need attribute certificates with lots of attributes. >> >> Is the subject the holder of a corresponding private key in this context, > > yes > >> or this just a signed message binding the subject to a set of attributes? > > exactly, these are not exclusive. > They are exclusive - your identity ties you to one or more sets of attributes, which are completely different dependent on the context. I can have a much different set of attributes if I am identifying myself to my company, or to a partner company, to my local curling club, or to my bank. Again, see the "laws of Identity" referenced above. >> If the subject participates in a protocol in which the certificate >> authenticates its private key, generally a unique identifier for >> each subject is sufficient to support per-subject ACLs, ... >> >> If this is something akin to a signed "passport", the object in question >> is a signed message, not a certificate. > > you can't really draw a clear line between "signed message" and > "certificate", because a certificate isn't anything else but a signed > message from the CA saying that this public key's pair belongs to that > entity. > > >> Subject attributes are encoded in the subject DN. You can specify >> custom OIDs, if the standard OIDs are not sufficient. > > Thank you, I think this is what I need. An image can be base64 encoded > and passed as a field, but I'm not sure if there is any length limit, > I will have to make some research on this. Thanks for the link. I would encourage you to re-think your design if you are going to put all of those attributes into a certificate It appears that what you REALLY want is some form of Identity Federation... and not simply PKI. At the very least, you might want to consider X.509 Identity Certificates as well as Attribute Certificates... Have fun. Patrick __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate with custom fields
On Fri, Jul 10, 2009 at 11:50:33PM +0200, Akos Vandra wrote: > > If the subject participates in a protocol in which the certificate > > authenticates its private key, generally a unique identifier for > > each subject is sufficient to support per-subject ACLs, ... > > > > If this is something akin to a signed "passport", the object in question > > is a signed message, not a certificate. > > you can't really draw a clear line between "signed message" and > "certificate", because a certificate isn't anything else but a signed > message from the CA saying that this public key's pair belongs to that > entity. Well, X.509 certificates, are signed messages that bind a public key to an "identity". Generally when one says "certificate" it is short for an X.509 public key certificate, which is used to authenticate a subject that can securely demonstrate possession of the corresponding private key. > > Subject attributes are encoded in the subject DN. You can specify > > custom OIDs, if the standard OIDs are not sufficient. > > Thank you, I think this is what I need. An image can be base64 encoded > and passed as a field, but I'm not sure if there is any length limit, > I will have to make some research on this. Thanks for the link. Length limits are protocol dependent, you have not specified the protocol with which your "certificates" will be used. [ FWIW, neither my image, nor any other set of discrete attributes, are an "identity". My identity is the totality of things that comprise me, and an "identifier" is a reference to that identity. "Identity theft" is a misnomer... X.509 certs bind a public key to subject identifier, presumably one that is meaningful to the verifier. ] -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate with custom fields
Thank you, this was much more helpful. 2009/7/10 Victor Duchovni : > On Fri, Jul 10, 2009 at 11:11:48PM +0200, Akos Vandra wrote: > >> > The parties involved here are not connected to the internet, and thus >> > don't have any access to a (this is an embedded project), and they >> > must confirm eachother's identity based on the CA-signed certificates. > > Well, my address is not my identity. Surely not. But your picture, name, and other infos define who you are. "Identities" are just primary > keys. It seems that you don't want identity certificates, but > for some reason need attribute certificates with lots of attributes. > > Is the subject the holder of a corresponding private key in this context, yes > or this just a signed message binding the subject to a set of attributes? exactly, these are not exclusive. > > If the subject participates in a protocol in which the certificate > authenticates its private key, generally a unique identifier for > each subject is sufficient to support per-subject ACLs, ... > > If this is something akin to a signed "passport", the object in question > is a signed message, not a certificate. you can't really draw a clear line between "signed message" and "certificate", because a certificate isn't anything else but a signed message from the CA saying that this public key's pair belongs to that entity. > > Subject attributes are encoded in the subject DN. You can specify > custom OIDs, if the standard OIDs are not sufficient. Thank you, I think this is what I need. An image can be base64 encoded and passed as a field, but I'm not sure if there is any length limit, I will have to make some research on this. Thanks for the link. > > http://openssl.org/docs/apps/req.html#DISTINGUISHED_NAME_AND_ATTRIBUTE > > -- > Viktor. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@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: Certificate with custom fields
On Fri, Jul 10, 2009 at 11:11:48PM +0200, Akos Vandra wrote: > > The parties involved here are not connected to the internet, and thus > > don't have any access to a (this is an embedded project), and they > > must confirm eachother's identity based on the CA-signed certificates. Well, my address is not my identity. "Identities" are just primary keys. It seems that you don't want identity certificates, but for some reason need attribute certificates with lots of attributes. Is the subject the holder of a corresponding private key in this context, or this just a signed message binding the subject to a set of attributes? If the subject participates in a protocol in which the certificate authenticates its private key, generally a unique identifier for each subject is sufficient to support per-subject ACLs, ... If this is something akin to a signed "passport", the object in question is a signed message, not a certificate. Subject attributes are encoded in the subject DN. You can specify custom OIDs, if the standard OIDs are not sufficient. http://openssl.org/docs/apps/req.html#DISTINGUISHED_NAME_AND_ATTRIBUTE -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate with custom fields
Victor Duchovni wrote: On Fri, Jul 10, 2009 at 10:04:45PM +0200, Akos Vandra wrote: Hello! I need to issue a few certificates with custom fields, with the customers more thoroughly identified, including Full name, Address, Telephone number, blablabla, and even a picture of the poor guy. A certificate is not a database. Put a unique id in the certificate, and use a real database to retrieve the related data. X.509 allows to have all such identity attributes in the subject DN. (except a picture as far as I know). Can this be done with one of the standards which uses openssl, or would I have to make one of my own? For example, why don't any XML.-like certificates exist? Your design is flawed. I am not sure about that. xml certs exist somehow: just reencode with XER encoding rules __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate with custom fields
to a central database, that is 2009/7/10 Akos Vandra : > Before just criticizing anything without any arguments whatsoever, > just stating that something is wrong, please think for a while. > Critiques are very important too, but if you do decide to criticize > something, make it useful. > > The parties involved here are not connected to the internet, and thus > don't have any access to a (this is an embedded project), and they > must confirm eachother's identity based on the CA-signed certificates. > > If anyone has any idea how to include this information in a > certificate, please tell me how this can be done. > > And please don't make this thread a flame. > > Best regards, > Vandra Ákos > > > > > 2009/7/10 Victor Duchovni : >> On Fri, Jul 10, 2009 at 10:04:45PM +0200, Akos Vandra wrote: >> >>> Hello! >>> >>> I need to issue a few certificates with custom fields, with the >>> customers more thoroughly identified, including Full name, Address, >>> Telephone number, blablabla, and even a picture of the poor guy. >> >> A certificate is not a database. Put a unique id in the certificate, >> and use a real database to retrieve the related data. >> >>> Can this be done with one of the standards which uses openssl, or >>> would I have to make one of my own? For example, why don't any >>> XML.-like certificates exist? >> >> Your design is flawed. >> >> -- >> Viktor. >> __ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-us...@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: Certificate with custom fields
Before just criticizing anything without any arguments whatsoever, just stating that something is wrong, please think for a while. Critiques are very important too, but if you do decide to criticize something, make it useful. The parties involved here are not connected to the internet, and thus don't have any access to a (this is an embedded project), and they must confirm eachother's identity based on the CA-signed certificates. If anyone has any idea how to include this information in a certificate, please tell me how this can be done. And please don't make this thread a flame. Best regards, Vandra Ákos 2009/7/10 Victor Duchovni : > On Fri, Jul 10, 2009 at 10:04:45PM +0200, Akos Vandra wrote: > >> Hello! >> >> I need to issue a few certificates with custom fields, with the >> customers more thoroughly identified, including Full name, Address, >> Telephone number, blablabla, and even a picture of the poor guy. > > A certificate is not a database. Put a unique id in the certificate, > and use a real database to retrieve the related data. > >> Can this be done with one of the standards which uses openssl, or >> would I have to make one of my own? For example, why don't any >> XML.-like certificates exist? > > Your design is flawed. > > -- > Viktor. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@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: " unable to get local issuer certificate" & certificate not trusted errors
Thank you, the certificate was verified as valid. As far as the CAPATH command, is it literally called "CAPATH"? because I couldn't find any reference to it in the openssl documentation. Carlo -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Duncan Berriman Sent: Thursday, July 09, 2009 3:18 PM To: openssl-users@openssl.org Subject: Re: " unable to get local issuer certificate" & certificate not trusted errors Its likely that the certificate is not installed correctly and that the person who installed it did not install the intermediate CA which comes with it. This isn't always obvious and doesn't usually cause a problem unless it is the first site the visitor has visited that uses that intermediate CA. Most suppliers have a utility (online) to check that certificates are installed correctly so I'd advise you go to equifax's site and run their test against the site/server concerned. If thats ok then it may be you need to specify CAPATH on the openssl command to the appropriate directory. Duncan On 9 Jul 2009, at 21:20, Agopian, Carlo wrote: > Hello, > > I'm getting the same error 20 as below for a different site. I did > find > out that the certificate issuer is Equifax Secure Certificate > Authority. > Obviously this is not one of the popular CA's such as > thawte,verisign,etc. Is this my problem? If so how do I tell > openssl to > recognize this CA? Following is my entire error for your reference. > Thanks in advance for your help. > >> openssl s_client -quiet -connect 12.175.11.57:443 > depth=0 > /C=US/ST=Wisconsin/L=Madison/O=Integrasys/OU=Madison/ > CN=model.goxroads.c > om > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 > /C=US/ST=Wisconsin/L=Madison/O=Integrasys/OU=Madison/ > CN=model.goxroads.c > om > verify error:num=27:certificate not trusted > verify return:1 > depth=0 > /C=US/ST=Wisconsin/L=Madison/O=Integrasys/OU=Madison/ > CN=model.goxroads.c > om > verify error:num=21:unable to verify the first certificate > verify return:1 > > Carlo > > -Original Message- > From: owner-openssl-us...@openssl.org > [mailto:owner-openssl-us...@openssl.org] On Behalf Of Saju Paul > Sent: Friday, February 01, 2008 10:39 AM > To: openssl-users@openssl.org > Subject: RE: " unable to get local issuer certificate" & > certificate not > trusted errors > Importance: High > > who is the signer of certificate newcert.pem ? is it a self-signed > certificate ? it should not be. newcert.pem should be signed by a > trusted > CA (thawte,verisign,godaddy etc.) or by a CA that is in google/gmail's > CA > repository. > -Original Message- > From: owner-openssl-us...@openssl.org > [mailto:owner-openssl-us...@openssl.org]on Behalf Of gopinath ethiraja > Sent: Friday, February 01, 2008 5:11 AM > To: openssl-users@openssl.org; openssl-...@openssl.org > Subject: " unable to get local issuer certificate" & certificate not > trusted errors > > > I tried to connect to a server using s_client command .but i get an > error stating > >" unable to get local issuer certificate" & also > it gives certificate not trusted " > > how to overcome this errors > > C:\OpenSSL\bin>openssl s_client -connect gmail.com:443 -verify 3 -cert > newcert.p > em -key newkey.pem -CAfile cacert.pem -state > verify depth is 3 > Enter pass phrase for newkey.pem: > Loading 'screen' into random state - done > CONNECTED(02D4) > SSL_connect:before/connect initialization > SSL_connect:SSLv2/v3 write client hello A > SSL_connect:SSLv3 read server hello A > depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA > verify error:num=27:certificate not trusted > verify return:1 > depth=0 /C=US/ST=California/L=Mountain View/O=Google > Inc/CN=mail.google.com > verify return:1 > SSL_connect:SSLv3 read server certificate A > SSL_connect:SSLv3 read server done A > SSL_connect:SSLv3 write client key exchange A > SSL_connect:SSLv3 write change cipher spec A > SSL_connect:SSLv3 write finished A > SSL_connect:SSLv3 flush data > SSL_connect:SSLv3 read finished A > --- > Certificate chain > 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/ > CN=mail.google.com >i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA > 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA >i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification > Authority > --- > Server certificate > -BEGIN CERTIFICATE- > MIIDIjCCAougAwIBAgIQeGJdG+ZuLrAZgPwP49qYUTANBgkqhkiG9w0BAQUFADBM > MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg > THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wNzA1MDMxNTM0NThaFw0w > ODA1MTUxNzI0MDFaMGkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh > MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMR
Re: Certificate with custom fields
On Fri, Jul 10, 2009 at 10:04:45PM +0200, Akos Vandra wrote: > Hello! > > I need to issue a few certificates with custom fields, with the > customers more thoroughly identified, including Full name, Address, > Telephone number, blablabla, and even a picture of the poor guy. A certificate is not a database. Put a unique id in the certificate, and use a real database to retrieve the related data. > Can this be done with one of the standards which uses openssl, or > would I have to make one of my own? For example, why don't any > XML.-like certificates exist? Your design is flawed. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Certificate with custom fields
Hello! I need to issue a few certificates with custom fields, with the customers more thoroughly identified, including Full name, Address, Telephone number, blablabla, and even a picture of the poor guy. Can this be done with one of the standards which uses openssl, or would I have to make one of my own? For example, why don't any XML.-like certificates exist? Regards, Vandra Ákos __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: trying to replicate ECC signing with openssl
Mike Frysinger writes: [...] > ive been trying to figure out exactly how to invoke openssl to get the > equivalent behavior. It's beyond me, I'm afraid. But a couple of things do suggest themselves... [...] > i'm creating the parameters file with: > openssl ecparam -name sect163k1 -rand -param_enc explicit -text I think that's the wrong thing to be trying to do. I think you've been given the private key, so you just need to somehow combine the bits you've been given into the form that OpenSSL wants. Probably (and this is the bit that's beyond me) you need to produce a group and a public key (both of which are public parts of the key), and presumably these are the first numbers you gave. Then, you need to use the private key and the random number to form the ECDSA signature of the file. ECDSA with SHA1 requires 160 bits of random data, which is exactly what you've been given so that matches up. (I don't see a way to provide the random number to any of the OpenSSL functions, so perhaps some hacking will be needed for that part.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
trying to replicate ECC signing with openssl
i was given a small "ecsign.exe" program that takes some ECC parameters, the private key, a random number, and outputs a signature of the specified binary. i'm trying to ditch this program in favor of the openssl suite (for obvious practical reasons). for example, the parameters file looks like (where # are comments): 163 # m: dimension of binary field 1 # a constant 1 # b constant 400020108A2E0CC0D99F8A5EF # Xg 2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8 # Yg 289070FB05D38FF58321F2E800536D538CCDAA3D9 # n 7 # k3 constant 6 # k2 constant 3 # k1 constant the private key looks like (no, not a security issue, this is a demo key): 1133A74FDA4FA538C92CE543521336B038D18EB5B the random number (again, demo value): 3A852AFB339E7AE3220CED10F478E0A018AAD27EF and for its output signature on a random file, we get: 3C47B123C88549E6E375B2393AFBF604AEB9E9CE3 3069158A3B7AAA828086DAEC4875D949070885D24 it also produces this, but i believe it is a reformatting of the above: E39C9EEB4A60BFAF93235B376E9E54883C127BC40300245D887090945D87C4AE6D0828A8AAB7A35891060300 ive been trying to figure out exactly how to invoke openssl to get the equivalent behavior. using "-name sect163k1", it seems i do not need to set a/b/n manually as the ones used are the default. but i cant figure out where to plugin Xg/Yg/k3/k2/k1. i'm creating the parameters file with: openssl ecparam -name sect163k1 -rand -param_enc explicit -text but this is about where i'm stuck. i guess the output of ecparam is the .pem file that i'd combine with the private key above to feed to `openssl ec` to sign the binary in question. but i'm not sure how to convert the private key to the pem format ... when i use -genkey, the resulting base64 encoded key looks to be much longer than the private key i have above ? -mike signature.asc Description: This is a digitally signed message part.
Re: Certificate Verification: Error (7): certificate signature failure
To close out this issue in the hopes that this will be of use to someone in the future, Dr. Henson greatly helped in tracking the problem down to a PHP extension that was calling EVP_cleanup(). "When you have a shared library using OpenSSL and multiple applications things like algorithm tables etc are common to all of them. So if one application messes up the tables then it will affect all applications subsequently. There has been a comment about it in PR#1743" "You'll only notice issues with Apache if you do something that looks up message digests from the algorithm table, such as verifying certificate signatures, which will only happen if you enable client authentication and not many people do." Removing the PHP code that triggered EVP_cleanup() resolved our issue. Thank you Steve! Jon __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
questions regarding certificate chains
Hello everyone! I have a couple of questions regarding certificate chains that I hope can be answered. The certificate chain goes something like this: root CA -> subordinate CA -> endpoint. 1) Must each endpoint have access to the root CA certificate in order to establish client TLS connections? I would think yes. How else can the client validate the certificate chain presented to it by the server (ie. sub CA cert and signed endpoint cert)? Must all cert chains end in a self-signed root cert? 2) If the subordinate CA is configured to sign certificates and CRLs, shouldn't the X509v3 Key Usage field of the sub CA cert contain certificate sign and CRL sign? Currently the sub CA I am using only has digital signature set, but it has signed a certificate signing request from my endpoint and I was able to obtain a signed CRL as well (Issuer of CRL is subject of sub CA cert). 3) When openssl verifies a certificate against a CRL (X509_V_FLAG_CRL_CHECK and X509_V_FLAG_CRL_CHECK_ALL flags set in X509_STORE), will it try to find the CA who signed this CRL in the store and verify the key usage for that cert is set to CRL sign? I am currently getting an "unable to get CRL issuer certificate" error and I am trying to determine if it is because I do not have a root CA cert in the store or because the key usage field of the sub CA cert is incorrect. 4) How do I add multiple chained CA certs to the store? Is X509_STORE_add_cert() sufficient? Will all certificates be presented when an incoming TLS connection is established, or only all certs up to and not including the root CA certificate? Any help with these questions would be greatly appreciated. Thanks. Leo Koutikas SMTS Software Engineer IPC Systems, Inc. DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
trying to replicate ECC signing with openssl
i was given a small "ecsign.exe" program that takes some ECC parameters, the private key, a random number, and outputs a signature of the specified binary. i'm trying to ditch this program in favor of the openssl suite (for obvious practical reasons). for example, the parameters file looks like (where # are comments): 163 # m: dimension of binary field 1 # a constant 1 # b constant 400020108A2E0CC0D99F8A5EF # Xg 2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8 # Yg 289070FB05D38FF58321F2E800536D538CCDAA3D9 # n 7 # k3 constant 6 # k2 constant 3 # k1 constant the private key looks like (no, not a security issue, this is a demo key): 1133A74FDA4FA538C92CE543521336B038D18EB5B the random number (again, demo value): 3A852AFB339E7AE3220CED10F478E0A018AAD27EF and for its output signature on a random file, we get: 3C47B123C88549E6E375B2393AFBF604AEB9E9CE3 3069158A3B7AAA828086DAEC4875D949070885D24 it also produces this, but i believe it is a reformatting of the above: E39C9EEB4A60BFAF93235B376E9E54883C127BC40300245D887090945D87C4AE6D0828A8AAB7A35891060300 ive been trying to figure out exactly how to invoke openssl to get the equivalent behavior. using "-name sect163k1", it seems i do not need to set a/b/n manually as the ones used are the default. but i cant figure out where to plugin Xg/Yg/k3/k2/k1. i'm creating the parameters file with: openssl ecparam -name sect163k1 -rand -param_enc explicit -text but this is about where i'm stuck. i guess the output of ecparam is the .pem file that i'd combine with the private key above to feed to `openssl ec` to sign the binary in question. but i'm not sure how to convert the private key to the pem format ... when i use -genkey, the resulting base64 encoded key looks to be much longer than the private key i have above ? -mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AW: Decoding OCSP response data: ASN1_D2I_READ_BIO:not enough data
Dear list, another update - we got it. [Fri Jul 10 10:28:39 2009] [error] [client 172.30.64.154] MWDE/nm: OCSP response line unstripped: HTTP/1.1 200 OK [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(217): [client 172.30.64.154] OCSP response header: Date: Fri, 10 Jul 2009 09:29:06 GMT [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(217): [client 172.30.64.154] OCSP response header: content-type: application/ocsp-response [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(217): [client 172.30.64.154] OCSP response header: content-length: 1212 [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(217): [client 172.30.64.154] OCSP response header: Connection: close [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(260): [client 172.30.64.154] MWDE/nm, read turn 1: OCSP response read, but len == 0 [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(284): [client 172.30.64.154] OCSP response: got 0 bytes, 0 total [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(292): [client 172.30.64.154] MWDE/nm, read turn 1: OCSP response in data: nul [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(284): [client 172.30.64.154] OCSP response: got 1212 bytes, 1212 total [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(292): [client 172.30.64.154] MWDE/nm, read turn 2: OCSP response in data: 0\x82\x04\xb8\n\x01 [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(260): [client 172.30.64.154] MWDE/nm, read turn 3: OCSP response read, but len == 0 [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(284): [client 172.30.64.154] OCSP response: got 0 bytes, 1212 total [Fri Jul 10 10:28:39 2009] [debug] ssl_util_ocsp.c(292): [client 172.30.64.154] MWDE/nm, read turn 3: OCSP response in data: Solution was to change the break-conditions in Apache's mod_ssl (ssl_util_ocsp.c). The original code did break the loop reading response data from bucket to bio, if it read an EOF *or* it read data of length == 0. Now we got this strange responder, which sends 0 bytes in the first line of response. By only breaking the loop, if EOF is read, we get to the second (and third, until bucket is empty or an EOF is read) line of the response. And guess what's in the second line? :) Thanks for the pointers to really check the data received! Mit freundlichen Grüßen / Kind regards Natanael Mignon Von: Natanael Mignon - michael-wessel.de [...@michael-wessel.de] Gesendet: Freitag, 10. Juli 2009 09:35 An: openssl-users@openssl.org Betreff: AW: Decoding OCSP response data: ASN1_D2I_READ_BIO:not enough data Updated details. If we do compare the two requests (one failing because of "not enough data", one working fine), there are obvious differences in receiving the response. Working fine: [Tue Jul 07 14:32:24 2009] [debug] ssl_util_ocsp.c(104): [client 10.200.48.140] sending request to OCSP responder [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Date: Tue, 07 Jul 2009 13:32:52 GMT [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Server: Apache-Coyote/1.1 [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Content-Type: application/ocsp-response [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Content-Length: 1585 [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140] OCSP response header: Connection: close [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(250): [client 10.200.48.140] OCSP response: got 1585 bytes, 1585 total [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(258): [client 10.200.48.140] MWDE/nm: OCSP response in data: 0\x82\x06-\n\x01 [Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(234): [client 10.200.48.140] OCSP response: got EOF Failing: [Tue Jul 07 14:38:23 2009] [debug] ssl_util_ocsp.c(104): [client 172.30.64.154] sending request to OCSP responder [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: Date: Tue, 07 Jul 2009 13:38:51 GMT [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: content-type: application/ocsp-response [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: content-length: 1212 [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154] OCSP response header: Connection: close [Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(234): [client 172.30.64.154] OCSP response: got EOF [Tue Jul 07 14:38:24 2009] [error] SSL Library Error: error:0D06B08E:asn1 encoding routines:ASN1_D2I_READ_BIO:not enough data [Tue Jul 07 14:38:24 2009] [error] [client 172.30.64.154] failed to decode OCSP response data This actually looks like we do not receive any response data except headers. The code branch, where we print out the response data
AW: Decoding OCSP response data: ASN1_D2I_READ_BIO:not enough data
Updated details. If we do compare the two requests (one failing because of "not
enough data", one working fine), there are obvious differences in receiving the
response.
Working fine:
[Tue Jul 07 14:32:24 2009] [debug] ssl_util_ocsp.c(104): [client 10.200.48.140]
sending request to OCSP responder
[Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140]
OCSP response header: Date: Tue, 07 Jul 2009 13:32:52 GMT
[Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140]
OCSP response header: Server: Apache-Coyote/1.1
[Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140]
OCSP response header: Content-Type: application/ocsp-response
[Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140]
OCSP response header: Content-Length: 1585
[Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(208): [client 10.200.48.140]
OCSP response header: Connection: close
[Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(250): [client 10.200.48.140]
OCSP response: got 1585 bytes, 1585 total
[Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(258): [client 10.200.48.140]
MWDE/nm: OCSP response in data: 0\x82\x06-\n\x01
[Tue Jul 07 14:32:25 2009] [debug] ssl_util_ocsp.c(234): [client 10.200.48.140]
OCSP response: got EOF
Failing:
[Tue Jul 07 14:38:23 2009] [debug] ssl_util_ocsp.c(104): [client 172.30.64.154]
sending request to OCSP responder
[Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154]
OCSP response header: Date: Tue, 07 Jul 2009 13:38:51 GMT
[Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154]
OCSP response header: content-type: application/ocsp-response
[Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154]
OCSP response header: content-length: 1212
[Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(208): [client 172.30.64.154]
OCSP response header: Connection: close
[Tue Jul 07 14:38:24 2009] [debug] ssl_util_ocsp.c(234): [client 172.30.64.154]
OCSP response: got EOF
[Tue Jul 07 14:38:24 2009] [error] SSL Library Error: error:0D06B08E:asn1
encoding routines:ASN1_D2I_READ_BIO:not enough data
[Tue Jul 07 14:38:24 2009] [error] [client 172.30.64.154] failed to decode OCSP
response data
This actually looks like we do not receive any response data except headers.
The code branch, where we print out the response data is not even called,
because the receive-bucket seems to be empty after the headers have been read
out (Apache/mod_ssl/ssl_util_ocsp.c, "while (!APR_BRIGADE_EMPTY(bb))" -->
copies from bb to bio).
What disturbes me: Doing the same request from the same system with a generic
OCSP-client (Java-based, using Bouncycastle-lib) works fine ("OCSP Response:
GOOD").
Any ideas?
Mit freundlichen Grüßen / Kind regards
Natanael Mignon
Von: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] im
Auftrag von Dr. Stephen Henson [st...@openssl.org]
Gesendet: Freitag, 3. Juli 2009 18:39
An: openssl-users@openssl.org
Betreff: Re: Decoding OCSP response data: ASN1_D2I_READ_BIO:not enough data
I suggest you check to see if you really get 1212 bytes of data in the
response and log them somewhere. If you post the result it can be analysed to
see if the response is valid.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
