Question

上个星期我们两次遇到这个问题。对于具有两个连接域的Firebase托管项目，证书中不包括一个域。

尝试连接浏览器似乎返回503状态代码，Chrome在控制台中显示net::ERR_CERT_COMMON_NAME_INVALID。 curl返回

（51）SSL：没有其他证书使用者名称与目标主机名“ {host}”匹配

（其中{host}是主机名/连接的域）

要直接检查证书，即SAN，我使用以下命令：

gnutls-cli --print-cert ${host} < /dev/null \
    | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
    | openssl x509 -noout -text \
    | grep DNS | tr , '\n' | tr -s " "

这将返回100个证书的列表，包括工作域的主机名，但仅包含失败域的默认firebaseapp.com/*.firebaseapp.com条目。

注意：我在这里使用gnutls-cli，因为似乎openssl s_client -connect ${host}:443在请求中不包含主机名，并且始终为firebaseapp.com/*.firebaseapp加载证书。 com

我已经联系了Firebase支持，但他们的最后答复（约16小时前）是“同一个项目有两个不同的域关联，但是我需要确认是否支持”。鉴于在分析问题时发现，在我们负责的域旁边，对于相同的两个主机名，已经找到了400多个SAN，因此，我对此表示肯定。

关于如何解决此问题的任何建议？我已经尝试删除并重新添加自定义域，但这没有任何改变。

从技术上来说，切换托管并不难，但是我们的主要问题是DNS受客户服务提供商的控制，并且他们很难更改生产中已经存在的任何内容。

Answer 1

经过Firebase支持的反复研究后，他们发现根域包含一个CAA record，其中不包含 letsencrypt.org 。

我们特定情况下的解决方法是仅让我们对子域进行加密。例如，使用以下设置

域：awesomesite.com
连接的域：firebaseapp.awesomesite.com

我们可以使用dig查询记录：

$ dig CAA awesomesite.com +noall +answer && dig CAA firebaseapp.awesomesite.com +noall +answer             

; <<>> (...) <<>> CAA awesomesite.com +noall +answer
;; global options: +cmd
awesomesite.com.        299 IN  CAA 0 iodef "mailto:cert@awesomesite.com"
awesomesite.com.        299 IN  CAA 0 issue "digicert.com"

; <<>> (...) <<>> CAA firebaseapp.awesomesite.com +noall +answer
;; global options: +cmd
firebaseapp.awesomesite.com.    3599    IN  CAA 0 issue "letsencrypt.org"

如您所见，域firebaseapp.awesomesite.com包含具有 letsencrypt.org 的CAA记录，而未触及awesomesite.com。

现在，一切正常，更新记录仅一小段时间。我们不必在Firebase Hosting上重新触发部署，也不必删除/添加连接的域（我之前曾尝试解决此问题的事物）。

更正此问题的替代方法：

删除CAA记录：从根域（或中间域）中删除CAA记录。
扩展CAA记录：在根域的CAA记录的域列表中包括 letsencrypt.org

Answer 2

对于您的自定义域，如果您的DNS记录具有指向其他提供程序的A记录或CNAME记录，则Firebase无法设置SSL证书。

https://support.google.com/firebase/answer/9137747?hl=en

Firebase Hosting生成的SSL证书不包含连接的域

2 个答案: