【问题标题】:SSL certificate generated by Firebase Hosting does not include connected domainFirebase 托管生成的 SSL 证书不包括连接的域
【发布时间】:2018-07-10 10:03:45
【问题描述】:

上周我们遇到过两次这个问题。对于具有两个连接域的 Firebase 托管项目,证书中不包含一个域。

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

(51) SSL:没有替代证书主题名称与目标主机名“{host}”匹配

(其中{host} 是主机名/连接域)

要直接检查证书,即SANs,我使用以下命令:

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 由我们客户的服务提供商控制,他们很难更改已经投入生产的任何内容。

【问题讨论】:

  • 我们遇到这个问题已经超过 3 天了,大约 70 个小时我们通过 Firebase 支持提出了这个问题。除了质疑我们的设置是否受支持的回复外,Firebase 支持没有关于票证的更新。我多次要求他们确认,当我创建一个新票时,它立即设置为参考无响应的票解决。非常感谢任何帮助或建议。
  • 我遇到了同样的问题,我所做的是使用 CNAME 记录重定向到 firebase 允许 SSL 证书的域。这不是最好的解决方案,但用户不会收到 SSL 证书消息
  • @Pintouch 谢谢你的建议。你的意思是,如果 x.com 在 Firebase Hosting 上运行并且可以工作,并且 y.com 是出现上述错误的域,我应该在 y.com 上使用 CNAME 指向 x.com?我认为这不能解决证书中缺少正确 SAN 的问题,还是我在这里遗漏了什么?
  • 不,你是对的,我检查了我所做的,我正在以编程方式重定向到另一个域。我记得尝试过,但是您对 SAN 列表中缺少的名称是正确的,您不能这样做,因为它是用于 SSL 证书的浏览器 URL...来自 firebase 的任何消息?
  • @Pintouch 好的,很高兴知道。我以为我误解了什么。太糟糕了,但感谢您的更新! Firebase 支持没有消息:3 天后,他们为延迟表示歉意,并表示他们“向 [他们的] 工程师提供了所提供的信息”,又过了 5 天,他们建议我检查另一个连接域的 google-site-verification TXT 记录那行得通。做到了,但没有改变。不确定他们是否只是猜测,或者实际上知道他们在做什么。他们仍然没有解决方案或解决方法。

标签: ssl dns firebase-hosting


【解决方案1】:

在与 Firebase Support 反复讨论后,他们发现根域包含一个不包含 letsencrypt.org 的 CAA record。

在我们的具体情况下,解决方法是只包括让我们加密子域。例如,使用以下设置

  • 域: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 域有一个 CAA 记录,letsencrypt.org,而 awesomesite.com 没有被触及。

现在一切正常,更新记录后不久。我们不必在 Firebase 托管上重新触发部署或删除/添加连接的域(我之前曾尝试解决此问题)。

解决问题的替代方案:

  • 删除 CAA 记录:从根域(或中间域)中删除 CAA 记录。
  • 扩展 CAA 记录:在根域的 CAA 记录中的域列表中包含 letsencrypt.org

2020 年 9 月更新:根据我收到的一封电子邮件,Google 正在将 SSL 证书提供商迁移到新的 Google 运行的 CA,因为 Let's Encrypt's transition to ISRG's Root 可能会向后中断兼容性。根据该电子邮件,需要使用 pki.goog 的额外 CAA:

firebaseapp.awesomesite.com.    3599    IN  CAA 0 issue "pki.goog"
firebaseapp.awesomesite.com.    3599    IN  CAA 0 issue "letsencrypt.org"

【讨论】:

    【解决方案2】:

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

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

    【讨论】:

    • 这里不是这样。正如我所描述的,证书已正确配置,但该过程失败了。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-01-02
    • 2020-07-04
    • 2019-07-21
    • 2023-03-10
    • 2017-09-03
    相关资源
    最近更新 更多