从 ASP Net 调用 https 进程

发布于 2024-08-13 00:30:34 字数 714 浏览 2 评论 0原文

我有一个 ASP NET Web 服务器应用程序,它调用在同一个盒子上运行的另一个进程,该进程创建一个 pdf 文件并返回它。第二个过程需要通过 SSL 进行安全连接。

第二个进程已向我的 ASP NET 应用程序颁发了数字证书,但我仍然无法进行身份验证,出现 403 错误。

代码有点难以显示,但这里有一个简化的方法......

    X509Certificate cert = X509Certificate.CreateFromCertFile("path\to\cert.cer");
    string URL = "https://urltoservice?params=value";
    HttpWebRequest req = HttpWebRequest.Create(URL) as HttpWebRequest;
    req.ClientCertificates.Add(cert);
    req.Credentials = CredentialCache.DefaultCredentials;
    req.PreAuthenticate = true;
    /// error happens here
    WebResponse resp = req.GetResponse();
    Stream input = resp.GetResponseStream();

错误文本是“远程服务器返回错误:(403) Forbidden”。 欢迎任何指点。

I have an ASP NET web server application that calls another process running on the same box that creates a pdf file and returns it. The second process requires a secure connection via SSL.

The second process has issued my ASP NET application with a digital certificate but I still cannot authenticate, getting a 403 error.

The code is a little hard to show but here's a simplified method ...

    X509Certificate cert = X509Certificate.CreateFromCertFile("path\to\cert.cer");
    string URL = "https://urltoservice?params=value";
    HttpWebRequest req = HttpWebRequest.Create(URL) as HttpWebRequest;
    req.ClientCertificates.Add(cert);
    req.Credentials = CredentialCache.DefaultCredentials;
    req.PreAuthenticate = true;
    /// error happens here
    WebResponse resp = req.GetResponse();
    Stream input = resp.GetResponseStream();

The error text is "The remote server returned an error: (403) Forbidden."
Any pointers are welcome.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

掐死时间 2024-08-20 00:30:34

最后修复了(在这个 *&%$@#& 上浪费了 6 个小时),

我需要向调用 ASP.NET 应用程序运行的帐户授予对 digi 证书上私钥的访问权限。默认情况下,此帐户是 NETWORK SERVICE,尽管您可能希望在更受限制的帐户下运行。
使用 winhttpcertcfg 工具授予访问权限,这就是它对我有用的原因:

winhttpcertcfg -g -s "cert name" -c "LOCAL_MACHINE\MY" -a "NETWORK SERVICE"
其中“证书名称”是数字证书的 CN。
更多信息请访问 http://support.microsoft.com/kb/901183

感谢所有参与的人帮助指导如何使其正常工作:)

Finally fixed (wasted 6 hours on this *&%$@#&)

I needed to grant access to the private keys on the digi cert to the account that the calling ASP.NET application runs under. This account is NETWORK SERVICE by default although you may want to run under a more restricted account.
Access is granted with the winhttpcertcfg tool, here's what got it working for me:

winhttpcertcfg -g -s "cert name" -c "LOCAL_MACHINE\MY" -a "NETWORK SERVICE"
where "cert name" is the CN of the digi cert.
More info at http://support.microsoft.com/kb/901183

Thanks to all who helped out with pointers on how to get this working :)

萌能量女王 2024-08-20 00:30:34

403 听起来像是授权问题,而不是身份验证问题。这可能是由 PDF 服务访问的文件和文件夹的 NTFS 安全设置引起的。也许它没有权限在输出文件夹中创建 PDF 文件?

您可以将客户端证书安装到浏览器中,然后通过浏览器访问您的PDF服务吗?当您这样做时,您仍然会收到 403 还是它有效?

您可以临时配置 PDF 服务以允许未加密的 HTTP 连接吗?这会让问题消失吗?

从 Windows 资源管理器中,您能否授予“网络服务”帐户对与 PDF 服务站点根目录相对应的物理文件夹的完全控制权?还授予它对其访问的任何其他目录的完全控制权。当你弄清楚事情之后,你应该把事情锁定起来。

或者您可以更改应用程序池以在不同的帐户下运行 - 例如您自己的帐户。

最后:如果您运行的是 IIS 7,则可以打开失败请求跟踪,这将为您提供有关失败原因的更多信息。

A 403 sounds like an authorization problem, not an authentication problem. It might be caused by the NTFS security settings on the files and folders accessed by your PDF service. Maybe it doesn't have permission to create the PDF file in the output folder?

Can you install the client certificate into your browser, and then access your PDF service through the browser? When you do that, do you still get a 403 or does it work?

Can you temporarily configure the PDF service to allow unencrypted HTTP connections? Does that make the problem go away?

From Windows Explorer, can you grant the "Network Service" account full control over the physical folder corresponding to the root of the PDF service site? Also grant it full control over any other directories it accesses. You should lock things down later after you've figured things out.

Or you can change the application pool to run under a different account - e.g. your own account.

Finally: if you're running IIS 7, you can turn on failed request tracing, which should give you a lot more info about why it failed.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文