C# 用于自托管WCF服务、WCF数据服务（OData）和C Windows服务中的网页的ssl/https

我有一个用C编写的Windows服务应用程序，它在后台执行许多任务。作为一个附加功能，该应用程序为UI客户端提供接口，以连接到当前的WPF客户端应用程序。目前主要是WCF数据服务OData和WCF服务，但也可能包括通过嵌入ASP.NET为网页提供服务，以便使用浏览器访问该服务

所有这些都可以很好地工作，通过ServiceHost+WSHttpBinding和DataServiceHost+WebHttpBinding使用自托管服务，这都是在代码中设置的，因为它有点动态/灵活

现在我开始研究身份验证，并通过MessageCredentialType.UserName、UserNamePasswordValidationMode.custom等使用自定义名称/密码验证器设置基本身份验证。现在客户端需要提供正确的用户名/密码，并根据特定于应用程序的用户列表进行验证。这也很有效，比如

webHttpBinding = new WebHttpBinding(WebHttpSecurityMode.TransportCredentialOnly);
webHttpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;

serviceHost.Credentials.UserNameAuthentication.UserNamePasswordValidationMode = UserNamePasswordValidationMode.Custom;
serviceHost.Credentials.UserNameAuthentication.CustomUserNamePasswordValidator = new UserRepositoryPasswordValidator { UserRepository = UserRepository };

serviceHost.Authorization.PrincipalPermissionMode = PrincipalPermissionMode.Custom;

然而，据我所知，在没有任何传输安全性的情况下，用户名/密码以及任何数据在客户端ans服务之间以纯文本传输，这是不可取的。因此，我试图找到一种使用安全/加密通信的方法。这听起来像是ssl/https的发展方向

我阅读了许多文章来了解如何做到这一点，但发现这种方法过于复杂和混乱。我的应用程序显然不使用IIS或其他web服务器，所以许多文章和帖子似乎不适用于我的场景。 此外，所讨论的应用程序应该部署/安装到不同的目标机器上，并且只需运行而无需调整任何操作系统方面。我非常困惑地看到，使用ssl/https需要运行netsh命令来向端口注册证书，等等。这为什么如此复杂

我可以接受，用于ssl/https的证书不是高度可信的证书，因为为安装我的软件的每台目标计算机创建一个新证书是不切实际的，因为我甚至无法控制或看到这些计算机

是否有人提供了一个可以接受的好策略，让我当前的C Windows服务和自托管WCF/WCF数据服务使用ssl/https，而不会带来太多麻烦，也不会使我的应用程序的安装过程复杂化

J-