嗨，我来帮你捋清楚这个问题的解决办法～首先得明白为什么会出现这个错误：当你用HTTPS访问offer.mysupersite.com时，浏览器会检查这个域名对应的SSL证书，但当前返回的证书是给securedomain.com（或它的子域名）签发的，证书里的“通用名称”或者SAN（主题备用名称）和你访问的offer.mysupersite.com不匹配，浏览器就会判定这个证书无效，弹出ERR_CERT_COMMON_NAME_INVALID错误。

下面是几个可行的解决方向，你可以根据自己的情况选择：

• 让着陆页服务为你的自定义子域名配置SSL证书
  这是最直接的解决方案。你需要联系这个着陆页服务的支持，询问他们是否支持为用户的自定义子域名（也就是你的offer.mysupersite.com）签发或配置SSL证书。现在很多SAAS服务都支持这个功能：你在服务后台添加你的自定义域名，他们会自动通过Let's Encrypt这类免费证书机构为你的域名签发证书，或者把你的域名添加到他们的通配符证书的SAN列表里。这样当用户访问你的子域名时，返回的证书就会包含offer.mysupersite.com，浏览器就不会报错了。

• 用CDN服务做中转（比如Cloudflare）
  如果着陆页服务不支持自定义域名的证书，你可以借助CDN来解决。步骤大概是这样：

  1. 把offer.mysupersite.com的DNS解析切换到支持SSL的CDN平台；
  2. 在CDN后台设置这个子域名的解析方式为CNAME，指向myname.securedomain.com；
  3. 开启CDN的SSL功能，选择合适的模式：比如“Flexible”模式（用户和CDN之间用HTTPS，CDN和后端服务之间用HTTP），或者“Full”模式（两端都用HTTPS，因为后端的myname.securedomain.com已经有合法证书，所以可以正常工作）。
     这样用户访问offer.mysupersite.com时，是和CDN建立HTTPS连接，CDN会给你的子域名提供合法的SSL证书，而CDN和后端服务之间的通信则会处理好证书匹配的问题，浏览器就不会再报错了。

• 尝试用CNAME替代A记录
  你现在用的是A记录指向服务的IP，试试改成CNAME记录直接指向myname.securedomain.com，然后去着陆页服务的后台添加offer.mysupersite.com作为自定义域名。有些服务会通过SNI（服务器名称指示）技术，根据用户访问的域名返回对应的证书——如果服务支持这个，并且能为你的子域名配置好证书关联，这个方法也能解决问题。不过这个前提还是服务要支持自定义域名的证书配置，不然单纯改CNNAME还是会返回原来的证书，错误依然存在。

最后说说你提到的TXT记录：TXT记录本身没办法直接解决证书匹配的问题，它主要用来做域名所有权验证（比如服务需要确认你确实是offer.mysupersite.com的所有者，会让你添加一条特定的TXT记录）、或者配置邮件相关的SPF/DKIM规则。如果着陆页服务在添加自定义域名时需要验证你的所有权，那TXT记录是配置流程里的一步，但它不是解决证书错误的直接方案哦。

备注：内容来源于stack exchange，提问作者jibai31