Problems with OpenSSL Engine and hashing.
Hello everybody, I have a problem in making our OpenSSL Engine that drives our HW accelerator work fine for hash (SHA1 in particular). The problem seems to be related to my Digest_Copy or (less likely) Digest_Cleanup implementation (I'll explain this further on). The Engine works fine for the Cipher algorithms (both just operating on a file and using s_client/s_server), and works fine for SHA1 when operating on a file. Trying to run an s_client / s_server session, I noticed that multiple context are used and the calls to Digest_Update function are mixed, so I have to maintain coherency in some way. - 1 - The easiest (and quickest) way to do this is to buffer the data that I receive at each call to Digest_Update, for each context, and ask for a real hash operation only when I receive the Digest_Final for that context. Doing in this way, everything is ok, both operating on a single file (here only one context is used) and using s_client / s_server (multiple contexts). In this scenario, in the Digest_Copy function I make a memcopy of the EVP_MD_CTX-md_data field where our data structure sits, and moreover I manually allocate and copy the buffer in which I am keeping the stored data. In the Digest_Cleanup I make a free of the buffer in which I keep the data (it is dynamically allocated) and I set to zero the counters used to keep track of its size and actual occupation. In this way, as I said, everything works. - 2 - The previous solution is mainly a workaround and has a big disadvantage if you want to hash large files or amount of data. So I decided to use the capability of our HW accelerator to save and restore the current context of the hash block. Here I have some problem, when using s_client/ s_server. Even if I implement it in the most trivial and inefficient way (RESTORE/UPDATE/SAVE at *each* call to update) it does not work. In this scenario, we have a buffer for the context in our data structure. I allocate this buffer at the first call to Digest_Update, obviously not setting the RESTORE flag for this first call. I call free for this buffer and put it to NULL in the Digest_Cleanup function and, if this buffer is valid (not null) I copy it in the Digest_Copy function, by allocating a proper memory area in the to context. If I use this solution on a single file, it works, so the SAVE/RESTORE mechanism works fine (and it has been proved elsewhere). But it fails in the s_client/s_server test. As the main difference is that here the Digest_Copy and Digest_Cleanup function are called, I suppose the problem is here, even if I do not see many differences with the scenario number -1- What am I missing? Could you help me? Can someone point me to some useful resource or describe me exactly what has to be implemented in the Digest_Copy (and Digest_Cleanup) function? Or do you know another way to avoid the problem of mixed context? I mean: sha1_init(ctx_A) sha1_update(ctx_A) sha1_init(ctx_B) sha1_update(ctx_B) sha1_update(ctx_A) Thank you very much and best regards, Marco Grella __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: calling SSL_library_init multiple times
Jagannadha Bhattu G wrote: Hi, Can I call SSL_library_init multiple times in my code under different threads? as SSL_library_init() initializes global tables it should only be called from one thread a time and of course no other thread should use the global data while SSL_library_init() is running. Ideally it should be run once before the threads using ssl are created. From the documented return values, it always returns 1 but this doesn't mean it's reentrant Cheers, Nils __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
remove
- Original Message - From: Marco GRELLA [EMAIL PROTECTED] Date: Monday, February 27, 2006 2:29 pm Subject: Problems with OpenSSL Engine and hashing. Hello everybody, I have a problem in making our OpenSSL Engine that drives our HW accelerator work fine for hash (SHA1 in particular). The problem seems to be related to my "Digest_Copy" or (less likely) "Digest_Cleanup" implementation (I'll explain this further on). The Engine works fine for the Cipher algorithms (both just operating on a file and using s_client/s_server), and works fine for SHA1 when operating on a file. Trying to run an s_client / s_server session, I noticed that multiple context are used and the calls to "Digest_Update" function are mixed, so I have to maintain coherency in some way. - 1 - The easiest (and quickest) way to do this is to buffer the data that I receive at each call to "Digest_Update", for each context, and ask for a real hash operation only when I receive the "Digest_Final" for that context. Doing in this way, everything is ok, both operating on a single file (here only one context is used) and using s_client / s_server (multiplecontexts). In this scenario, in the "Digest_Copy" function I make a "memcopy" of the EVP_MD_CTX-md_data field where our data structure sits, and moreover I manually allocate and copy the buffer in which I am keeping the stored data. In the "Digest_Cleanup" I make a "free" of the buffer in which I keep the data (it is dynamically allocated) and I set to zero the counters used to keep track of its size and actual occupation. In this way, as I said, everything works. - 2 - The previous solution is mainly a workaround and has a big disadvantageif you want to hash large files or amount of data. So I decided to use the capability of our HW accelerator to save and restore the current context of the hash block. Here I have some problem, when using s_client/ s_server. Even if I implement it in the most trivial and inefficient way (RESTORE/UPDATE/SAVE at *each* call to update) it does not work. In this scenario, we have a buffer for the context in our data structure. I allocate this buffer at the first call to "Digest_Update",obviously not setting the RESTORE flag for this first call. I call "free" for this buffer and put it to NULL in the "Digest_Cleanup"function and, if this buffer is valid (not null) I copy it in the "Digest_Copy" function, by allocating a proper memory area in the "to" context. If I use this solution on a single file, it works, so the SAVE/RESTORE mechanism works fine (and it has been proved elsewhere). But it fails in the s_client/s_server test. As the main difference is that here the "Digest_Copy" and "Digest_Cleanup" function are called, I suppose the problem is here, even if I do not see many differences with the scenarionumber -1- What am I missing? Could you help me? Can someone point me to some useful resource or describe me exactly what has to be implemented in the Digest_Copy (and Digest_Cleanup) function?Or do you know another way to avoid the problem of "mixed context"? I mean: sha1_init(ctx_A) sha1_update(ctx_A) sha1_init(ctx_B) sha1_update(ctx_B) sha1_update(ctx_A) Thank you very much and best regards, Marco Grella __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-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]
AES key length selection bug in OpenSSL 0.9.8a
Dear OpenSSL users, OpenSSL 0.9.8a does not allow to properly select AES key length. It selects both 128-bit and 256-bit AES no matter which one was specified: [EMAIL PROTECTED]:~$ /usr/local/ssl/bin/openssl version OpenSSL 0.9.8a 11 Oct 2005 [EMAIL PROTECTED]:~$ /usr/local/ssl/bin/openssl ciphers -v AES256-SHA AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 The old OpenSSL version works fine: [EMAIL PROTECTED]:~$ /usr/bin/openssl version OpenSSL 0.9.7e 25 Oct 2004 [EMAIL PROTECTED]:~$ /usr/bin/openssl ciphers -v AES256-SHA AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 Here is another example of the same problem: [EMAIL PROTECTED]:~$ /usr/local/ssl/bin/openssl s_client -cipher AES128-SHA CONNECTED(0003) [cut] SSL-Session: Protocol : TLSv1 Cipher: AES256-SHA [cut] Is there any known solution? Can you help? Best regards, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: First posting NEWBEE
MySQL would have to implement this. I believe there is some support of SSL encrypted connections in MySQL. Try here first: http://dev.mysql.com/doc/refman/5.0/en/secure-connections.html and if you still have questions, try the MySQL mailing lists. Otherwise I'm sure you can call OpenSSL functions from Delphi. Mark __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Installing a certificate chain
I'm trying to get a client to verify a server certificate signed by a sub-CA when the client has only the root CA certificate. I'm using TinyCA (GUI wrapper around OpenSSL) as the CA. Here's what I've done: 1. Created a root CA (CN=root.ca.linnet.org) 2. Created a sub CA under this (CN=sub.ca.linnet.org) 3. Created a CSR and signed it by the sub CA 4. Installed the certificate in a small server #!/bin/sh cd content openssl s_server -cert ../server.example.com-cert.pem \ -key ../server.example.com-key.pem \ -CApath /etc/ssl/certs \ -WWW 5. Installed the root CA's certificate under /etc/ssl/certs and re-ran c_rehash to incorporate it. However, when the client connects, it is not presented with a full certificate chain back to the root, but just the certificate signed by the subCA: $ openssl s_client -connect localhost:4433 -CApath /etc/ssl/certs -showcerts ... --- Certificate chain 0 s:/C=GB/L=London/O=Test server certificate/CN=server.example.com i:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=sub.ca.linnet.org/[EMAIL PROTECTED] --- As a result, even though the client has the root certificate available (CN=root.ca.linnet.org), it's unable to verify the certificate presented. Somehow, I need to get the server to present a full certificate chain to the client. I tried appending the sub CA's own certificate (signed by the root CA) to server.example.com-cert.pem, but that didn't make any difference. If I swapped the two around, so that the sub CA's certificate is first, then OpenSSL won't start: $ ./server.sh Using default temp DH parameters Enter PEM pass phrase: unable to get private key from '../server.example.com-key.pem' 86322:error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509/x509_cmp.c:389: Anyway, it's not clear to me whether the certificate generated by TinyCA is incomplete, or whether there's some additional configuration required by the server to get it to send the chain. I'd be very grateful if someone could point me in the right direction. The certificates and their decoding are attached below. Regards, Brian. Here are the two certificates, which currently are appended together in server.example.com-cert.pem, although it seems only the first one is used. -BEGIN CERTIFICATE- MIIFLDCCAxSgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBiTELMAkGA1UEBhMCR0Ix DzANBgNVBAcTBkxvbmRvbjEvMC0GA1UEChMmQ2FuZGxlciBJbnNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkxGjAYBgNVBAMTEXN1Yi5jYS5saW5uZXQub3JnMRww GgYJKoZIhvcNAQkBFg1jYUBsaW5uZXQub3JnMB4XDTA2MDIyNzA5NTQ1OVoXDTA3 MDIyNzA5NTQ1OVowXTELMAkGA1UEBhMCR0IxDzANBgNVBAcTBkxvbmRvbjEgMB4G A1UEChMXVGVzdCBzZXJ2ZXIgY2VydGlmaWNhdGUxGzAZBgNVBAMTEnNlcnZlci5l eGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr3UiikWgAhQV NFAWeXXPK+7XtbaOVKpcoL0+Ok9Cm9z+nJWJ1cpq/4zJxkRR5LFXjrRy9jqp+1Zx aZewAmp4FsuZRhTOO47ugOKsII5Kimwekus6TK9NTScPZ8H9RyqSGekL/7COZc7a kmmEPc0zN3CRcgPhYsD2geXtkOm/akMCAwEAAaOCAUwwggFIMAkGA1UdEwQCMAAw EQYJYIZIAYb4QgEBBAQDAgZAMCsGCWCGSAGG+EIBDQQeFhxUaW55Q0EgR2VuZXJh dGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBS5Cjm+UPTMK/3DzRe7d9KK5Ko83zCB tgYDVR0jBIGuMIGrgBTpiiSu+6nySxH2HwjSEw6vFlOCK6GBj6SBjDCBiTELMAkG A1UEBhMCR0IxDzANBgNVBAcTBkxvbmRvbjEvMC0GA1UEChMmQ2FuZGxlciBJbnNl Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxGzAZBgNVBAMTEnJvb3QuY2EubGlu bmV0Lm9yZzEbMBkGCSqGSIb3DQEJARYMY2FAbGlubmV0Lm9nggEBMBgGA1UdEgQR MA+BDWNhQGxpbm5ldC5vcmcwCQYDVR0RBAIwADANBgkqhkiG9w0BAQUFAAOCAgEA H/9GBEq95+QCNJRYKmj+EJX+DjLT7r9xzZpj/uGWj5eQ6rpJzox8rcXeXWjuLa4z Jps0h5L8EcayVM3LGo2mbYvpAqkzbH0IRX8RX5DKZS5dMwNWvjk97U1KKcTUBoU3 AwYGg4gRkYUIsx34sEyT+FTZsw+KnPJmAjgFqCgdQFncqAioLFFbEPaz/Rc8DTtv yfWivTO4aHVS8sew0wzKcqNwQZqelMoGTrbcl3YUscPO/jVIS92X/YMwqPbUb0te 4JeUnXxGGXhyaF6dlGnZ1BfNUkPn78vHNc8pDcvjCiDN3r4UqjLs1q3TXdFya98I apsmUcaynoyZAnn7GHIWoKkRBPVQ0CFZ5CaI5ISG0wD1t/pYq3XZm9+v1IdfAsAv p/fw12Zo3i04aUVx9XafqJnFRm6f2n7U8QWqNtTg9nYwIzwFwQmaWUaodvCKXfRp fEnxjCLFmoHORL/Vhr5Ym6m7Sx3bXXGcc2+G48c0EGsc7LZ8biKsBpm0B6HIhIb1 xvaz531FA21NBAH/z5kTeE1oncIRR+VdXhZ1sSirJMy0hNjqJcJH4NTHOuc0KUFe 3STpBNE7qfbGW7GskMN6ZoiqvD4UFAggs1/FGv3ZC1xFz2rO568MsBjsAvV2yd3x y0MA0ara5qLIB+YxqYx1Wxu/jckoUpgDM2wbDJzb+iA= -END CERTIFICATE- -BEGIN CERTIFICATE- MIIHCTCCBPGgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBiTELMAkGA1UEBhMCR0Ix DzANBgNVBAcTBkxvbmRvbjEvMC0GA1UEChMmQ2FuZGxlciBJbnNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkxGzAZBgNVBAMTEnJvb3QuY2EubGlubmV0Lm9yZzEb MBkGCSqGSIb3DQEJARYMY2FAbGlubmV0Lm9nMB4XDTA2MDIyNzA5NTIwNFoXDTE2 MDIyNTA5NTIwNFowgYkxCzAJBgNVBAYTAkdCMQ8wDQYDVQQHEwZMb25kb24xLzAt BgNVBAoTJkNhbmRsZXIgSW5zZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRow GAYDVQQDExFzdWIuY2EubGlubmV0Lm9yZzEcMBoGCSqGSIb3DQEJARYNY2FAbGlu bmV0Lm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJo0SnhJcnpf 8CDjzLsO/FJYVRItFpkVK6X7icd0QgsgRVRd3svJPsspRCO4ui+WHfZWSJ2Jbq7r K1tNAHYAoldmc3rFBZVcdz/LlaH8ZLYyC31M2psIprcSxGVRpkbvNDv3Ezgn32ci bRAcA3lNpYv4TJt2gqkEkUpttMMXWOkliTW6gSd8BmnImGvkjgN0MrPrEUHnQ1tR
Re: build non-bsafe version of Openssl
You are mistaken. OpenSSL does not use BSafe. /r$ -- SOA Appliance Group IBM Application Integration Middleware __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: calling SSL_library_init multiple times
Jagannadha Bhattu G [EMAIL PROTECTED]: Hi, Can I call SSL_library_init multiple times in my code under different threads? From the documented return values, I conclude that it should be possible. Can some one confirm it? Thanks JB Yes it's possible. I'm doing like this for now... , but I'm not shure whether this is correct... //wbr - Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: build non-bsafe version of Openssl
Hi Richard,Thanks a lot for that clarification. Actually i was a bit confused about this since in some places I read that there is a patch that can be installed to enable BSAFE. In some other place I read that BSAFE is now available as part of Openssl currently. coz of this, I thought I had to explicitly give some option so that a non-bsafe version of Openssl is built. Thanks again :-)SmithaOn 2/27/06, Richard Salz [EMAIL PROTECTED] wrote: You are mistaken.OpenSSL does not use BSafe./r$--SOA Appliance GroupIBM Application Integration Middleware__ OpenSSL Project http://www.openssl.orgUser Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Installing a certificate chain
On Mon, Feb 27, 2006, Brian Candler wrote: I'm trying to get a client to verify a server certificate signed by a sub-CA when the client has only the root CA certificate. I'm using TinyCA (GUI wrapper around OpenSSL) as the CA. Here's what I've done: 1. Created a root CA (CN=root.ca.linnet.org) 2. Created a sub CA under this (CN=sub.ca.linnet.org) 3. Created a CSR and signed it by the sub CA 4. Installed the certificate in a small server #!/bin/sh cd content openssl s_server -cert ../server.example.com-cert.pem \ -key ../server.example.com-key.pem \ -CApath /etc/ssl/certs \ -WWW 5. Installed the root CA's certificate under /etc/ssl/certs and re-ran c_rehash to incorporate it. However, when the client connects, it is not presented with a full certificate chain back to the root, but just the certificate signed by the subCA: $ openssl s_client -connect localhost:4433 -CApath /etc/ssl/certs -showcerts ... --- Certificate chain 0 s:/C=GB/L=London/O=Test server certificate/CN=server.example.com i:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=sub.ca.linnet.org/[EMAIL PROTECTED] --- As a result, even though the client has the root certificate available (CN=root.ca.linnet.org), it's unable to verify the certificate presented. Somehow, I need to get the server to present a full certificate chain to the client. I tried appending the sub CA's own certificate (signed by the root CA) to server.example.com-cert.pem, but that didn't make any difference. If I swapped the two around, so that the sub CA's certificate is first, then OpenSSL won't start: $ ./server.sh Using default temp DH parameters Enter PEM pass phrase: unable to get private key from '../server.example.com-key.pem' 86322:error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509/x509_cmp.c:389: Anyway, it's not clear to me whether the certificate generated by TinyCA is incomplete, or whether there's some additional configuration required by the server to get it to send the chain. I'd be very grateful if someone could point me in the right direction. The certificates and their decoding are attached below. Regards, Brian. Here are the two certificates, which currently are appended together in server.example.com-cert.pem, although it seems only the first one is used. [snipped] Since you didn't include the root CA it isn't possible to say why it isn't excluded. I notice the small serial numbers in the certificates and some invalid extensions in there. I'd suggest using the CA.pl script (if you use OpenSSL 0.9.8 get it from a recent snapshot: the included one is buggy) instead. 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: AES key length selection bug in OpenSSL 0.9.8a
Hi Michal, OpenSSL 0.9.8a does not allow to properly select AES key length. It selects both 128-bit and 256-bit AES no matter which one was specified: I reported this same bug in February 17th, and Dr. Steven Henson has confirmed it is a bug so hopefully it will be fixed soon. If you find any work around please let me know. -Chris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
ld.so.1
Hi, Does somebody has an idea about the following error message.ld.so.1: /usr/local/ssl/bin/openssl: fatal: libssl.so.0.9.7: open failed: No such file or directoryI don't understand 'cause openssl is correctly installed and my $PATH and $LD-LIBRARY_PATH seem to be correct.HOST:user1% echo $PATH/opt/VRTSvmsa/bin:/etc/vx/bin:/var/opt/STORtools/bin:/var/opt/SUNWvts/bin:/opt/SUNWvts/bin:/usr/local/ssl/bin:/usr/ccs/bin:/usr/local/bin:/oracle/JOY/817_32/bin:/home/joyadm:/usr/sap/JOY/SYS/exe/run:/usr/bin:.:/usr/ccs/bin:/usr/ucb HOST:user2% echo $LD_LIBRARY_PATH/usr/local/lib:/usr/local/ssl/libNB: I'm a newbie so don't blame me for all the stupid things I can write and I 'm not an english native speakersothank youjs Yahoo! Mail Bring photos to life! New PhotoMail makes sharing a breeze.
Re: ld.so.1
Salut, i suppose you have installed an SMC package, have you done a pkgchk SMCosslxx ? do libso have execute bit set ? what Solaris is it ? John Doe a crit: Hi, Does somebody has an idea about the following error message. ld.so.1: /usr/local/ssl/bin/openssl: fatal: libssl.so.0.9.7: open failed: No such file or directory I don't understand 'cause openssl is correctly installed and my $PATH and $LD-LIBRARY_PATH seem to be correct. HOST:user1% echo $PATH /opt/VRTSvmsa/bin:/etc/vx/bin:/var/opt/STORtools/bin:/var/opt/SUNWvts/bin:/opt/SUNWvts/bin:/usr/loca l/ssl/bin:/usr/ccs/bin:/usr/local/bin:/oracle/JOY/817_32/bin:/home/joyadm:/usr/sap/JOY/SYS/exe/run:/ usr/bin:.:/usr/ccs/bin:/usr/ucb HOST:user2% echo $LD_LIBRARY_PATH /usr/local/lib:/usr/local/ssl/lib NB: I'm a newbie so don't blame me for all the stupid things I can write and I 'm not an english native speakerso thank you js Yahoo! Mail Bring photos to life! New PhotoMail makes sharing a breeze.
Re: Installing a certificate chain
On Mon, Feb 27, 2006 at 01:41:33PM +0100, Dr. Stephen Henson wrote: Since you didn't include the root CA it isn't possible to say why it isn't excluded. I notice the small serial numbers in the certificates and some invalid extensions in there. I'd suggest using the CA.pl script (if you use OpenSSL 0.9.8 get it from a recent snapshot: the included one is buggy) instead. The root certificate is attached below. I also tried appending this to my server.example.com-cert.pem (so there were three certificates in all), but that didn't make a difference. Is it correct of me simply to concatenate the server certificate together with the sub-CA certificate and the root certificate? Or should TinyCA have created a certificate which incorporates the whole chain itself? Or does the application use some other mechanism to assemble the chain from the constituent certificates? I'm afraid I'm not sufficiently PKCS#7-savvy to know what a real certificate at the bottom of a chain should look like. I think that the small serial numbers are intentional; these are the first certificates issued by the root CA and the sub CA respectively, and openssl creates them as newcerts/01.pem. However, I note that the root self-signed certificate does seem to have a very large serial number. I can try doing everything from scratch using openssl commands solely, but TinyCA itself is just a set of perl scripts which call openssl req/ca as required. Do you think TinyCA is invoking openssl wrongly in this case? Regards, Brian. -BEGIN CERTIFICATE- MIIHAjCCBOqgAwIBAgIJAP5hXQM6l3J+MA0GCSqGSIb3DQEBBAUAMIGJMQswCQYD VQQGEwJHQjEPMA0GA1UEBxMGTG9uZG9uMS8wLQYDVQQKEyZDYW5kbGVyIEluc2Vj dXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTEbMBkGA1UEAxMScm9vdC5jYS5saW5u ZXQub3JnMRswGQYJKoZIhvcNAQkBFgxjYUBsaW5uZXQub2cwHhcNMDYwMjI3MDk0 ODQ1WhcNMTYwMjI1MDk0ODQ1WjCBiTELMAkGA1UEBhMCR0IxDzANBgNVBAcTBkxv bmRvbjEvMC0GA1UEChMmQ2FuZGxlciBJbnNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRo b3JpdHkxGzAZBgNVBAMTEnJvb3QuY2EubGlubmV0Lm9yZzEbMBkGCSqGSIb3DQEJ ARYMY2FAbGlubmV0Lm9nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 86u5sSM8mxdIhuTOZbOtr2mkUOzjINQTVqIWR7mLmaCNyz5Zvqd2Pu4DjwrRadko zVrtxlG2C1kwd9zUEB0MaRkrOL6EdaQNxNZ7OIoP+JYPAKzSlwcu6wiIFsYZZ9Zg QCs150kw9CYfofjsC5NHWetfogJvnKtseqBfQt5Ohl3SGM26/JQpMF0GpJWL/U4L GBvWsRKZRlTHAAWWv8AAOFPgLEfTgLKvOPNHUxoG+TDH2CtNfQO5DpxacB4WFKPP 5NSmVu5bxWWqalU07J0xuv+KlLRdJZ0ZORLaxq919ezxVCjwVfqv80Y6LzzwgZsz 9kIlWoN+N3U3SA8gVuOcrdUmh/HRIs4YkSjeaqfF0n91YNMwdMvipKmX0OeinujK eNEvT16JAGjUaveTQulvPkWDhV7evXh1yGv5HFfoIp/N6zGAKBr2uZDtgd6vnXlU eRLMXAtokbCkB+Rd7el4SBO0ZgeUTA2chZNjtv17mbWZQR0NQsMdYgOO4oc/MEoa ZwaesMec0iLNtCpSq2TyxikkC0qAcirv/a4Qqbb35DXdSRiXS11A11pDTQdGqKBY u9RZTTCk2JYkxcLC8DLf2BsK/NBrb+WV24fyLOelbbhBUyQoxvF0vkhO2MdDfjns yr8UBF6IqYvhPmHTNSx9WJXfkLU2HyI0n7QZ/lvjipsCAwEAAaOCAWkwggFlMB0G A1UdDgQWBBRc63ElpozI5U1LsApJkx5YAYl3HjCBvgYDVR0jBIG2MIGzgBRc63El pozI5U1LsApJkx5YAYl3HqGBj6SBjDCBiTELMAkGA1UEBhMCR0IxDzANBgNVBAcT BkxvbmRvbjEvMC0GA1UEChMmQ2FuZGxlciBJbnNlY3VyZSBDZXJ0aWZpY2F0ZSBB dXRob3JpdHkxGzAZBgNVBAMTEnJvb3QuY2EubGlubmV0Lm9yZzEbMBkGCSqGSIb3 DQEJARYMY2FAbGlubmV0Lm9nggkA/mFdAzqXcn4wDwYDVR0TAQH/BAUwAwEB/zAR BglghkgBhvhCAQEEBAMCAQYwCQYDVR0SBAIwADArBglghkgBhvhCAQ0EHhYcVGlu eUNBIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAXBgNVHREEEDAOgQxjYUBsaW5uZXQu b2cwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4ICAQBwVm4ODxvvF5GU qrIpPA9IF1JY2jIwgK9E3tGNmoULAUKPyx4hqHpma/h88c8ZIDZ1/CPfnIgC4doE htSdBlErZ9aqj3ZRfhVeVoeHdEHp+xC+qHxAVeFgaSm6sa6NM2Obj1h+YECw+YeO Vm826GT3/Pw40BI5U0UmIbeIivf+i3zGttQruo/JmE2XM+gOCjeKu1v4T189DcAm Dlrc24K06CMwI/ZpTuexEWtWC5W3ASaxO14Liq8iDgd2x1y61zlyEYCITkXYWwos wmlrbIc77NfIzO/fFgy+bOaJCP7R4Uz5L5zdqbmqdvhgeREJJTNX2CDVxDvaDVy2 bJQh8NMnPIAfP5kBJ9Ps6o646HwLwzD4LNPsA10uOBrfaxImT7S+vDaD5y0M0jz9 Tkxj/ry6UB78CNeRyl9SBmM+lCFAISxlZJt6VR85EVxD50PI5DjeK+xYAd8CKimr v5vbycDQhFnd7dztIyAVOcTm/77PpYVqc1TJxPBKPPa3p/ex6H83lD9kKgip1smQ G65x4v9jISrTpL8Cd4ERcuJmVBNVwCaKJxS5xjzhNs76gW3LeG0uxYADFMtmK2s3 H2XagAOn+pfPFUOA6CA+YaZzWcv0qL9PrRgoW4safcsCGAHxkop/9Ue1PvWMPGWc kmnUshRcY8xjRvacwBQwu5YHc/4DDA== -END CERTIFICATE- 0:d=0 hl=4 l=1794 cons: SEQUENCE 4:d=1 hl=4 l=1258 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 9 prim: INTEGER :FE615D033A97727E 24:d=2 hl=2 l= 13 cons: SEQUENCE 26:d=3 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption 37:d=3 hl=2 l= 0 prim: NULL 39:d=2 hl=3 l= 137 cons: SEQUENCE 42:d=3 hl=2 l= 11 cons: SET 44:d=4 hl=2 l= 9 cons: SEQUENCE 46:d=5 hl=2 l= 3 prim: OBJECT:countryName 51:d=5 hl=2 l= 2 prim: PRINTABLESTRING :GB 55:d=3 hl=2 l= 15 cons: SET 57:d=4 hl=2 l= 13 cons: SEQUENCE 59:d=5 hl=2 l= 3 prim: OBJECT:localityName 64:d=5 hl=2 l= 6 prim: PRINTABLESTRING :London 72:d=3 hl=2 l= 47 cons: SET 74:d=4 hl=2 l= 45 cons: SEQUENCE
Re: ld.so.1
On Mon, Feb 27, 2006 at 07:24:56AM -0800, John Doe wrote: ld.so.1: /usr/local/ssl/bin/openssl: fatal: libssl.so.0.9.7: open failed: No such file or directory I don't understand 'cause openssl is correctly installed and my $PATH and $LD-LIBRARY_PATH seem to be correct. LD_LIBRARY_PATH is a bit of a frig, which is best avoided. Read 'man crle' to see the way to add /usr/local/ssl/lib to your permanent library search path under Solaris. I'm not sure if Solaris has ldd, but this can be useful for troubleshooting too: try ldd /usr/local/ssl/bin/openssl It might show you that libssl in turn depends on some other library which it can't find. Regards, Brian. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Installing a certificate chain
On Mon, Feb 27, 2006, Brian Candler wrote: On Mon, Feb 27, 2006 at 01:41:33PM +0100, Dr. Stephen Henson wrote: Since you didn't include the root CA it isn't possible to say why it isn't excluded. I notice the small serial numbers in the certificates and some invalid extensions in there. I'd suggest using the CA.pl script (if you use OpenSSL 0.9.8 get it from a recent snapshot: the included one is buggy) instead. The root certificate is attached below. I also tried appending this to my server.example.com-cert.pem (so there were three certificates in all), but that didn't make a difference. Have you tried placing the sub CA in /etc/ssl/certs and running c_rehash on that directory? Is it correct of me simply to concatenate the server certificate together with the sub-CA certificate and the root certificate? Or should TinyCA have created a certificate which incorporates the whole chain itself? Or does the application use some other mechanism to assemble the chain from the constituent certificates? I'm afraid I'm not sufficiently PKCS#7-savvy to know what a real certificate at the bottom of a chain should look like. It needs to have the whole chain visible somehow. Placing the subCA and root CA in the trusted directory is one way. Concatenating them into a single file and pointing to that using -CAfile is another. 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: Installing a certificate chain
On Mon, Feb 27, 2006 at 08:05:59PM +0100, Dr. Stephen Henson wrote: On Mon, Feb 27, 2006, Brian Candler wrote: On Mon, Feb 27, 2006 at 01:41:33PM +0100, Dr. Stephen Henson wrote: Since you didn't include the root CA it isn't possible to say why it isn't excluded. I notice the small serial numbers in the certificates and some invalid extensions in there. I'd suggest using the CA.pl script (if you use OpenSSL 0.9.8 get it from a recent snapshot: the included one is buggy) instead. The root certificate is attached below. I also tried appending this to my server.example.com-cert.pem (so there were three certificates in all), but that didn't make a difference. Have you tried placing the sub CA in /etc/ssl/certs and running c_rehash on that directory? I hadn't, because I thought that would invalidate what I'm trying to do. Clearly, if I distribute the sub-CA's certificate to all the clients, then they will be able to validate it anyway. But I hadn't thought that perhaps the *server* side still needs to be able to pick up those certificates from there... [Test] Yep, if I do that, the server does indeed hand out the chain. Is it correct of me simply to concatenate the server certificate together with the sub-CA certificate and the root certificate? Or should TinyCA have created a certificate which incorporates the whole chain itself? Or does the application use some other mechanism to assemble the chain from the constituent certificates? I'm afraid I'm not sufficiently PKCS#7-savvy to know what a real certificate at the bottom of a chain should look like. It needs to have the whole chain visible somehow. Placing the subCA and root CA in the trusted directory is one way. Concatenating them into a single file and pointing to that using -CAfile is another. Ah. I had just used -cert ../server.example.com-cert.pem (where this file contains all the certificates). So now I've added -CAfile as well, pointing to the same file: #!/bin/sh cd content openssl s_server -cert ../server.example.com-cert.pem \ -CAfile ../server.example.com-cert.pem \ -key ../server.example.com-key.pem \ -WWW And it works. I've removed the sub-CA certificate and its symlink from /etc/ssl/certs, but the client can still verify the chain: $ openssl s_client -connect localhost:4433 -showcerts -CApath /etc/ssl/certs CONNECTED(0003) depth=2 /C=GB/L=London/O=Candler Insecure Certificate Authority/CN=root.ca.linnet.org/[EMAIL PROTECTED] verify return:1 depth=1 /C=GB/L=London/O=Candler Insecure Certificate Authority/CN=sub.ca.linnet.org/[EMAIL PROTECTED] verify return:1 depth=0 /C=GB/L=London/O=Test server certificate/CN=server.example.com verify return:1 --- Certificate chain 0 s:/C=GB/L=London/O=Test server certificate/CN=server.example.com i:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=sub.ca.linnet.org/[EMAIL PROTECTED] ... 1 s:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=sub.ca.linnet.org/[EMAIL PROTECTED] i:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=root.ca.linnet.org/[EMAIL PROTECTED] ... 2 s:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=root.ca.linnet.org/[EMAIL PROTECTED] i:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=root.ca.linnet.org/[EMAIL PROTECTED] ... Verify return code: 0 (ok) That's great. Many thanks for pointing me in the right direction on this one. Regards, Brian. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Installing a certificate chain
On Mon, Feb 27, 2006 at 07:36:16PM +, Brian Candler wrote: Ah. I had just used -cert ../server.example.com-cert.pem (where this file contains all the certificates). So now I've added -CAfile as well, pointing to the same file: #!/bin/sh cd content openssl s_server -cert ../server.example.com-cert.pem \ -CAfile ../server.example.com-cert.pem \ -key ../server.example.com-key.pem \ -WWW And it works. I've removed the sub-CA certificate and its symlink from /etc/ssl/certs, but the client can still verify the chain: As a follow-up for the benefit of the list archive: to get this to work in Apache+mod_ssl I just had to uncomment SSLCertificateChainFile /usr/local/etc/apache/ssl.crt/ca.crt from httpd.conf, and point it at a file containing the sub-CA's certificate (signed by the root CA) and the root CA's own self-signed certificate. Regards, Brian. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
