我们在与客户的 SAML SSO 集成中充当服务提供商。在开发和阶段测试期间，我们通常会交换元数据文件和 SSO 端点。
在形成我们的元数据时，我们使用openssl命令行工具生成一个自签名证书，我们将X509Certificate节点的值设置为：
openssl genrsa -out server.pem 1024
openssl req -new -key server.pem -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.pem -out server.crt
现在的问题是，在生产时，我们应该从第三方获取合法证书，还是可以简单地重新生成一个新的自签名证书？如果使用自签名的，我们会有什么潜在的安全性或其他影响？
注意：作为服务提供商，我们不会在这种 IdP 发起的设置中发送 SAML 消息。
使用 Python、Django 和djangosaml2包（如果相关）。
TL;DR： 自签名证书很好，至少在某些情况下甚至推荐。使用较长的有效期以避免密钥翻转问题，如果是 RSA，则至少使用 2048 位密钥。
SAML 2.0 包括应该用于签名验证和作为SAML 元数据一部分的加密接收者的证书（从技术上讲，在EntityDescriptor.
使用元数据的实体应该以“已知良好”的方式验证元数据。例如，这可能是通过仅通过受信任的通道下载它（例如通过具有正常证书验证的 HTTPS），或者通过在本地存储已以某种其他受信任的方式获取并验证元数据的副本。
在实践中，元数据也往往是 XML 签名的，它提供了一个额外的完整性验证层，超出了例如 HTTPS 提供的保护。（这是一件好事，特别是考虑到有多少实现似乎需要实际手动下载元数据并将其存储在容易被意外或恶意修改的地方。至少 XML 签名无法验证，导致元数据被拒绝而不是而不是使用可能不正确的元数据。）
如果您无法在确保所述元数据的完整性的同时交换 SAML 元数据，那么您就会遇到严重的引导问题，以至于我什至不确定是否可以以安全的方式使用 SAML。如果您不能信任作为元数据一部分的证书，这意味着您也不能信任元数据中的任何其他内容，例如端点 URI。
如果您能够在确保其完整性的同时交换 SAML 元数据，则根据定义，它包含一个受信任的证书 blob，旨在（受元数据中规定的限制）用于：
由于该证书（来自受信任的元数据）根据定义是受信任的，因此使用 CA 签名的证书与使用自签名证书相比没有显着的优势。因此，没有理由使用 CA 签名的证书，也有理由不使用（例如，在 Internet2 上，建议使用有效期至少为 10 年的证书；我不知道有任何商业 CA 提供证书长期有效）。
举一个公认的轶事示例，Microsoft 的 Active Directory 联合服务 (ADFS) 似乎对 SAML 元数据中的自签名证书非常满意。我在 SP 方面所做的与您在测试中所做的几乎完全相同，ADFS 充当 IdP。