godaddy的时间戳服务器和itextsharp出了什么问题? [英] what is wrong with godaddy's timestamp server and itextsharp?

查看:126
本文介绍了godaddy的时间戳服务器和itextsharp出了什么问题?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用iTextSharp库来签署PDF文档。当我使用标准TSAClientBouncyCastle类从GoDaddy的服务器获取时间戳时( http://tsa.starfieldtech.com ) ,响应是一个空流。同时,它与其他符合RFC 3161标准的时间戳服务器完美配合。此外,当我使用microsoft的signtool.exe用/ tr选项签署exe文件时,它适用于Godaddy的服务器。
所以我想知道我尝试使用iTextSharp库以编程方式获取时间戳有什么问题。

I am using the iTextSharp library to sign PDF documents. When I use the standard TSAClientBouncyCastle class to get time stamp from GoDaddy's server ( http://tsa.starfieldtech.com ), the response is an empty stream. At the same time, it perfectly works with other RFC 3161 compliant timestamp servers. Also, when I use microsoft's signtool.exe to sign exe file with /tr option, it works with Godaddy's server. So I wonder what is wrong with my attempt to get a timestamp programmatically using the iTextSharp library.

提前致谢。

UPD:

我使用过这个样本:

http://sourceforge.net/p/itextsharp/code/ HEAD / tree / tutorial / signatureatures / chapter2 / C2_01_SignHelloWorld / C2_01_SignHelloWorld.cs

只修改我指定了一个带有构造函数的TSAClient 。

with only modification that I've specified a TSAClient with constructor that takes an URL.

代码修改方式如下:而不是

The code is modified in a following way: instead of

MakeSignature。 SignDetached(外观,pks,链,null,null,null,0,subfilter);

我使用

ITSAClient tsaClient = new TSAClientBouncyCastle(http://tsa.starfieldtech.com/);
MakeSignature.SignDetached(外观,pks,链,null,null,tsaClient,0,subfilter);

推荐答案


当我使用标准 TSAClientBouncyCastle 用于从GoDaddy服务器获取时间戳的类( http://tsa.starfieldtech。 com)),响应是一个空流。

When I use the standard TSAClientBouncyCastle class to get time stamp from GoDaddy's server (http://tsa.starfieldtech.com), the response is an empty stream.

我可以使用iTextSharp& ;;重现这种行为。 C#但不是iText& Java。

I could reproduce this behavior using iTextSharp & C# but not iText & Java.

通过检查实际网络流量,时间戳请求对象被证明是相同构建的,但在封装HTTP请求中使用的HTTP头存在细微差别。

By inspecting the actual network traffic the time stamp request objects turned out to be identically built but there were minor differences in the HTTP headers used in the enveloping HTTP request.

逐个调整 TSAClientBouncyCastle.GetTSAResponse 中的请求标头, 用户代理标题被证明是罪魁祸首

Adjusting the request headers in TSAClientBouncyCastle.GetTSAResponse one by one, the User-Agent header proved to be the culprit:


  • .Net HttpWebRequest 默认情况下似乎没有添加这样的标题,但是

  • Java HttpURLConnection 默认情况下会添加包含Java版本作为值,例如Java / 1.8.0_20。

  • The .Net HttpWebRequest by default does not seem to add such a header but
  • the Java HttpURLConnection by default adds such a header containing the Java version as value, e.g. "Java/1.8.0_20".

TSAClientBouncyCastle.GetTSAResponse ,例如像这样:

/**
 * Get timestamp token - communications layer
 * @return - byte[] - TSA response, raw bytes (RFC 3161 encoded)
 */
protected internal virtual byte[] GetTSAResponse(byte[] requestBytes) {
    HttpWebRequest con = (HttpWebRequest)WebRequest.Create(tsaURL);
    // Additional User-Agent header to make http://tsa.starfieldtech.com happy
    con.UserAgent = "iTextSharp";
    con.ContentLength = requestBytes.Length;
    con.ContentType = "application/timestamp-query";
    con.Method = "POST";

时间戳服务器返回正确的时间戳响应。

the time stamp server returns a proper time stamp response.

由于User-Agent标头被指定为推荐但不是必需的,因此焦点时间戳服务器的这种行为是非常值得怀疑的。

As the User-Agent header is specified as recommended but not required, this behavior of the time stamp server in focus is quite questionable.

实际上我必须先解决另一个问题:我必须在这里使用HTTP代理,并且代理总是干扰iTextSharp / C#时间戳请求(但同样不能使用iText / Java时间戳请求)返回

Actually I had to fight with a different issue first: I have to use a HTTP proxy here, and the proxy always interfered with the iTextSharp/C# time stamp requests (but again not with the iText/Java time stamp requests) returning a

System.Net.WebException : The remote server returned an error: (417) Expectation Failed.
at System.Net.HttpWebRequest.GetResponse()

将HTTP协议版本限制为1.0

Restricting the HTTP protocol version to 1.0

    con.ProtocolVersion = Version.Parse("1.0");

解决了这个问题。

(@ BrunoLowagie,@ PauloSoares:在iTextSharp中添加User-Agent标头不应该受到影响,但我怀疑通常将HTTP限制为1.0是一个好主意。)

(@BrunoLowagie, @PauloSoares: It shouldn't hurt to add a User-Agent header in iTextSharp but I doubt generally restricting HTTP to 1.0 is a good idea.)

这篇关于godaddy的时间戳服务器和itextsharp出了什么问题?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆