我有一个用 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;
但是，据我了解，没有任何类型的传输安全性，用户名/密码以及任何数据都在客户端和服务之间以纯文本形式传输，这是不可取的。因此，我试图找到一种使用安全/加密通信的方法。这听起来像 ssl/https 将是要走的路。
我浏览了许多文章来了解如何做到这一点，但发现这种方法过于复杂和令人困惑。我的应用程序显然不使用 IIS 或其他 Web 服务器，所以很多文章和帖子似乎不适用于我的场景。此外，有问题的应用程序应该部署/安装到不同的目标机器上并“运行”而不需要调整任何操作系统方面。看到使用 ssl/https 需要运行 netsh 命令来向端口注册证书等，我感到非常困惑。为什么这么复杂？
我可以接受用于 ssl/https 的证书不是高度可信的证书，因为为安装了我的软件的每台目标机器创建一个新证书是不切实际的（其中大部分我什至无法控制或从未见过）。
有没有人有关于让我当前的 C# Windows 服务与自托管 WCF/WCF 数据服务使用 ssl/https 没有太多麻烦并且不会使我的应用程序的安装过程复杂化的良好可接受策略的说明？
J.-