Firebase Hosting 生成的 SSL 证书不包括连接的域 [英] SSL certificate generated by Firebase Hosting does not include connected domain

查看:12
本文介绍了Firebase Hosting 生成的 SSL 证书不包括连接的域的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

We've had this issue twice during the last week. For a Firebase Hosting project with two connected domains, one domain is not included in the certificate.

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

Trying to connect with a browser seems to return a 503 status code and Chrome shows net::ERR_CERT_COMMON_NAME_INVALID in the console. curl returns

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

(51) SSL: no alternative certificate subject name matches target host name '{host}'

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

(where {host} is the host name / connected domain)

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

To check the certificate directly, i.e. the SANs, I use the following command:

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

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

This returns a list of 100 certificates including the host name for the working domain, but only the default firebaseapp.com/*.firebaseapp.com entries for the failing domain.

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

Note: I am using gnutls-cli here, because it seems that openssl s_client -connect ${host}:443 does not include the host name in the request and always loads a certificate for firebaseapp.com/*.firebaseapp.com

我已经联系了 Firebase 支持,但他们的最后回复(大约 16 小时前)是有两个不同的域与同一个项目相关联,但我需要确认这是否受支持".我很确定这是支持的,因为在我对问题的分析过程中,我发现了 400 多个 SAN 用于我们负责的域旁边的相同的两个主机名.

I have already reached out to Firebase Support, but their last response (~16 hours ago) was "there are two different domains associated to the same project, but I need to confirm if this is supported". I am quite sure this is supported, given that during my analysis of the problem I have found more than 400 SANs for the same two host names next to the domains under our responsibility.

对我们如何解决此问题有任何建议吗?我已经尝试删除并重新添加自定义域,但这并没有改变任何东西.

Any suggestions on how we can resolve this issue? I already tried deleting and re-adding the custom domain, but this did not change anything.

切换托管在技术上不会太困难,但我们的主要问题是 DNS 由我们客户的服务提供商控制,他们很难更改已在生产中的任何内容.

Switching hosting would technically not be too difficult, but our main issue is that the DNS is under control of a service provider of our customer and it's difficult for them to change anything already in production.

推荐答案

在与 Firebase 支持人员反复讨论后,他们发现根域包含一个 CAA 记录,不包括 letsencrypt.org.

After some back and forth with Firebase Support, they found out that the root domain contained a CAA record that did not include letsencrypt.org.

在我们的特定情况下的修复是只包括让我们加密子域.例如,使用以下设置

The fix in our specific case was to include let's encrypt for the subdomain only. As an example, using the following settings

  • 域:awesomesite.com
  • 连接域:firebaseapp.awesomesite.com

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

We can query the records using 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 是没碰过.

As you can see, the domain firebaseapp.awesomesite.com has a CAA record with letsencrypt.org, while awesomesite.com was not touched.

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

Everything works fine now, just a short time after updating the records. We did not have to retrigger deployment on Firebase Hosting or delete/add the connected domain (things I had previously tried to resolved the problem).

解决问题的替代方法:

  • 删除 CAA 记录:从根域(或中间域)中删除 CAA 记录.
  • 扩展 CAA 记录:在根域的 CAA 记录中的域列表中包含 letsencrypt.org
  • Delete CAA records: Remove the CAA record from the root domain (or intermediary domains).
  • Extend CAA records: Include letsencrypt.org in the list of domains in the CAA record of the root domain

更新,2020 年 9 月:根据我收到的一封电子邮件,由于 让我们加密过渡到 ISRG 的根,这可能会破坏向后兼容性.根据那封电子邮件,需要使用 pki.goog 的附加 CAA:

Update, September 2020: According to an email I have received, Google is in the process of migrating the SSL certificate provider to a new Google-run CA because of Let's Encrypt's transition to ISRG's Root that may break backwards compatibility. According to that email, an additional CAA using pki.goog is required:

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

这篇关于Firebase Hosting 生成的 SSL 证书不包括连接的域的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆