Re: issue with p12 creation and network solutions EV SSL
On Monday 25 Apr 2011 20:07:03 James Chase wrote: I simplified the issue a bit in order to try and understand what is going on here and found that the SSL certificate that Network Solutions is providing, along with the intermediate chain file cannot be verified by newer installs of Firefox. Hi James. That seems unlikely. Try browsing to NetSol's own EV site (https://www.networksolutions.com) in FF4. I see the EV green bar and no browser warnings. Could you post the top part of the output from openssl s_client -connect yourdomain:yourport ? Then we can compare it with... $ openssl s_client -connect www.networksolutions.com:443 CONNECTED(0003) depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/serialNumber=3713002/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/C=US/ST=VA/L=Herndon/O=Network Solutions, LLC/OU=Technology Services/OU=Secure Link EV SSL/CN=www.networksolutions.com i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV Server CA 1 s:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV Server CA i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority 2 s:/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root --- It doesn't have anything to do with the p12 file I am creating (I loaded up the network solutions files in apache and tested). Who would be at fault here? Am I still doing something wrong, or is this Mozilla's fault for not including a needed root ca file? It seems the missing link is the AddTrustExternalCARoot certificate. I tried adding the AddTrustExternalCARoot cert to the top of my certificate chain, but this causes apache to break, and then not start complaining of [error] Failed to configure CA certificate chain!. I used a chain file that I have used in previous years, and that did allow apache to start but I still cannot verify with Firefox. Then I tried using last years (and soon expiring) certificate for my site and that works FINE. So ... Network Solutions screwed something up when issuing my certificate (this is the second one I have had re-issued) or am I doing something wrong. I have no idea what that could be at this point -- I have never had so much trouble with an SSL certificate and am not an expert by any means. Anyone have any thoughts? I called NS earlier in this process and they said not our problem but perhaps I will try again. On Mon, Apr 25, 2011 at 11:01 AM, James Chase chase1...@gmail.com wrote: I did run the verification, and didn't have an issue there. Still am not able to figure out how to correctly create this as the only way the p12 compiles is by dropping the -chain command but that creates ssl verifications warnings in Firefox web browsers. openssl req -verify -in www.example.com.csr -key www.example.com.key verify OK -BEGIN CERTIFICATE REQUEST- CERTIFICATE DATA HERE -END CERTIFICATE REQUEST- On Sat, Apr 23, 2011 at 4:41 PM, James Chase chase1...@gmail.com wrote: I am using the same system -- I have tried with last years chain file as well. The only thing that would be different to my knowledge are possibly the version of openssl and the renewed crt file if it possibly requires new CA's (I did use their most current certificates before I tried using my old cafile). openssl verify never returns, I'm not sure what the syntax I am shooting for there is. When i try without using the -chain command then it compiles the p12 and it does seem to load in Chrome and IE ,but in FF3 I get: secure.example.com uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) And in FF4 I get: store.innertraditions.com uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer) I have always used the -chain and -CAfile options together when creating p12's. On Sat, Apr 23, 2011 at 12:32 PM, Crypto Sal crypto@gmail.comwrote: On 04/21/2011 06:51 PM, James Chase wrote: I have done this multiple years in a row with the exact same process but now I get the following error when I try to create my SSL: openssl pkcs12 -export -chain -CAfile cachain.crt -out my.domain.com.p12 -inkey my.domain.com.key -in MY.DOMAIN.COM.crt Error unable to get local issuer certificate getting chain. I concatenated
Re: PKCS12 - Why Encrypted?
Hi, I am no expert on the matter, but on my humble opinion, I think you can rely on this book because most of its content is about fundamental concepts, not implementation details ( padding, message encoding, ... ) for which you can find updates on RSA Labs PKCS http://www.rsa.com/rsalabs/node.asp?id=2124 or other web sites. Michel Le 21/04/2011 16:09, Patrick Rutkowski a écrit : Wow, awesome. I just read the foreword and the preface before getting to work. They're very well written, and now I'm excited for the coming chapters for sure :-) I'll probably read it over the coming week or two. But I'm mildly worried about the date the book was written, which was 1996; and though it was updated in 2001, that was still a long time ago now. I wonder to what degree the material will be outdated, or to what degree modern day material will be completely missing. -Patrick On Apr 21, 2011, at 8:55 AM, Michel (PAYBOX) wrote: I believe this [freely available] book should interest you : Handbook of Applied Cryptography http://www.cacr.math.uwaterloo.ca/hac/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
slow https conenctions
Hi, I've come to this list in search of help with slow https conenctions (via the subversion, apache and finally mod_ssl lits). There is a 15 second ish delay whenever a client connects using https, i've tracked this down in the logs to the snippet shown. -- snip -- [Thu Apr 21 11:21:49 2011] [info] Connection: Client IP: 127.0.0.1, Protocol: TLSv1, Cipher: DHE-RSA-AES256-SHA (256/256 bits) [Thu Apr 21 11:22:07 2011] [debug] ssl_engine_io.c(1889): OpenSSL: read 5/5 bytes from BIO#c99cd0 [mem: ca14b0] (BIO dump follows) -- end -- But i really dont know how to get any further. This machine is pretty powerful, quad 3ghz xeon etc. Full log from startup bellow,.. any help / ideas much appreciated. [Thu Apr 21 11:21:16 2011] [info] Init: Initializing (virtual) servers for SSL [Thu Apr 21 11:21:16 2011] [info] Configuring server for SSL protocol [Thu Apr 21 11:21:16 2011] [debug] ssl_engine_init.c(465): Creating new SSL context (protocols: SSLv3, TLSv1) [Thu Apr 21 11:21:16 2011] [debug] ssl_engine_init.c(661): Configuring permitted SSL ciphers [ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM] [Thu Apr 21 11:21:16 2011] [debug] ssl_engine_init.c(420): Configuring TLS extension handling [Thu Apr 21 11:21:16 2011] [debug] ssl_engine_init.c(792): Configuring RSA server certificate [Thu Apr 21 11:21:16 2011] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?) [Thu Apr 21 11:21:16 2011] [debug] ssl_engine_init.c(831): Configuring RSA server private key [Thu Apr 21 11:21:16 2011] [info] mod_ssl/2.2.17 compiled against Server: Apache/2.2.17, Library: OpenSSL/0.9.8r [Thu Apr 21 11:21:16 2011] [notice] Child 3268: Child process is running [Thu Apr 21 11:21:16 2011] [debug] mpm_winnt.c(408): Child 3268: Retrieved our scoreboard from the parent. [Thu Apr 21 11:21:16 2011] [info] Parent: Duplicating socket 276 and sending it to child process 3268 [Thu Apr 21 11:21:16 2011] [debug] mpm_winnt.c(605): Parent: Sent 1 listeners to child 3268 [Thu Apr 21 11:21:16 2011] [debug] mpm_winnt.c(564): Child 3268: retrieved 1 listeners from parent [Thu Apr 21 11:21:16 2011] [notice] Child 3268: Acquired the start mutex. [Thu Apr 21 11:21:16 2011] [notice] Child 3268: Starting 64 worker threads. [Thu Apr 21 11:21:16 2011] [notice] Child 3268: Listening on port 443. [Thu Apr 21 11:21:49 2011] [info] [client 127.0.0.1] Connection to child 0 established (server pl161.serck-uk.internal:443) [Thu Apr 21 11:21:49 2011] [info] Seeding PRNG with 144 bytes of entropy [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_kernel.c(1866): OpenSSL: Handshake: start [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_kernel.c(1874): OpenSSL: Loop: before/accept initialization [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1889): OpenSSL: read 11/11 bytes from BIO#c99cd0 [mem: ca14b0] (BIO dump follows) [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1822): +-+ [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | : 16 03 01 00 df 01 00 00-db 03 01 ... | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1867): +-+ [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1889): OpenSSL: read 217/217 bytes from BIO#c99cd0 [mem: ca14bb] (BIO dump follows) [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1822): +-+ [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | : 4d b0 05 3d 24 b5 92 40-cb c0 c7 84 df 99 b8 2f M..=$..@.../ | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | 0010: 1c 49 78 19 74 74 b3 0d-3f 89 d3 3d 7a 90 7c 50 .Ix.tt..?..=z.|P | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | 0020: 00 00 5c c0 14 c0 0a 00-39 00 38 00 88 00 87 c0 ..\\.9.8. | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | 0030: 0f c0 05 00 35 00 84 c0-12 c0 08 00 16 00 13 c0 5... | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | 0040: 0d c0 03 00 0a c0 13 c0-09 00 33 00 32 00 9a 00 ..3.2... | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | 0050: 99 00 45 00 44 c0 0e c0-04 00 2f 00 96 00 41 00 ..E.D./...A. | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | 0060: 07 c0 11 c0 07 c0 0c c0-02 00 05 00 04 00 15 00 | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | 0070: 12 00 09 00 14 00 11 00-08 00 06 00 03 00 ff 01 | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | 0080: 00 00 56 00 00 00 0e 00-0c 00 00 09 6c 6f 63 61 ..V.loca | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | 0090: 6c 68 6f 73 74 00 0b 00-04 03 00 01 02 00 0a 00 lhost... | [Thu Apr 21 11:21:49 2011] [debug] ssl_engine_io.c(1861): | 00a0: 34 00 32 00 01 00 02 00-03 00 04 00 05 00
Re: issue with p12 creation and network solutions EV SSL
Well my results are quite different, and I guess point to my p12 not being correctly created. Strangely, the p12 I am running this test on works in production and doesn't produce a warning (I re-created last years certificate as a new p12 using the same process I am trying with this years). I also tried running this on my test apache site, where I am just using the plain old certificate, key and network solutions supplied chain file -- and the openssl s_client command returns better output but I still get a warning! [me@myserver ~]$ openssl s_client -connect www.example.com:443 CONNECTED(0003) depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1.3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1.3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=27:certificate not trusted verify return:1 depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1.3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1.3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd/OU=Book Sales/OU=Secure Link EV SSL/CN=www.example.com i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV SSL CA --- On Mon, Apr 25, 2011 at 6:16 PM, Rob Stradling rob.stradl...@comodo.comwrote: On Monday 25 Apr 2011 20:07:03 James Chase wrote: I simplified the issue a bit in order to try and understand what is going on here and found that the SSL certificate that Network Solutions is providing, along with the intermediate chain file cannot be verified by newer installs of Firefox. Hi James. That seems unlikely. Try browsing to NetSol's own EV site (https://www.networksolutions.com) in FF4. I see the EV green bar and no browser warnings. Could you post the top part of the output from openssl s_client -connect yourdomain:yourport ? Then we can compare it with... $ openssl s_client -connect www.networksolutions.com:443 CONNECTED(0003) depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/serialNumber=3713002/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/C=US/ST=VA/L=Herndon/O=Network Solutions, LLC/OU=Technology Services/OU=Secure Link EV SSL/CN=www.networksolutions.com i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV Server CA 1 s:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV Server CA i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority 2 s:/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root --- It doesn't have anything to do with the p12 file I am creating (I loaded up the network solutions files in apache and tested). Who would be at fault here? Am I still doing something wrong, or is this Mozilla's fault for not including a needed root ca file? It seems the missing link is the AddTrustExternalCARoot certificate. I tried adding the AddTrustExternalCARoot cert to the top of my certificate chain, but this causes apache to break, and then not start complaining of [error] Failed to configure CA certificate chain!. I used a chain file that I have used in previous years, and that did allow apache to start but I still cannot verify with Firefox. Then I tried using last years (and soon expiring) certificate for my site and that works FINE. So ... Network Solutions screwed something up when issuing my certificate (this is the second one I have had re-issued) or am I doing something wrong. I have no idea what that could be at this point -- I have never had so much trouble with an SSL certificate and am not an expert by any means. Anyone have any thoughts? I called NS earlier in this process and they said not our problem but perhaps I will try
RE: Combining MD5 and SHA-1 to reduce collision probability
Hi, thank you for clarification, Dave! * Dave Thompson Friday, April 22, 2011 12:34 AM: so among 2^n+1 different messages, at least two of them must have the same 2^n bit hash (actually half because of birthday attack). To be exact: for an n-bit or 2^n-value hash, with 2^n + 1 messages you are certain to have a collision. Because of the birthday paradox, with about 2^(n/2) random messages you are *likely* to have a collision. This is just a fact of nature; attack is used for actions by an intelligent adversary. Just for sake of completeness I think it could be added (for the assumed intention of the OP's question) that there is no guarantee that two different messages have two different hashes, because the first two tested messages could have the same hash (of course with very very low probability). Could it even be possible that two messages shorter than n bit accidently have the same (strong n-bit) hash? Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: issue with p12 creation and network solutions EV SSL
Someone suggested it would be helpful to post the chain file and the site's public certificate to the list. If it is helpful, here is the site cert (and below that their supplied chain file) -BEGIN CERTIFICATE- MIIF+TCCBOGgAwIBAgIRAOQNdqGKinmztM0sRh0SkkowDQYJKoZIhvcNAQEFBQAw WTELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE5ldHdvcmsgU29sdXRpb25zIEwuTC5D LjEnMCUGA1UEAxMeTmV0d29yayBTb2x1dGlvbnMgRVYgU2VydmVyIENBMB4XDTEx MDQxMzAwMDAwMFoXDTEyMDQyOTIzNTk1OVowggE0MRIwEAYDVQQFEwlWLTU4NTA4 LTAxEzARBgsrBgEEAYI3PAIBAxMCVVMxEzARBgsrBgEEAYI3PAIBAhMCVlQxHTAb BgNVBA8TFFByaXZhdGUgT3JnYW5pemF0aW9uMQswCQYDVQQGEwJVUzEOMAwGA1UE ERMFMDU3NjcxCzAJBgNVBAgTAlZUMRIwEAYDVQQHEwlSb2NoZXN0ZXIxFDASBgNV BAkTC09uZSBQYXJrIFN0MSswKQYDVQQKEyJJbm5lciBUcmFkaXRpb25zIEludGVy bmF0aW9uYWwgTHRkMRMwEQYDVQQLEwpCb29rIFNhbGVzMRswGQYDVQQLExJTZWN1 cmUgTGluayBFViBTU0wxIjAgBgNVBAMTGXN0b3JlLmlubmVydHJhZGl0aW9ucy5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDF66W6jHcsm5vPLFWt 8Vk+CSUINYZCibR8xMMYcgj1OCXArNJTWYJIPVFTcdMY97U0OmOGB/w44zzywKOz Yd3756/S5QYfokwkZ6A+dibbdOwzQX/qP2yGMD/zRPP8bALbAeiIEu5gnZkyqZVy UITMY7OnyV/VK0bP15o4/WMcFVMq7J2pZoY/7e3//Bhzd2yj4UtL/MQ+WVBq2Mh9 1XC5o+db2J4IP7HWEd14h5buRBlS+gdR+aPnQRfUgD8msOcrIHMuPo+cK0swGjLl lvEsvaMHsIdwTG0mnesLxMlYo1gbC0v/zJNbKmTOkcWU26V4rM9/3to+82wd2u2V XkAXAgMBAAGjggHdMIIB2TAfBgNVHSMEGDAWgBSKNeQ1OrwRoZ779U80ZtVLrExi aDAdBgNVHQ4EFgQUgUqFpUzoDl9o44trs/oaV2Lv0+swDgYDVR0PAQH/BAQDAgWg MAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMG4G A1UdIARnMGUwYwYMKwYBBAGGDgECAQgBMFMwUQYIKwYBBQUHAgEWRWh0dHA6Ly93 d3cubmV0d29ya3NvbHV0aW9ucy5jb20vbGVnYWwvU1NMLWxlZ2FsLXJlcG9zaXRv cnktZXYtY3BzLmpzcDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLm5ldHNv bHNzbC5jb20vTmV0d29ya1NvbHV0aW9uc0VWU2VydmVyQ0EuY3JsMHoGCCsGAQUF BwEBBG4wbDBDBggrBgEFBQcwAoY3aHR0cDovL3d3dy5uZXRzb2xzc2wuY29tL05l dHdvcmtTb2x1dGlvbnNFVlNlcnZlckNBLmNydDAlBggrBgEFBQcwAYYZaHR0cDov L29jc3AubmV0c29sc3NsLmNvbTAkBgNVHREEHTAbghlzdG9yZS5pbm5lcnRyYWRp dGlvbnMuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQBusLaUTTTcvQl0up5zKYsfNPoS YXRsSC0tOEBdKBPvCDHmJlpNkjE/IPYTsRT/oxnWL3QORWKfClz9ygIy9L6AJb8w BDaopoHEt7oNIPjjyp3ArOyjkGOZTllPJMyv/SznKQVQLmsO8uMEyV5AXIHyW8nm OC0jMS28dELdFXrBOIPNUGw/e2lsRQbfoaMQY/vuSbLv1nlL28K3vXj3Jn/rSXaa Zc25pUZPQTGObF5is9CGBPnBW1zrtkj1jV+J05eRb5Qqc3zUMvlgUg58CNZjWraS pjyc7DtAqYyE//iPI+JBOSGBlc3Q6Qedxs3O/O9TrDpAyVQAffL5f1EgeQey -END CERTIFICATE- And the chain file -BEGIN CERTIFICATE- MIIEPDCCAySgAwIBAgIQSEus8arH1xND0aJ0NUmXJTANBgkqhkiG9w0BAQUFADBv MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF eHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEwNDgzOFow gZcxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMR8wHQYDVQQDExZVVE4tVVNFUkZpcnN0 LUhhcmR3YXJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsffDOD+0 qH/POYJRZ9Btn9L/WPPnnyvsDYlUmbk4mRb34CF5SMK7YXQSlh08anLVPBBnOjnt KxPNZuuVCTOkbJex6MbswXV5nEZejavQav25KlUXEFSzGfCa9vGxXbanbfvgcRdr ooj7AN/+GjF3DJoBerEy4ysBBzhuw6VeI7xFm3tQwckwj9vlK3rTW/szQB6g1ZgX vIuHw4nTXaCOsqqq9o5piAbF+okh8widaS4JM5spDUYPjMxJNLBpUb35Bs1orWZM vD6sYb0KiA7I3z3ufARMnQpea5HW7sftKI2rTYeJc9BupNAeFosU4XZEA39jrOTN SZzFkvSrMqFIWwIDAQABo4GqMIGnMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8D veAky1QaMB0GA1UdDgQWBBShcl8mGyiYQ5VdBzfVhZadS9LDRTAOBgNVHQ8BAf8E BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8v Y3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBADzse+Cuow6WbTDXhcbSaFtFWoKmNA+wyZIjXhFtCBGy dAkjOjUlc1heyrl8KPpH7PmgA1hQtlPvjNs55Gfp2MooRtSn4PU4dfjny1y/HRE8 akCbLURW0/f/BSgyDBXIZEWT6CEkjy3aeoR7T8/NsiV8dxDTlNEEkaglHAkiD31E NREU768A/l7qX46w2ZJZuvwTlqAYAVbO2vYoC7Gv3VxPXLLzj1pxz+0YrWOIHY6V 9+qV5x+tkLiECEeFfyIvGh1IMNZMCNg3GWcyK+tc0LL8blefBDVekAB+EcfeEyrN pG1FJseIVqDwavfY5/wnfmcI0L36tsNhAgFlubgvz1o= -END CERTIFICATE- -BEGIN CERTIFICATE- MIIEsTCCA5mgAwIBAgIQVGi1eXSfYP/+kzbRw2KvLjANBgkqhkiG9w0BAQUFADCB lzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2Ug Q2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3Qt SGFyZHdhcmUwHhcNMDYxMjAxMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjBiMQswCQYD VQQGEwJVUzEhMB8GA1UEChMYTmV0d29yayBTb2x1dGlvbnMgTC5MLkMuMTAwLgYD VQQDEydOZXR3b3JrIFNvbHV0aW9ucyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDkvH6SMG3G2I4rC7xGzuAnlt7e +foS0zwzc7MEL7xxjOWftiJgPl9dzgn/ggwbmlFQGiaJ3dVhXRncEg8tCqJDXRfQ NJIg6nPPOCwGJgl6cvf6UDL4wpPTaaIjzkGxzOTVHzbRijr4jGPiFFlp7Q3Tf2vo uAPlT2rlmGNpSAW+Lv8ztumXWWn4Zxmuk2GWRBXTcrA/vGp97Eh/jcOrqnErU2lB UzS1sLnFBgrEsEX1QV1uiUV7PTsmjHTC5dLRfbIR1PtYMiKagMnc/Qzpf14Dl847 ABSHJ3A4qY5usyd2mFHgBeMhqxrVhSI8KbWaFsWAqPS7azCPL0YCorEMIuDTAgMB AAGjggErMIIBJzAfBgNVHSMEGDAWgBShcl8mGyiYQ5VdBzfVhZadS9LDRTAdBgNV HQ4EFgQUITDJ+wDXTpjah6oq0KcusUAxp0wwDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wfgYDVR0gBHcwdTAOBgwrBgEEAYYOAQIBAwEwYwYMKwYBBAGG
Re: issue with p12 creation and network solutions EV SSL
Hi, Your SSL certificate has an Authority Key Identifier extension which has a value of 8a 35 e4 35 3a bc 11 a1 9e fb f5 4f 34 66 d5 4b ac 4c 62 68. This indicates that it has NOT been issued by the Network Solutions EV Server CA certificate that is present in the chain file you posted: this one has a Subject Key Identifier extension equal to b6 4e 85 9d 84 1f 1b 1d d4 52 89 4e 07 96 2d f9 de f1 8f cc. Actually, your SSL certificate has been signed by an updated Network Solutions EV Server CA certificate which was reissued on 11/26/2010 and that has a Subject Key Identifier extension equal to the Authority Key Identifier extension of your SSL certificate. And this update CA certificate is in turn reissued by an updated Network Solutions Certificate Authority certificate that was issued on 10/10/2010. So, the chain file you are using is wrong and you should use the updated one. I have reconstructed the correct one for you. Here it is : == -BEGIN CERTIFICATE- MIIE8DCCA9igAwIBAgIQeqyiHVOdFFQRPARe2DX46jANBgkqhkiG9w0BAQUFADBi MQswCQYDVQQGEwJVUzEhMB8GA1UEChMYTmV0d29yayBTb2x1dGlvbnMgTC5MLkMu MTAwLgYDVQQDEydOZXR3b3JrIFNvbHV0aW9ucyBDZXJ0aWZpY2F0ZSBBdXRob3Jp dHkwHhcNMTAxMTI2MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjBZMQswCQYDVQQGEwJV UzEhMB8GA1UEChMYTmV0d29yayBTb2x1dGlvbnMgTC5MLkMuMScwJQYDVQQDEx5O ZXR3b3JrIFNvbHV0aW9ucyBFViBTZXJ2ZXIgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDQNVzi55UamI/YT9bV3H5cgr+fzEv6PEqBvNrFp+mtmiaP 3BksYxI+Vt915kis40eQf18I8aOA0dDNJc1Z860uw+sGCf45JDmioezExJrXoAhV /sjFZC785waIlcE+MVpV8B2YBJS0f17ckKmhhceqErmH0aNxEQJsfpvJOevstVgn i6OYEaCrg/skMACuAlf+gOLKj0hgYznbr5Z0g7s7bO+zM8am3DHp+byqtx7I9H9Y aXLuWo82Cv4yERw0PXmIadfaMHM2aOH8EChB7mx/iAg+k3djiqrIqHvLNHAEoWw7 bUgn1D0Xugyj4Ypaqx/hcibDjiYyKNlySQ7u5XVDAgMBAAGjggGpMIIBpTAfBgNV HSMEGDAWgBQhMMn7ANdOmNqHqirQpy6xQDGnTDAdBgNVHQ4EFgQUijXkNTq8EaGe +/VPNGbVS6xMYmgwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw ZgYDVR0gBF8wXTBbBgRVHSAAMFMwUQYIKwYBBQUHAgEWRWh0dHA6Ly93d3cubmV0 d29ya3NvbHV0aW9ucy5jb20vbGVnYWwvU1NMLWxlZ2FsLXJlcG9zaXRvcnktZXYt Y3BzLmpzcDBSBgNVHR8ESzBJMEegRaBDhkFodHRwOi8vY3JsLm5ldHNvbHNzbC5j b20vTmV0d29ya1NvbHV0aW9uc0NlcnRpZmljYXRlQXV0aG9yaXR5LmNybDCBggYI KwYBBQUHAQEEdjB0MEsGCCsGAQUFBzAChj9odHRwOi8vY3J0LnVzZXJ0cnVzdC5j b20vTmV0d29ya1NvbHV0aW9uc0FkZFRydXN0RVZTZXJ2ZXJDQS5jcnQwJQYIKwYB BQUHMAGGGWh0dHA6Ly9vY3NwLm5ldHNvbHNzbC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBADtBp7D2JBjlyHcOqAW86EhXzoEj/xeYaAGJxWmewqtFq3NMJclvdwVyEOue XnIM99N/vGMcsOVMRAGZH+He/HDjd+XY6aktld0Fz27Fx9ncL9FAfo/pR4uH2YEz pStMuS6k4ajMHGvPBDZaqqSgdDAbUSDHYblQGOS/K8P4pvqMiRYhmadaQ5kDbXTg i+qweI4gAdIpsozxeyoIsmJqMDZdXKc7Su73BzJHLfaIYgypJOBw36KmQgx7fSgF 1wtt5YT78MmIs6nZAcOcmNzLg0fs+dGeoFxdpzFSuF2wkQNvHmrv4zYC4xpdMUqQ FhvXMwUw+wCqKOtfDecUViddfLQ= -END CERTIFICATE- -BEGIN CERTIFICATE- MIIFLjCCBBagAwIBAgIQXclynOqKeVoX7tu/zCghSzANBgkqhkiG9w0BAQUFADBv MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF eHRlcm5hbCBDQSBSb290MB4XDTEwMTAxMDEwMTAxMFoXDTIwMDUzMDEwNDgzOFow YjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE5ldHdvcmsgU29sdXRpb25zIEwuTC5D LjEwMC4GA1UEAxMnTmV0d29yayBTb2x1dGlvbnMgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5Lx+kjBtxtiOKwu8 Rs7gJ5be3vn6EtM8M3OzBC+8cYzln7YiYD5fXc4J/4IMG5pRUBomid3VYV0Z3BIP LQqiQ10X0DSSIOpzzzgsBiYJenL3+lAy+MKT02miI85Bsczk1R820Yo6+Ixj4hRZ ae0N039r6LgD5U9q5ZhjaUgFvi7/M7bpl1lp+GcZrpNhlkQV03KwP7xqfexIf43D q6pxK1NpQVM0tbC5xQYKxLBF9UFdbolFez07Jox0wuXS0X2yEdT7WDIimoDJ3P0M 6X9eA5fOOwAUhydwOKmObrMndphR4AXjIasa1YUiPCm1mhbFgKj0u2swjy9GAqKx DCLg0wIDAQABo4IB0TCCAc0wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFCEwyfsA106Y2oeqKtCnLrFAMadMMA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MG4GA1UdIARnMGUwYwYMKwYBBAGGDgECAQgBMFMw UQYIKwYBBQUHAgEWRWh0dHA6Ly93d3cubmV0d29ya3NvbHV0aW9ucy5jb20vbGVn YWwvU1NMLWxlZ2FsLXJlcG9zaXRvcnktZXYtY3BzLmpzcDBEBgNVHR8EPTA7MDmg N6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENB Um9vdC5jcmwwgbMGCCsGAQUFBwEBBIGmMIGjMD8GCCsGAQUFBzAChjNodHRwOi8v Y3J0LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5wN2MwOQYI KwYBBQUHMAKGLWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9BZGRUcnVzdFVUTlNH Q0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAQbJTbI4r8iImYQdMT+qI4AhyNO14VhPNMHy2F058 a4W/3JAbXWAl/rNC49vE/7BLKBxRZn/3CB9cxRLm4cXRjnoW6I1iuYQ/vGdR+AoT H6egK4vifO35cCPFLIq5IQx+SdufcuWdFSLySL814kswfwLYoCx96qE+d/a0wVoV o+fSspKwv1NQSzhdErPCINa9GY/Q9LrE5Dg1OMPbe03AnkTdf8rNd4/lr6S12SYm FeeW+Y2mWbh/YIOKZMaN/ZeWcdpgcIwfTfwx2pUQ7Yahy1ihDqjusinPpIuUl0PC +v/apwI8P+RW99qe6MpAjiuvQ00uqbfh0w4VvAkvbbBFlA== -END CERTIFICATE- -BEGIN CERTIFICATE- MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
Re: issue with p12 creation and network solutions EV SSL
On Tuesday 26 Apr 2011 13:29:00 James Chase wrote: Someone suggested it would be helpful to post the chain file and the site's public certificate to the list. If it is helpful, here is the site cert (and below that their supplied chain file) -BEGIN CERTIFICATE- snip -END CERTIFICATE- Piping that site cert through openssl x509 -noout -issuer gives... issuer= /C=US/O=Network Solutions L.L.C./CN=Network Solutions EV Server CA And the chain file -BEGIN CERTIFICATE- snip -END CERTIFICATE- -BEGIN CERTIFICATE- snip -END CERTIFICATE- -BEGIN CERTIFICATE- snip -END CERTIFICATE- Piping that last CA cert through openssl x509 -noout -subject gives... subject= /C=US/O=Network Solutions L.L.C./CN=Network Solutions EV SSL CA You've got the wrong chain file. I understand that NetSol switched to a new EV Issuing CA a few months ago. Are you definitely using the chain file that they supplied with your latest site cert? On Tue, Apr 26, 2011 at 8:19 AM, James Chase chase1...@gmail.com wrote: Well my results are quite different, and I guess point to my p12 not being correctly created. Strangely, the p12 I am running this test on works in production and doesn't produce a warning (I re-created last years certificate as a new p12 using the same process I am trying with this years). I also tried running this on my test apache site, where I am just using the plain old certificate, key and network solutions supplied chain file -- and the openssl s_client command returns better output but I still get a warning! [me@myserver ~]$ openssl s_client -connect www.example.com:443 CONNECTED(0003) depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=27:certificate not trusted verify return:1 depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd/OU=Book Sales/OU=Secure Link EV SSL/CN=www.example.com i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV SSL CA --- On Mon, Apr 25, 2011 at 6:16 PM, Rob Stradling rob.stradl...@comodo.comwrote: On Monday 25 Apr 2011 20:07:03 James Chase wrote: I simplified the issue a bit in order to try and understand what is going on here and found that the SSL certificate that Network Solutions is providing, along with the intermediate chain file cannot be verified by newer installs of Firefox. Hi James. That seems unlikely. Try browsing to NetSol's own EV site (https://www.networksolutions.com) in FF4. I see the EV green bar and no browser warnings. Could you post the top part of the output from openssl s_client -connect yourdomain:yourport ? Then we can compare it with... $ openssl s_client -connect www.networksolutions.com:443 CONNECTED(0003) depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/serialNumber=3713002/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2 .1.2=Delaware/businessCategory=Private Organization/C=US/ST=VA/L=Herndon/O=Network Solutions, LLC/OU=Technology Services/OU=Secure Link EV SSL/CN=www.networksolutions.com i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV Server CA 1 s:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV Server CA i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority 2 s:/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
Re: issue with p12 creation and network solutions EV SSL
You've got the wrong chain file. I understand that NetSol switched to a new EV Issuing CA a few months ago. Are you definitely using the chain file that they supplied with your latest site cert? I am using the chain file that they suggest downloading which already has the intermediate files concatenated into a file -- but apparently it is wrong. I checked the .crt file that they include with my site certificate and they are the same certs that are in the chain file they have precompiled. I can't believe how much time I have spent on this issue and could the root of the issue be that they are not packaging the right files with my new certificate? wtf Mounir, where did you get those certificates?? The only cert that you used that came with my certificate is the last one, AddTrustExternalCARoot -- the other two are NOT included and are not in NetSol's precompiled chain file. Your chain file works when I test with apache, and I have just created a p12 from those chain files and that works too! Halellujah. But seriously, how did you synthesize that chain file? And how would I be expected to create that on my own?? I spent an hour and a half on the phone with NetSol telling them their was something wrong with their files and they just kept saying it was my fault and they will bill me $120/hour to fix it. On Tue, Apr 26, 2011 at 8:19 AM, James Chase chase1...@gmail.com wrote: Well my results are quite different, and I guess point to my p12 not being correctly created. Strangely, the p12 I am running this test on works in production and doesn't produce a warning (I re-created last years certificate as a new p12 using the same process I am trying with this years). I also tried running this on my test apache site, where I am just using the plain old certificate, key and network solutions supplied chain file -- and the openssl s_client command returns better output but I still get a warning! [me@myserver ~]$ openssl s_client -connect www.example.com:443 CONNECTED(0003) depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=27:certificate not trusted verify return:1 depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd/OU=Book Sales/OU=Secure Link EV SSL/CN=www.example.com i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV SSL CA --- On Mon, Apr 25, 2011 at 6:16 PM, Rob Stradling rob.stradl...@comodo.comwrote: On Monday 25 Apr 2011 20:07:03 James Chase wrote: I simplified the issue a bit in order to try and understand what is going on here and found that the SSL certificate that Network Solutions is providing, along with the intermediate chain file cannot be verified by newer installs of Firefox. Hi James. That seems unlikely. Try browsing to NetSol's own EV site (https://www.networksolutions.com) in FF4. I see the EV green bar and no browser warnings. Could you post the top part of the output from openssl s_client -connect yourdomain:yourport ? Then we can compare it with... $ openssl s_client -connect www.networksolutions.com:443 CONNECTED(0003) depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/serialNumber=3713002/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2 .1.2=Delaware/businessCategory=Private Organization/C=US/ST=VA/L=Herndon/O=Network Solutions, LLC/OU=Technology Services/OU=Secure Link EV SSL/CN=www.networksolutions.com i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV Server CA 1 s:/C=US/O=Network Solutions
Re: slow https conenctions
On 04/26/11 3:06 AM, Matthew Fletcher wrote: I've come to this list in search of help with slow https conenctions (via the subversion, apache and finally mod_ssl lits). There is a 15 second ish delay whenever a client connects using https, 15 seconds sounds to *me* like a DNS related timeout. perhaps the server is doing a reverse lookup on the client? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: issue with p12 creation and network solutions EV SSL
Hi James, I got the the correct certificate chain from my Windows 7 box. Microsoft tends to update its trusted CA certificates store more quickly and regularly than Mozilla or Linux distros: the latest update was last month on March 23rd 2011. It is sad that even Network Solutions guys are not aware of this update...This issue should not have existed at the first place! Good luck, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 4/26/2011 7:07 PM, James Chase wrote: You've got the wrong chain file. I understand that NetSol switched to a new EV Issuing CA a few months ago. Are you definitely using the chain file that they supplied with your latest site cert? I am using the chain file that they suggest downloading which already has the intermediate files concatenated into a file -- but apparently it is wrong. I checked the .crt file that they include with my site certificate and they are the same certs that are in the chain file they have precompiled. I can't believe how much time I have spent on this issue and could the root of the issue be that they are not packaging the right files with my new certificate? wtf Mounir, where did you get those certificates?? The only cert that you used that came with my certificate is the last one, AddTrustExternalCARoot -- the other two are NOT included and are not in NetSol's precompiled chain file. Your chain file works when I test with apache, and I have just created a p12 from those chain files and that works too! Halellujah. But seriously, how did you synthesize that chain file? And how would I be expected to create that on my own?? I spent an hour and a half on the phone with NetSol telling them their was something wrong with their files and they just kept saying it was my fault and they will bill me $120/hour to fix it. On Tue, Apr 26, 2011 at 8:19 AM, James Chase chase1...@gmail.com mailto:chase1...@gmail.com wrote: Well my results are quite different, and I guess point to my p12 not being correctly created. Strangely, the p12 I am running this test on works in production and doesn't produce a warning (I re-created last years certificate as a new p12 using the same process I am trying with this years). I also tried running this on my test apache site, where I am just using the plain old certificate, key and network solutions supplied chain file -- and the openssl s_client command returns better output but I still get a warning! [me@myserver ~]$ openssl s_client -connect www.example.com:443 http://www.example.com:443 CONNECTED(0003) depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15 http://2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15 http://2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=27:certificate not trusted verify return:1 depth=0 /serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15 http://2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/serialNumber=03-11- 1975/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Massachusetts/1 .3.6.1.4.1.311.60.2.1.1=A City/2.5.4.15 http://2.5.4.15=V1.0, Clause 5.(b)/C=US/postalCode=05767/ST=MA/L=A City/streetAddress=One Park St/O=A Company International Ltd/OU=Book Sales/OU=Secure Link EV SSL/CN=www.example.com http://www.example.com i:/C=US/O=Network Solutions L.L.C./CN=Network Solutions EV SSL CA --- On Mon, Apr 25, 2011 at 6:16 PM, Rob Stradling rob.stradl...@comodo.com mailto:rob.stradl...@comodo.comwrote: On Monday 25 Apr 2011 20:07:03 James Chase wrote: I simplified the issue a bit in order to try and understand what is going on here and found that the SSL certificate that Network Solutions is providing, along with the intermediate chain file cannot be verified by newer installs of Firefox. Hi James. That seems
Re: issue with p12 creation and network solutions EV SSL
I got the the correct certificate chain from my Windows 7 box. Microsoft tends to update its trusted CA certificates store more quickly and regularly than Mozilla or Linux distros: the latest update was last month on March 23rd 2011. It is sad that even Network Solutions guys are not aware of this update...This issue should not have existed at the first place! Good luck, I really can't thank you enough. I wouldn't have known how to follow the chain and find which files were needed to build up their intermediate certificate chain (though thanks to your notes, I do now). I still can't believe how badly Network Solutions screwed this situation up and the extremely poor level of support I received from them. They should have been able to figure out I was using the wrong chain files -- they supposedly ran scripts on my ssl certificate when I called them. Hope someone else can benefit from being aware of this issue. Thanks for all your help guys!
Multithreaded server example of OpenSSL
Hi, I need a multithreaded OpenSSL server which can handle multiple clients. Is there full example of such a server? Regards Peter
Re: slow https conenctions
Hi, On 04/26/11 3:06 AM, Matthew Fletcher wrote: I've come to this list in search of help with slow https conenctions (via the subversion, apache and finally mod_ssl lits). There is a 15 second ish delay whenever a client connects using https, 15 seconds sounds to *me* like a DNS related timeout. perhaps the server is doing a reverse lookup on the client? ...or is getting a record, trying to connect to that IPv6 addressand failing, then falling back to IPv4 alan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PKCS12 - Why Encrypted?
On Tue, Apr 26, 2011 at 5:49 AM, Michel (PAYBOX) msa...@paybox.com wrote: Hi, I am no expert on the matter, but on my humble opinion, I think you can rely on this book because most of its content is about fundamental concepts, not implementation details ( padding, message encoding, ... ) for which you can find updates on RSA Labs PKCS http://www.rsa.com/rsalabs/node.asp?id=2124 or other web sites. The HAC is a bit dated. If I recall correctly, 9.6.5 (Integrity Codes) is no longer applicable - use an authenticated encryption mode instead. Also, be careful of RSA Data Securities reading. For example, the output of RC4/ARC4 is biased, but the topic does not warn a user who might be trying to generate a pseudo random stream (http://www.rsa.com/rsalabs/node.asp?id=2250). RSA does discuss the key scheduling weaknesses, though (http://www.rsa.com/rsalabs/node.asp?id=2009). Le 21/04/2011 16:09, Patrick Rutkowski a écrit : Wow, awesome. I just read the foreword and the preface before getting to work. They're very well written, and now I'm excited for the coming chapters for sure :-) I'll probably read it over the coming week or two. But I'm mildly worried about the date the book was written, which was 1996; and though it was updated in 2001, that was still a long time ago now. I wonder to what degree the material will be outdated, or to what degree modern day material will be completely missing. -Patrick On Apr 21, 2011, at 8:55 AM, Michel (PAYBOX) wrote: I believe this [freely available] book should interest you : Handbook of Applied Cryptography http://www.cacr.math.uwaterloo.ca/hac/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
