我正在使用ASP.NET MVC平台开发一个应用程序，该平台将作为Web上的服务公开（SaaS模型）。我正在尝试确定为每个用户帐户分区URL命名空间的最佳方法。该应用程序需要通过SSL安全访问，因此我主要关注的是提出一种适用于SSL证书的URL设计。以下是我提出的选项。在每个示例中， bob 和 jane 是两个示例用户帐户：
e.g。
https://bob.example.com
https://jane.example.com
e.g。
https://bobs-domain.com
https://domain-of-jane.com
在这种情况下，每个用户都会绑定一个SSL证书 他们的域名。一个大 我能想到的缺点是我们的 服务器必须维护 所有用户的私钥 证书，我们必须设计一个 允许用户使用的系统 安全地传输他们的私钥 到我们的服务器。即使我们有这样的 一个系统，我觉得它也会 用户必须承受很大的负担 获得证书然后提交 我们的私钥。
或者，我们可以 自动发布和提供 每个用户的SSL证书 他们注册，所以他们可以开始 通过SSL访问他们的应用程序 额外的步骤。这个会 要求我们成为发行人 SSL证书，我没有 看着......可能我们会 成为其他一些大牌的经销商 像Verisign这样的公司 擅长这类事。
尽管有这种明显的痛苦 方法，此选项确实启用 我们可能想要的一些功能 在将来提供，即允许 用户拥有自己的品牌 通过访问的应用程序版本 他们自己的公司域名。
e.g。
https://example.com/bob
https://example.com/jane
从SSL的角度来看 证书维护，这是 可能是最好的选择。我们会 只需要一个固定域SSL证书 （例如example.com） 供所有用户使用。
不幸的是，此网址设计效果不佳 与我们当前的其他方面 特别是应用程序架构 负载平衡。
我的问题是：你会选择什么选项，为什么？我特别喜欢听到现实世界的例子和经历，但我还没有提出任何其他问题或疑虑。
答案 0 :(得分：2)
我会选择A.这个解决方案不是很昂贵，它可以很好地扩展，如果您稍后决定，它不会限制您使用自定义域。
通配符证书过去非常昂贵，但今天你可以在GoDaddy或RapidSSL每年获得大约200美元，我认为这相当便宜。这些证书（几乎）可以在任何浏览器中使用，但VeriSign提供的验证不附带。我不知道你是否需要这个。
如果你选择B，你必须为每个用户购买证书，但是使用通配符证书后，证书将在几次注册后支付，其余的将是纯粹的收入。
除此之外，解决方案实施起来非常简单，这也是一种优势。
答案 1 :(得分：1)
听起来像选项B给我。它是唯一似乎a）与您的架构一起工作并且b）与您未来的潜在目标一起工作的人。您可以将自定义域的SSL证书的价格作为服务启动成本的一部分（或者按月收费摊销成本）。
我没有看到A和B之间真正的区别，除了你可以使用A的外卡证书之外，它们实际上是完全相同的，你只是不需要。如果没有外卡方面，A == B，它们都是example.com的子域的事实是巧合。
即使在开头有选项A，如果您希望为您的客户提供服务功能，您也可以稍后扩展到选项B.
答案 2 :(得分：1)
选项B对用户有很多价值，如果我有选择，我会选择这条路线。请记住，您可以购买多域ssl证书/ UCC，并且您可以在一个证书下获得多达100个域。如果有其他证书允许超过100 - 请告诉我，因为我们正在建立一个SAAS模型，并有类似的问题。
答案 3 :(得分：0)
你是对的Will，A和B是一样的。但是，我认为这主要是从编码的角度来看。使用任一选项，Web服务器将根据HTTP标头中的主机名确定帐户。 C与编码角度略有不同，因为它会根据域名下的路径匹配帐户，而ASP.NET MVC框架的URL路由功能在这里会派上用场。
从管理角度来看，每个选项都是完全不同的。使用选项A，我们必须管理子域名...我们可以这样做，因为我们的DNS提供商有一个API来管理主机记录。如上所述，使用选项B，我们必须管理所有不同域名的私钥。
我猜测答案的数量，这不是在这个论坛上提出的最好的问题类型，可能是因为它太开放了。我只是希望那个曾经在那里做过的人能够参与其中，主要是因为我知道我是否在正确的轨道上，因为我以前从未设计过这样的系统。
由于
答案 4 :(得分：0)
我会使用secure.domain.com而不是www.domain或domain.com的证书 我见过许多网站使用其中一个选项的证书（有或没有www前缀），当用户使用其他选项时，系统会提示他接受证书接受。
您可以将user.domain.com用于非安全网站，当用户需要启用SSL时，只需使用您的主要secure.domain.com/user/ .......
这只是一个想法。
斯拉维