看样子一定是客户端证书pem格式的问题了,看看有没有可能是文件换行符的问题,不嫌麻烦的话调试一下curl的源代码吧
在 2010-7-26 下午9:34,"Chinainvent" <chinain...@gmail.com>编写:
谢谢,这个帖子,给我了很大希望,按帖子里的方法,我把ca、key、client cert分了开来了,不过仍然报错,这次我加入了-v选项,使用出错更详细些:
[yunkai@alibaba ~/itbu/https]$ curl -v --key key.pem --cacert ca.pem --cert client.pem:xxxx https://www.cn.alibaba-inc.com* About to connect() to www.cn.alibaba-inc.com port 443 (#0)* Trying 121.0.17.70... connected* Connected to www.cn.alibaba-inc.com (121.0.17.70) port 443 (#0)* Initializing NSS with certpath: /etc/pki/nssdb* CAfile: ca.pemCApath: none* Closing connection #0* Out of memorycurl: (27) Out of memory
2010/7/26 Feng Shao <seve...@gmail.com>
>
>
>
> 2010/7/26 Chinainvent <chinain...@gmail.co...
是不是文件格式问题? dos2unix一下看看。
不会的,我的所有操作,都是在我的fedora13上进行的。今天又细看了一遍https的握手过程,大家可以参考这里,从文中看,我说的这种情况,就属于“双向认证”的过程,大家在单向认证上,都有很丰富的经验,但使用双向认证,一般是不多见的。所以同学们的建议,大部分都基于猜测。呼唤有真正成功经验的同学登场吧。。。
On 7/27/10, Feng Shao <seve...@gmail.com> wrote:
> 2010/7/27 Chinainvent <chinain...@gmail.com>
>
>> 不会的,我的所有操作,都是在我的fedora13上进行的。
>>
>> 今天又细看了一遍https的握手过程,大家可以参考这里<http://baike.baidu.com/view/14121.html?wtp=tt>
>> ,从文中看,我说的这种情况,就属于“双向认证”的过程,大家在单向认证上,都有很丰富的经验,但使用双向认证,一般是不多见的。所以同学们的建议,大部分都基于猜测。
>>
>> 呼唤有真正成功经验的同学登场吧。。。
>>
>
> 昨晚我用发给你那个帖子( http://curl.haxx.se/mail/archive-2005-09/0138.html )里面的方法试过,
> 我用的是startssl.com的客户端证书,从Firefox导出后文件扩展名是.p12 ,(PKCS)文件,
> 然后用链接中的三个命令,生成证书,
> openssl pkcs12 -in MULTICERT.p12 -out ca.pem -cacerts -nokeys
> openssl pkcs12 -in MULTICERT.p12 -out client.pem -clcerts -nokeys
> openssl pkcs12 -in MULTICERT.p12 -out key.pem -nocerts
>
> curl -v --key key.pem --cacert ca.pem --cert client.pem:xxxxxx
> https://www.somesite.com/page
>
> 命令就是这样的,你照着做看行不行。
>
>>
>> 因为现在本人对证书认证、https的协议细节不熟,所以即使看源码,也需要先补上这两堂课。
>>
>>
>> 2010/7/27 Wang Feng <wanng...@gmail.com>
>>
>> 2010/7/27 Chinainvent <chinain...@gmail.com>:
>>> > 1. ca证书,是直接从firefox里导出来的,
>>> >
>>> > 2. 个人证书,是从IE导出来的pfx格式。
>>>
>>> 是不是文件格式问题? dos2unix一下看看。
>>>
>>
>>
>>
>> --
>> Chinainvent
>> Blog: http://blog.csdn.net/chinainvent
>> Work at Alibaba <http://www.alibaba.com>
>>
>>
>
--
Chinainvent
Blog: http://blog.csdn.net/chinainvent
Work at Alibaba <http://www.alibaba.com>
On 7月28日, 下午3时37分, Chinainvent <chinainvent....@gmail.com> wrote:
> 还是失败,原因在于,从firefox里导出的p12文件,只是client的公钥与私钥的合并体,你的例子中的MULITCERTS.p12是怎么来的呢?不 可解出三者合一的东西呀。。。,
>
> 而对于我所关心的以司的这个内网:https://www.cn.alibaba-inc.com
> ,我只能把公共证书的单独导出来并转成cacert.p12,但是当我把这三者一起使用时,就报出我前观邮件中提到的错误:
>
> [yunkai@alibaba ~/itbu/https/tm]$ curl -v --key key.pem --cacertwww.cn.alibaba-inc.com.pem--cert client.pem:hello123https://www.cn.alibaba-inc.com
> * About to connect() towww.cn.alibaba-inc.comport 443 (#0)
> * Trying 121.0.17.70... connected
> * Connected towww.cn.alibaba-inc.com(121.0.17.70) port 443 (#0)
> * Initializing NSS with certpath: /etc/pki/nssdb
> * CAfile:www.cn.alibaba-inc.com.pem
> CApath: none
> * Closing connection #0
> * Out of memory
> curl: (27) Out of memory
>
> 2010/7/28 Chinainvent <chinainvent....@gmail.com>
>
>
>
>
>
> > 谢谢Feng,现在医院排队,我就是照你推荐的那个网址一模一样照做的,不过有你这成功的案例,也让我很欣喜了,回去我再试试:D
>
> > On 7/27/10, Feng Shao <sevene...@gmail.com> wrote:
> > > 2010/7/27 Chinainvent <chinainvent....@gmail.com>
>
> > >> 不会的,我的所有操作,都是在我的fedora13上进行的。
>
> > >> 今天又细看了一遍https的握手过程,大家可以参考这里<
> >http://baike.baidu.com/view/14121.html?wtp=tt>
>
> > ,从文中看,我说的这种情况,就属于“双向认证”的过程,大家在单向认证上,都有很丰富的经验,但使用双向认证,一般是不多见的。所以同学们的建议,大部分都基 于猜测。
>
> > >> 呼唤有真正成功经验的同学登场吧。。。
>
> > > 昨晚我用发给你那个帖子(http://curl.haxx.se/mail/archive-2005-09/0138.html)里面的方法试过,
> > > 我用的是startssl.com的客户端证书,从Firefox导出后文件扩展名是.p12 ,(PKCS)文件,
> > > 然后用链接中的三个命令,生成证书,
> > > openssl pkcs12 -in MULTICERT.p12 -out ca.pem -cacerts -nokeys
> > > openssl pkcs12 -in MULTICERT.p12 -out client.pem -clcerts -nokeys
> > > openssl pkcs12 -in MULTICERT.p12 -out key.pem -nocerts
>
> > > curl -v --key key.pem --cacert ca.pem --cert client.pem:xxxxxx
> > >https://www.somesite.com/page
>
> > > 命令就是这样的,你照着做看行不行。
>
> > >> 因为现在本人对证书认证、https的协议细节不熟,所以即使看源码,也需要先补上这两堂课。
>
> > >> 2010/7/27 Wang Feng <wanng.fe...@gmail.com>
>
> > >> 2010/7/27 Chinainvent <chinainvent....@gmail.com>:
> > >>> > 1. ca证书,是直接从firefox里导出来的,
>
> > >>> > 2. 个人证书,是从IE导出来的pfx格式。
>
> > >>> 是不是文件格式问题? dos2unix一下看看。
>
> > >> --
> > >> Chinainvent
> > >> Blog:http://blog.csdn.net/chinainvent
> > >> Work at Alibaba <http://www.alibaba.com>
>
> > --
> > Chinainvent
> > Blog:http://blog.csdn.net/chinainvent
> > Work at Alibaba <http://www.alibaba.com>
>
> --
> Chinainvent
> Blog:http://blog.csdn.net/chinainvent
> Work at Alibaba <http://www.alibaba.com>
呵呵,还是ubuntu好,搞开发还是用u吧
在 2010-7-29 下午11:26,"Chinainvent" <chinain...@gmail.com>编写:
我成功了!!!一切原因,都在于fedura13上的libcurl库(直接从yum安装的,libcurl-7.20.1-3.fc13.i686)!真是折腾呀。今天,从curl的官网上下载了curl的源码,然后打开-g选项,进行调试,一开始问题依旧,后来发现编译后的curl还是引到了系统安装的/usr/lib/libcurl.so.4,后面设置LD_LIBRARY_PATH,使curl引用本地编译的libcurl,刚才一试居然可以了!!!相当激动呀,这两天的努力算是没有白费。不过,还是要感谢各位的回复,是你们给了偶力量:DThank you!!
2010/7/29 何源 <he.yuan...@gmail.com>
>
> p12证书应该是根证书、客户证书(内含客户公钥)、客户私钥组成的。由于有客户的密钥对,所以打包的时候都用DES3或加密算法加了密。
> 我觉得以上操作应该没有问题。要不您换一个版本的curl...
不是想挑起战争,只是当年用rh7和fc1也是遇到过类似的与系统库有关的怪问题,跟踪了很久,浪费不少时间,后来换u就再没出过怪事了。
当然如果工作需要不得不用又另当别论
在 2010-7-29 下午11:46,"Chinainvent" <chinain...@gmail.com>编写:
这跟u没有什么关系。。,任何人都会犯错。我曾经用u,因为服务都redhat,fedora的系统结构与redhat并无二致,图个较低的学习成本而已。
2010/7/29 lxcypp <lxc...@gmail.com>
>
> 呵呵,还是ubuntu好,搞开发还是用u吧
>>
>> 在 2010-7-29 下午11:26,"Chinainvent" <chinain...@gmail.com>编写:
>>...