Re: PKCS12 - Why Encrypted?

2011-04-26 Thread Jeffrey Walton 
On Tue, Apr 26, 2011 at 5:49 AM, Michel (PAYBOX)  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

Re: slow https conenctions

2011-04-26 Thread Alan Buxey 
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

Multithreaded server example of OpenSSL

2011-04-26 Thread derleader mail 
 
Hi,

 I need a multithreaded OpenSSL server which can handle multiple clients. Is 
there full example of such a server?

Regards
Peter

Re: issue with p12 creation and network solutions EV SSL

2011-04-26 Thread James Chase 
>
>
> 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!

Re: issue with p12 creation and network solutions EV SSL

2011-04-26 Thread Mounir IDRASSI 

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
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

> > 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
mailto:rob.stradl...@comodo.com>>wrote:
> >> 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 intermedi

Re: slow https conenctions

2011-04-26 Thread John R Pierce 

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

2011-04-26 Thread James Chase 
>
>
> 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 
> 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
> wrote:
> > >> 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/busines

Re: issue with p12 creation and network solutions EV SSL

2011-04-26 Thread Rob Stradling 
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-

> -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-

> -END CERTIFICATE-
> -BEGIN CERTIFICATE-

> -END CERTIFICATE-
> -BEGIN CERTIFICATE-

> -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  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 
wrote:
> >> 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
> >> 
>

Re: issue with p12 creation and network solutions EV SSL

2011-04-26 Thread Mounir IDRASSI 

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
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZ

Re: issue with p12 creation and network solutions EV SSL

2011-04-26 Thread James Chase 
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
DgECAQgBMFMwUQYIKwYBBQUHAgEWRWh0dHA6Ly93d3cubmV0d29ya3NvbHV

RE: Combining MD5 and SHA-1 to reduce collision probability

2011-04-26 Thread Steffen DETTMER 
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

2011-04-26 Thread James Chase 
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 wrote:

> 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 earlie

slow https conenctions

2011-04-26 Thread Matthew Fletcher 
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 06

Re: PKCS12 - Why Encrypted?

2011-04-26 Thread Michel (PAYBOX) 

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

Re: issue with p12 creation and network solutions EV SSL

2011-04-26 Thread Rob Stradling 
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  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  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 wrote:
> >>>  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 -inke