在 least privilege 的基础上,我认为“正确”的方法是将它们安装在 Azure 信任存储中,但在我的情况下,我使用嵌入资源提供了它们,就像 idsrv3 示例中一样。
以下是对我有用的一些具体细节。创建自签名证书:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\makecert.exe" -r -pe -n "CN=MyAppIdentity" -sky signature MyApp.cer -sv MyApp.pvk
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\pvk2pfx.exe" -pvk MyApp.pvk -spc MyApp.cer -pfx MyApp.pfx -pi MyPassword -po MyPassword
尽管pvk2pfx.exe文档中提到,如果不提供-po,则pfx文件将不能保持与pvk相同的密码,使用X509Certificate2()时会因密码问题而失败。
对我来说,在Azure上使用idsrv3示例代码时,idsrv3示例证书可以正常工作:
var assembly = typeof(Certificate).Assembly;
using (var stream = assembly.GetManifestResourceStream("MyCompany.Identity.Website.Config.idsrv3test.pfx"))
{
return new X509Certificate2(ReadStream(stream), "idsrv3test");
}
然而,当我制作自己的证书时,在使用上述代码进行本地测试时,一切正常,但在Azure上,我不得不添加一些额外的标志才能使其正常工作。我并不确定使用这些标志的影响,但它们有效,所以这是一个开始:
using (var stream = assembly.GetManifestResourceStream("MyCompany.Identity.Website.Config.MyApp.pfx"))
{
return new X509Certificate2(ReadStream(stream),
"MyPassword",
X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);
}