Re: X509 verify
I'm using the PEM_write_X509(), avoiding the BIO, is there any difference?
Anyway, this function does not give errors.
Calling the ERR_error_string() on the failed verify, the error returned is:
error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib
Searching on Google for this error it is not so helpful, it says only that
something on the certificate or on the public key is wrong.
Probably the i2d/d2i functions add something undesired on mine X509
structure.
Thanks again for your help.
Best Regards
Andrea Saracino
2011/7/28 Erwin Himawan ehima...@gmail.com
By the way sorry for the font size, it does not mean anything, it just
mixed up during cut and paste.
The function to dump x509 into a certificate is is PEM_write_bio_X509() and
the function to dump a x509 der file is bio_write(). Here is the doc on
bio_write http://www.manpagez.com/man/3/BIO_write/osx-10.3.php
erwin
On Wed, Jul 27, 2011 at 8:20 PM, Erwin Himawan ehima...@gmail.com wrote:
**
I would not use the X509_print_fp(), since it does not give you the PEM
or DER file.
Use intead PEM_write_bio or write_bio() for PEM and DER respectively.
Also check for error for the status of these two bio write function.
hopefully it helps
*From:* Andrea Saracino saracino.and...@gmail.com
*Sent:* Wednesday, July 27, 2011 6:05 PM
*To:* openssl-users@openssl.org
*Subject:* Re: X509 verify
Hi Erwin, thanks for your fast answer.
I dumped both the certificates in 2 PEM files, then I used the
X509_print_fp() to obtain the readable version of both of them. The two
resulting files are identical. Perhaps there is something wrong in the
invocation of the i2d/d2i functions. I'm posting an extract of the code:
//
struct T_G_4{
unsigned char nonce[NONCE_SIZE];
int cert_size;
unsigned char certificate[MAX_MSG_SIZE-NONCE_SIZE-sizeof(int)];
}
/*...*/
T_G_4 * TG4=new T_G_4;
/*...*/
peer_certificate=/* initialization function */ //this is a private member
of a class and the two functions are members of the same class
EVP_PKEY * pubkey=EVP_PKEY_new();
EVP_PKEY_set1_RSA(pubkey, rsa_ca_pub_key);
X509_verify(peer_certificate,pubkey); //this verification returns 1
unsigned char * serialized certificate=NULL; //following the example of
the openssl d2i_X509 page, NULL pointer avoids the management of the
increasing pointer
TG4-cert_size=i2d(peer_certificate,serialized_certificate);
//serialization
memcpy(TG4-certificate,serialized_certificate,TG4-cert_size);
//initialize the remaining fields and return TG4
//passing the structure to another function
//other function:
/*...*/
unsigned char * serialized_certificate=new unsigned char [TG4-cert_size];
memcpy(serialized_certificate,TG4-certificate,TG4-cert_size);
peer_certificate = d2i_X509(NULL,(const unsigned char
**)serialized_certificate,TG4-cert_size); //deserialization
X509_verify(peer_certificate,pubkey); //now it returns 0... :(
/*...*/
Is there something wrong in this code?
Thanks in advance.
Best Regards
Andrea Saracino
2011/7/27 Erwin Himawan ehima...@gmail.com
The way I would verify this is by writting the original X509 object into
PEM file and dumping the X509 object resulted from d2i_x509() into another
PEM file and compares both files using the openssl ; either using asnparse
or x509 command.
On Wed, Jul 27, 2011 at 9:46 AM, Andrea Saracino
saracino.and...@gmail.com wrote:
Hello everyone,
I've found some issues using the function X509_verify() on a simple X509
certificate. After the creation, if I call:
X509_verify(certificate,ca_key);
the function returns 1, but if I call the i2d_X509() function on the
certificate and then the d2i_X509() on the obtained byte string, the
X509_verify() on the resultant certificate returns 0.
I printed the certificate, in a readable format, before and after the
i2d() and d2i() execution and the result is exactly the same. The various
fields (issuer, subject...) have the correct values. Any ideas?
Best Regards
Andrea Saracino
Re: support for 2048-bit keys
Somewhere I have read that RSA key size limit is 32k or so. Largest key I have attempted to generate was 24k, largest key successfully generated and used was 16k. Are the these RSA keys or DH parameters? In any case 2048bit (2k) sized keys are supported almost by anything. Hello, I am working on a product where we are upgrading from openssl-0.9.8.d to version 1.0.0, and we want to transition from using 1024 bit keys to 2048. I am coming up to speed with SSL in general. My question is: was key length of 2048 already supported on openssl-0.9.8.d? I did read about it in HOWTO, but I just want to make sure. Thanks, Dirce __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Simple question: Maximum length of PEM file?
Thanks Wim, for your kind informative answer. Wim Lewis-3 wrote: On 26 Jul 2011, at 10:16 PM, Katif wrote: Can you tell me what are the application dependency factor here so we'll be able to chase a limit? It is used as an RSA key exchange certification/private key pairing. Thanks... The two things that are variable size are the key material itself, and the many fields that can occur in a certificate. A private key file just has key material, so its size should be proportional to the key size in bits (plus constant overhead); a certificate has key material for the key it represents, a signature from the issuer's key (which may have a size dependent on that key's size), and an arbitrary collection of other data that can be incorporated into the certificate when it's created (such as the name or address of the subject, or a list of permitted/forbidden uses, CRL distribution points, legal boilerplate, etc). I don't think there's any limit to the amount of extension data that can be included in a certificate, though in practice it's rarely more than a few kilobytes. I'd suggest parsing a handful of files using openssl asn1parse to get an idea of what's in there and how large each thing is. The sizes and offsets that asn1parse gives you refer to the DER-encoded file; a PEM-encoded file has four bytes for every three of DER, plus another few percent overhead for line endings. As Kenneth Goldman says, though, you need to consider what will happen when you encounter a certificate larger than you expect, because it *will* happen. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/Simple-question%3A-Maximum-length-of-PEM-file--tp32139325p32155520.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: support for 2048-bit keys
It is for RSA keys. Thanks, Dirce Somewhere I have read that RSA key size limit is 32k or so. Largest key I have attempted to generate was 24k, largest key successfully generated and used was 16k. Are the these RSA keys or DH parameters? In any case 2048bit (2k) sized keys are supported almost by anything. Hello, I am working on a product where we are upgrading from openssl-0.9.8.d to version 1.0.0, and we want to transition from using 1024 bit keys to 2048. I am coming up to speed with SSL in general. My question is: was key length of 2048 already supported on openssl-0.9.8.d? I did read about it in HOWTO, but I just want to make sure. Thanks, Dirce __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Re: Re: Handshake question
That didn't work. I immediately got an error from the server :
SSL3_GET_CLIENT_HELLO: no shared cipher.
Do you know what my original error meant:
SSL_BYTES_TO_CIPHER_LIST:scsv received when renegotiating
Maybe if I know what it is referring to I can track down the issue. There
isn't much posted on the net about it.
On , castre...@gmail.com wrote:
Hi Eriwin,
Your response does make sense but I need to clarify.
I created a CA Certifcate and a private key.( CA.cert and CAPrivate.key)
I then created a server certificate request ( server.csr and server.key)
and signed it with the CA's private key, creating the
following 2 files: server.crt, and server.pem.
Now currently in my program the server-side is loading the server.pem
file and the server.key file.
The client-side is loading the CA.cert.
So if I understand what you are saying above. I need to reverse the
loading ( below is what I currently have in my code:
if(ac.user() == server)
{
_ssl_context = new ssl::context(ssl::method_sslv3, ssl::role_server);
_ssl_context-set_certificate(ssl\\subexec\\certs\\01.pem,
ssl\\subexec\\private\\server.key);
}
else //client
{
_ssl_context = new ssl::context(ssl::method_sslv3, ssl::role_client);
_ssl_context-set_ca_certificate(ssl\\subexec\\certs\\ca.crt);
}
Are you saying it should be :
if(ac.user() == client)
{
_ssl_context = new ssl::context(ssl::method_sslv3, ssl::role_server);
_ssl_context-set_certificate(ssl\\subexec\\certs\\01.pem,
ssl\\subexec\\private\\server.key);
//_ssl_context-set_ca_certificate(ssl\\subexec\\certs\\ca.crt);
}
else //client
{
_ssl_context = new ssl::context(ssl::method_sslv3, ssl::role_client);
_ssl_context-set_ca_certificate(ssl\\subexec\\certs\\ca.crt);
}
On , Erwin Himawan ehima...@gmail.com wrote:
You metion that:
Server loads its server certificate and private key ( self-signed by a
CA that I created).
I would liem to clarify: the server cert is a self signed cert? or the
CA cert is a self signed cert?
If the server cert is a self signed cert, the server is actually the
ca, which in this case, the client needs the server slef signed cert.
If the server is not a self-signed cert, make sure that the ca
self-signed cert can verify the server cert. You can use the openssl
verify CLI to do this. If you can then give the ca cert to client. If i
remember correctly, when you set the verify peer to none, the server does
not do cert-based auth on the client. however, tls spec specifies that
client must do cert-based auth on the server. so, server must send the
client its cert.
hopefully, my reply make sense.
On Wed, Jul 27, 2011 at 3:52 PM, castre...@gmail.com wrote:
I need some help.
I am basically stuck and don't know how to fix the handshake and must
be missing something.
Perhaps it is something with the certificates.
I have a server certificate/privatekey and a CA certificate.
Server loads its server certificate and private key ( self-signed by a
CA that I created).
The client loads the CA certificate.
Using memory buffers and blocking IO.
I begin the handshake by the client intiating hello message.
The server reads message, and data is put in its ssl output. This is
sent back to client.
The client read the data ( SSL_read) and data it populated in the ssl
output. This is sent back to the server. ( it is waiting for more input
from server)
The server reads the data (SSL_read) and nothing is generated in
outbut it is waiting for more information from client.
Basically I am at a stale mate now.
What information am I missing.
When I go and look at what state the client is in it say it is
UNKWN..what does this imply
Do I need a client certificate even though I have programmed the server
to be a VERIFY_PEER_NONE?
Does anybody have any references/books I can go get to help me with
this issue...I am completely lost and confused.
Note: I am currently working on windows.
Re: testing null encryption
hi, thanks for the info victor. played with the openssl command line utility using the s_client s_server being configured to use eNULL with only NULL_SHA , NULL_MD5. The other ciphers of eNULL are disabled. I could see the client sending the above ciphers and the server selecting NULL_SHA. Whatever i type at the server i could see that message in the client terminal. hence i assume the exchange between client server does happen. I have two queries: 1) When i use my own applications (client server) which uses the openssl library a separate client program and a separate server program,both configured to use only eNULL as above. (ie with only NULL_SHA NULL_MD5), i am seeing a error at the server application saying: Error in GET_CLIENT_HELLO_MSG: No shared ciphers: in s_srvr.c . I feel there is something missing in my client server applications compared to the openssl client server programs. Unable to understand what the error message is saying .. i was expecting that since both my client server have the common ciphers - NULL_SHA NULL_MD5, one of them to get selected and the handshake should get completed can somebody tell what the error messages convey in my application. 2) Getting back to the client server programs supplied along with the openssl package. When eNULL was configured as mentioned above, ran the wireshark packet capture utility. typed hello world at the server and the hello world was reflected in the client. Was expecting hello world to be seen in clear text because NULL encryption is used. But in wireshark i could not see anything in clear text .. Atleast i could not see hello world in the application data section of wireshark. Rightly application data was after the client hello exchange messages sent by the ssl protocol. wondering why clear text message was not seen does any form of encoding is used by the client server.?? Thanks. have a nice day, navin From: Victor Duchovni victor.ducho...@morganstanley.com To: openssl-users@openssl.org openssl-users@openssl.org Sent: Wednesday, 27 July 2011, 20:20 Subject: Re: testing null encryption On Wed, Jul 27, 2011 at 02:53:09AM -0700, navin gopalakrishnan wrote: a) testing NULL Encryption: While building openssl i modified the macro SSL_DEFAULT_CIPHER_LIST to #define SSL_DEFAULT_CIPHER_LIST eNULL That was unwise, don't do that. My understanding is the above modification? would provide only data authentication with NO encryption. Or possibly neither: $ openssl ciphers -v eNULL ECDHE-RSA-NULL-SHA SSLv3 Kx=ECDH Au=RSA Enc=None Mac=SHA1 ECDHE-ECDSA-NULL-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=None Mac=SHA1 AECDH-NULL-SHA SSLv3 Kx=ECDH Au=None Enc=None Mac=SHA1 ECDH-RSA-NULL-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=None Mac=SHA1 ECDH-ECDSA-NULL-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=None Mac=SHA1 NULL-SHA SSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1 NULL-MD5 SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5 as you can see above, the AECDH-NULL-SHA cipher provides neither authentication nor encryption, just message integrity over an anonymous channel. Is there a way to check this by running any test programs. You should not change the DEFAULT cipher list. Rather, applications can be configured with appropriate ciphers at run-time. The ciphers(1) utility, by default lists the DEFAULT ciphers. $ openssl ciphers $ openssl ciphers -v b) build openssl with no compression/decompression support in openssl.? You could read the INSTALL document that is included with the source code. While building openssl passed no-zlib option in the configure script and build went fine. This is documented to do what you requested. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: testing null encryption
On Thu, Jul 28, 2011 at 09:14:34AM -0700, navin gopalakrishnan wrote: 1) When i use my own applications (client server) which uses the openssl library a separate client program and a separate server program, both configured to use only eNULL as above. (i.e. with only NULL_SHA NULL_MD5), The ciphers are NULL-SHA and NULL-MD5, not NULL_SHA or NULL_MD5. $ openssl ciphers -v NULL-SHA:NULL-MD5 NULL-SHASSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1 NULL-MD5SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5 I am seeing a error at the server application saying: Error in GET_CLIENT_HELLO_MSG: No shared ciphers: in s_srvr.c . Then perhaps you have not installed a suitable server certificate, or more likely you have not in fact correctly configured the client or server cipherlist. Unable to understand what the error message is saying .. i was expecting that since both my client server have the common ciphers - NULL_SHA NULL_MD5, one of them to get selected and the handshake should get completed Either the server has no certificate, or you've misconfigured the ciphers: 2) Getting back to the client server programs supplied along with the openssl package. When eNULL was configured as mentioned above, ran the wireshark packet capture utility. typed hello world at the server and the hello world was reflected in the client. Was expecting hello world to be seen in clear text because NULL encryption is used. But in wireshark i could not see anything in clear text .. Atleast i could not see hello world in the application data section of wireshark. Rightly application data was after the client hello exchange messages sent by the ssl protocol. wondering why clear text message was not seen does any form of encoding is used by the client server.?? Compression may have been enabled. Or your test is flawed. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
